Support fined-grained access control in SecurityPolicy

zhaohuabing commented 9 months ago

Relates to

https://github.com/envoyproxy/gateway/issues/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:https://github.com/envoyproxy/envoy/issues/7913

[x] Allow/Deny IP Subnets
[ ] Authorization based on JWT claim
[ ] Authorization based on Basic Auth Username https://github.com/envoyproxy/gateway/issues/2947
[ ] Authorization based on client cert
[ ] Authorization based on identity extracted from an arbitrary HTTP header

arkodg commented 8 months ago

@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 commented 8 months ago

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.

https://github.com/envoyproxy/envoy/issues/7913#issuecomment-522095907 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 commented 7 months ago

@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 commented 7 months ago

@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 commented 7 months ago

@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 commented 7 months ago

@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 commented 7 months ago

@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 commented 7 months ago

thanks for sharing your use case @zetaab

To only allow specific claims, we can include this field within jwt within SecurityPolicy
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 commented 7 months ago

@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 commented 5 months ago

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 commented 5 months ago

@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.

https://github.com/envoyproxy/gateway/pull/3138

envoyproxy / gateway