API: authorization api for jwt claims

[zhaohuabing]

API for #3367

A SecurityPolicy enforcing authz on a Gateway resource based on jwtClaims (sub=jason or sub=alice) and iss=foo.bar.com:

  apiVersion: gateway.envoyproxy.io/v1alpha1
  kind: SecurityPolicy
  metadata:
    namespace: envoy-gateway
    name: policy-for-gateway 
  spec:
    targetRef:
      group: gateway.networking.k8s.io
      kind: Gateway
      name: gateway-1
    authorization:
      defaultAction: Deny
      rules:
      - action: Allow
        principal:
          jwt:
            claims:
            - name: sub
              values: [jason, alice]
            - name: iss
              values: [foo.bar.com]

A SecurityPolicy enforcing authz on a HTTPRoute resource based on scope contains "read::message"

  apiVersion: gateway.envoyproxy.io/v1alpha1
  kind: SecurityPolicy
  metadata:
    namespace: envoy-gateway
    name: policy-for-route 
  spec:
    targetRef:
      group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: route-1
    authorization:
      defaultAction: Deny
      rules:
      - action: Allow
        principal:
          jwt:
            sopes: [read::message]

Scopes and claims can be used together, they're And-ed if both are specified.
A SecurityPolicy enforcing authz on a HTTPRoute resource based on scope contains "read::message" and a custom claim message_type:

  apiVersion: gateway.envoyproxy.io/v1alpha1
  kind: SecurityPolicy
  metadata:
    namespace: envoy-gateway
    name: policy-for-route 
  spec:
    targetRef:
      group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: route-1
    authorization:
      defaultAction: Deny
      rules:
      - action: Allow
        principal:
          jwt:
            sopes: [read::message]            
            claims:
            - name: message_type
              values: [foo, bar]

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 67.96%. Comparing base (5998980) to head (e43f31a).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4009      +/-   ##
==========================================
+ Coverage   67.95%   67.96%   +0.01%     
==========================================
  Files         189      189              
  Lines       23103    23103              
==========================================
+ Hits        15699    15703       +4     
+ Misses       6281     6279       -2     
+ Partials     1123     1121       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[zetaab]

Seems good from my perspective

[zhaohuabing]

You may have better names for the field JWT and type JWTPrincipal :-) @arkodg @missBerg

[zhaohuabing]

I prefer using string for bool as "true"/"false" and integer if we need these types in the future. Any is too flexible, as it can represent nested structures besides simple types, which we won't use.

[denniskniep]

Does it make sense to specify the Matcher instead of the ClaimValueType? I think that would bring more flexibility.

i.e.

type JWTClaim struct {	
	Name string `json:"name"`
	ValueMatcher JWTClaimValueMatcher `json:"valueMatcher "`
}

type JWTClaimValueMatcher struct {
     equalsAny *JWTClaimValues  `json:"valueType,omitempty"`     
     notEqualsAny *JWTClaimValues  `json:"valueType,omitempty"`
     includesAll *JWTClaimValues  `json:"valueType,omitempty"`
     includesAny *JWTClaimValues  `json:"valueType,omitempty"`
     notIncludesAny *JWTClaimValues  `json:"valueType,omitempty"`
}

type JWTClaimValues struct {
     Values []string `json:"values"`
}

• equalsAny (assume claim is single string)
• notEqualsAny (assume claim is single string)
• includesAll (assume claim is string array)
• includesAny (assume claim is string array)
• notIncludesAny (assume claim is string array)
• ...

If necessary for a certain Matcher we could specify different properties

What do you think?

[zhaohuabing]

Hi @denniskniep In theory, we could make this API as flexible as the Envoy RBAC API, but I would like to make this API simpler and easier to understand as it's a user-facing API.

I believe the normal use cases for JWT claim based authorization is that we just compare wether the claims equal with any of the specified values (equalsAny). I can't think of any use cases for a substring matching.

Scope comparison is a bit different, all specified scopes must exist in the JWT. It's handled in a dedicated API field.

For the not use case, it can be accomplished with a Allow default action and a Deny rule:

      rules:
      - default: Allow
      - action: Deny
        principal:
          jwt:
            claims:
            - name: user
              values: [jason, alice]

[arkodg]

LGTM thanks Huabing !

[zirain]

--- FAIL: TestSecurityPolicyTarget (0.13s)
    --- FAIL: TestSecurityPolicyTarget/authorization-missing_principal (0.00s)
        securitypolicy_test.go:1126: Unexpected response while creating SecurityPolicy; got err=
            SecurityPolicy.gateway.envoyproxy.io "sp-1725430984228589885" is invalid: [spec: Invalid value: "object": if authorization.rules.principal.jwt is used, jwt must be defined, spec.authorization.rules[0].principal.jwt: Invalid value: "object": at least one of claims or scopes must be specified]
            ;missing strings within error=["at least one of clientCIDRs or jwt must be specified"]
FAIL
FAIL	github.com/envoyproxy/gateway/test/cel-validation	7.719s