envoyproxy/gateway

feat: Allow additional "actions/operations" matching in SecurityPolicy authorization rules

Open

#7 678 ouverte le 5 déc. 2025

Voir sur GitHub
 (7 commentaires) (0 réactions) (0 assignés)Go (802 forks)auto 404
help wantedkind/enhancementkind/feature

Métriques du dépôt

Stars
 (2 871 stars)
Métriques de merge PR
 (Métriques PR en attente)

Description

Description: Right now the AuthorizationRule model used in SecurityPolicy is based on principal/operation combo, with operation allowing only to match HTTPMethod. That is a direct limitation compared to what you can do in "native" Envoy, where RBAC "rules" consist of a "permissions/principals" combo with "permissions" defining a lot a different actions matching (header, url_path, destination_ip...). Let's consider the following Envoy exemple :

                  permissions:
                    - or_rules:
                        rules:
                          - header:
                              name: ":authority"
                              string_match:
                                exact: <DOMAIN_1>
                          - header:
                              name: ":authority"
                              string_match:
                                exact: <DOMAIN_2>
                  principals:
                    - sourced_metadata:
                        metadata_source: DYNAMIC
                        metadata_matcher:
                          filter: envoy.filters.http.jwt_authn
                          path:
                            - key: google_jwt_payload
                            - key: email
                          value:
                            string_match:
                              exact: <IDENTITY>

To my understanding you have no way to replicate such a global RBAC at Gateway level with EnvoyGateway, all you can do is define it at route level by moving the header matching part in HTTPRoute.

Im not sure why the approach was different originally and "permissions" concept was not mirrored in SecurityPolicy "rules" but shouldn't we consider that "operation" has to match "permissions" feature-wise and allow to define the same kind of actions matching (header, url_path, destination_ip...)?

Guide contributeur