Support fined-grained access control in SecurityPolicy

[zhaohuabing]

Relates to

#1845

What is this?

EG can leverage RBAC for implementing fine-grained access control, at both the Gateway and xRoute level.

The principal, obtained through the authentication process (such as OIDC, JWT, etc.), serves as the basis for defining access control policies. Source IP-based access control can also be supported in this model.

The below is roughly how API will look like, but it's just an initial idea and definitely needs more input.

API outline

kind: SecurityPolicy
metadata:
  name: rbac-example
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: http-route
  jwt:   # a jwt or oidc configuration is needed to obtain the principal
  ......  
  authorization:
  - principals: ["john"]
    permissions:
      methods: ["GET", "POST"]
      paths: ["/foo", "/bar"]

Reference:envoyproxy/envoy#7913

• Allow/Deny IP Subnets
• Authorization based on JWT claim
• Authorization based on Basic Auth Username Extract username from basic auth and forward it to backends #2947
• Authorization based on client cert
• Authorization based on identity extracted from an arbitrary HTTP header

[arkodg]

@zhaohuabing

• can't the paths and methods be limited by the HTTPRoute match fields ?
• can't the principal be limited by the issuer field in JWT https://gateway.envoyproxy.io/v0.6.0/api/extension_types/#jwtprovider ?

[zhaohuabing]

• can't the paths and methods be limited by the HTTPRoute match fields ?

We probably shouldn't go this route because:

• It could get tricky, especially when the policy targets a gateway.
• Separate of concerns: SecurityPolicy and HTTPRoute may be created by different roles, such as app developers and administrators.

We can just remove the path out of the API because SecurityPolicy can target a xRoute.

• can't the principal be limited by the issuer field in JWT https://gateway.envoyproxy.io/v0.6.0/api/extension_types/#jwtprovider ?

Yes, we can. As the below links show, the Envoy RBAC filter can retrieve claims such as sub from the metadata generated by the JWT filter and use them as principals.

envoyproxy/envoy#7913 (comment)
https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/jwt_authn/v3/config.proto#envoy-v3-api-field-extensions-filters-http-jwt-authn-v3-jwtprovider-payload-in-metadata

[zetaab]

@zhaohuabing if you use api outline that is mentioned in first post, it does not support "action" mentioned in https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/rbac/v3/rbac.proto#config-rbac-v3-rbac

so instead the api spec should be something like

kind: SecurityPolicy
metadata:
  name: rbac-example
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: http-route
  jwt:   # a jwt or oidc configuration is needed to obtain the principal
  ......  
  authorization:
  - action: ALLOW # possible values ALLOW, DENY, LOG
    policies:
      policy1:
        principals:
        - <array of https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/rbac/v3/rbac.proto#envoy-v3-api-msg-config-rbac-v3-policy >
        permissions:
        - <array of https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/rbac/v3/rbac.proto#envoy-v3-api-msg-config-rbac-v3-permission >
        condition: # is this needed?

[arkodg]

@zetaab this feature has not been built out yet, you can use the existing fields in jwt for authz
https://gateway.envoyproxy.io/latest/api/extension_types/#jwtprovider

[zetaab]

@arkodg yep, but just wanted to mention that there can be multiple types of "action". So perhaps worth of including that as well.

Anyways I am really waiting for this feature, so just wanted to participate

[arkodg]

@zetaab can you also outline your use case here ? are you trying to perform authz based on claims ?
if thats the case, imo we can include a claims field with jwt

[zetaab]

@arkodg my use case is 1) I would like to have OIDC authentication (+JWT verify needed in envoy level?) 2) I would like to define that group X,Y,Z is allowed (others denied) to HTTPRoute or even in global level. Currently the claims can be included as http headers in http response towards upstream afaik. However, there is no way to block requests based on the claim values.

Another case: 1) JWT authentication 2) I want that only sub value X is allowed and others denied.

Third case: HTTPRoute requires one of the following: 1) OIDC auth (+jwt) OR 2) specified ip address. (this needs two action ALLOW policies. So authorization needs to be an array)

I think all of these can be done with envoyproxy RBAC module

[arkodg]

thanks for sharing your use case @zetaab

1. To only allow specific claims, we can include this field within jwt within SecurityPolicy
2. To only allow specific ip addresses, we can include a ipAllowList / ipDenyList within ClientTrafficPolicy / SecurityPolicy

both these APIs will translate intent into envoy rbac filter

[arkodg]

@guydc brought the use case of wanting to limit supported methods (send 401 status to unsupported http methods)
so it sounds like a top level authorization or acl field makes sense here which allows the user to create ALLOW / DENY rules with different types (method, claim, remoteCIDR)

[rooque]

1. To only allow specific claims, we can include this field within jwt within SecurityPolicy

@arkodg Can we include this in v1.1.0? it's a very nice feature and I dare say essential to the gateway!

[zhaohuabing]

@arkodg @zetaab @rooque @guydc Thanks for the great feedback! I've created an API draft based on our discussion. Feel free to check it out and leave your thoughts when you have time.

#3138