Open zhaohuabing opened 9 months ago
@zhaohuabing
paths
and methods
be limited by the HTTPRoute
match fields ?principal
be limited by the issuer
field in JWT https://gateway.envoyproxy.io/v0.6.0/api/extension_types/#jwtprovider ?
- can't the
paths
andmethods
be limited by theHTTPRoute
match fields ?
We probably shouldn't go this route because:
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 theissuer
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
@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?
@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
@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
@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
@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
thanks for sharing your use case @zetaab
claims
, we can include this field within jwt
within SecurityPolicy
ipAllowList
/ ipDenyList
within ClientTrafficPolicy
/ SecurityPolicy
both these APIs will translate intent into envoy rbac filter
@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
)
- To only allow specific
claims
, we can include this field withinjwt
withinSecurityPolicy
@arkodg Can we include this in v1.1.0? it's a very nice feature and I dare say essential to the gateway!
@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.
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
andxRoute
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
Reference:https://github.com/envoyproxy/envoy/issues/7913