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

[jlephay]

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...)?

[zhaohuabing]

Hi @jlephay Envoy’s API is extremely flexible and geared toward controller applications, while the EG API is more opinionated and optimized for human users.

Would you mind elaborating on your specific use case? That’ll help us figure out how (or whether) it can be supported within the EG API.

[jlephay]

Sure @zhaohuabing . My specific use-case was to define authorization based on a combination of principal(s) + destinnation(s) (":authority" header in my case).
In my original Envoy configuration i was achieving that by defining a Global RBAC at Gateway level (see complete exemple in my original post).
I was able te replicate that somehow with EnvoyGateway by creating one HTTPRoute per destinnation(s) group (matching the correct headers) and then associating one SecurityPolicy to each one of those HTTPRoute with the expected principal(s).

For exemple :

---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: <HTTPROUTE_NAME>
spec:
  parentRefs:
    - name: <GW_NAME>
  rules:
  - matches:
    - headers:
      - name: <HEADER_NAME>
        type: RegularExpression
        value: "^<HEADER_DOMAIN_REGEXP>$"
    backendRefs:
    - group: gateway.envoyproxy.io
      kind: Backend
      name: <BACKEND_NAME>
	  
---
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: <SP_NAME>
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: <HTTPROUTE_NAME>
  jwt:
    providers:
    - name: google-jwt
      issuer: https://accounts.google.com
      remoteJWKS:
        uri: https://www.googleapis.com/oauth2/v3/certs
      extractFrom:
        headers:
        - name: X-Goog-Iap-Jwt-Assertion
  authorization:
    defaultAction: Deny
    rules:
    - name: "allow"
      action: Allow
      principal:
        jwt:
          provider: google-jwt
          claims:
          - name: email
            values: ["<IDENTITY>"]

But thats seems to be an unnecessary limitation and a legit use-case outside of my specific context. You should be able to have a single route on your gateway and apply authorization globally based on headers. It doesnt seem natural to me to have to create individuals HTTPRoutes just to implement the header matching, since you will end up "artificially" with a lot of HTTPRoute/SecurityPolicy using the same Backend just to define those RBAC. In the end I dont necessarily want to define different routes, I just want to define different authorizations,

I may be wrong and it could be intended, Id be glad to have your feedback on that. Thx again.

[zhaohuabing]

This can be supported by introducing a Host field in the Operation API.

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: <SP_NAME>
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: <HTTPROUTE_NAME>
  authorization:
    defaultAction: Deny
    rules:
    - name: "allow"
      action: Allow
      operation:
         hosts: 
         - foo.bar.com
         - *.example.com
      principal:
        jwt:
          provider: google-jwt
          claims:
          - name: email
            values: ["<IDENTITY>"]

[jlephay]

It could be a solution yeah, though in my case I woud need it to be more flexible and allow multiple hostnames matching in a single policy (including wildcard ones), exemple:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: <SP_NAME>
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: <HTTPROUTE_NAME>
  authorization:
    defaultAction: Deny
    rules:
    - name: "allow"
      action: Allow
      operation:
         hosts: 
		 - foo.bar.com
		 - *.xyz.com
      principal:
        jwt:
          provider: google-jwt
          claims:
          - name: email
            values: ["<IDENTITY>"]

I guess another way to see it would be to have a more "generic" approach, closer to what you can do in RBAC permissions and define header matching based on regexp pattern, something like :

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: <SP_NAME>
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: <HTTPROUTE_NAME>
  authorization:
    defaultAction: Deny
    rules:
    - name: "allow"
      action: Allow
      operation:
	    or_rules:
	      headers:
          - name: Host
            type: Exact
            value: "foo.bar.com:443"
          - name: Host
            type: RegularExpression
            value: "^.*.xyz.com:443$"
      principal:
        jwt:
          provider: google-jwt
          claims:
          - name: email
            values: ["<IDENTITY>"]

Im not sure which one is better, "hosts" approach is definitly more "user-friendly" and readable. Headers approach is more flexible and could be used outside of my specific hostname use-case.
Or it could be both :-)

[arkodg]

doesnt header matching already exist

gateway/api/v1alpha1/authorization_types.go

Line 112 in 1b88e71

Headers []AuthorizationHeaderMatch `json:"headers,omitempty"`

?

its exact match for now, but can be enhanced

gateway/api/v1alpha1/authorization_types.go

Line 132 in 1b88e71

// Only exact matches are supported for now. It should be good enough for authorization use cases. If use cases for other

[jlephay]

Interesting. Header matching is indeed possible but only in Principal API it seems. It would (partially) work for me but it would also be a bit counter-intuitive to use that to match "Host" since it has nothing to do with user identity.
The other issue beeing that in current implementation if multiple headers are specified, all headers must match for the rule to match, which is a bit strange since it's not the way the equivalent "value" array in JWTPrincipal behaves ("If multiple values are specified, one of the values must match for the rule to match"). In my case that's not what I want to achieve, I want to have some sort of "or_rules" and allow a set of principal to access any of the domains/headers.
Any way, I could understand that adding that Header support over-complicates things and that you prefer to go "the hosts way".

[zhaohuabing]

It could be a solution yeah, though in my case I woud need it to be more flexible and allow multiple hostnames matching in a single policy (including wildcard ones)

Yeah, hosts should be a list and support wildcards. I updated the example in my previous comment.