-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: External Authorization Support #140
Comments
hi @bcelenza , is there a open PR for this? Would be really interested to check this feature. |
Hey @abhijitherekar. We're still currently researching how we'll implement this feature in App Mesh. We'll update this issue when we have an API proposal and will happily accept feedback / answer any questions you post here. |
Hey folks! We're working on this feature, and looking for your input. 5 easy questions below -- please feel free to answer any that pertain to your needs.
Thanks in advance! |
Hi Brian. My team is currently considering migrating to AppMesh, but we would require this feature before we could use the Virtual Gateway for ingress to the mesh. Our requirement is for an auth subrequest for ingress traffic, similar to how the NGINX auth subrequest works. To provide this capability we have been looking at running our own Envoy or NGINX service that has an Envoy sidecar so that it can proxy requests to services within the mesh.
|
Thanks for the feedback @RyanFrench! Can you tell me a little bit more about how you authorize a caller once you’ve authenticated them? For example, do you do authorization based on HTTP verb and path, or is it more complex than that? Additionally, have you looked into Open Policy Agent for both the authN and authZ functionality? I’m curious how it compares to your existing implementation. |
Once the call is authenticated we have very simple information within the JWT that points to the permissions of the caller for each resource they are allowed access to. This typically gives read/write access to a specific resource ID, and the individual service will determine if the service is allowed to read or modify the resource based on what the path does. We haven't looked into the Open Policy Agent. It does look interesting although I think it's a little bit different in terms of the implementation. Our implementation is done in code, not via configuration. |
I would like to have two instances of my app, e.g. two different kubernetes In this way, I can configure what users are belonging to an early-test-group, so I can have early features in one Deployment, but only stable features in the other Deployment. Yes, it would be good if I can use OpenPolicyAgent - but I have not understood if I an achieve this setup yet. |
Hey @jlpettersson, neat idea. Because Open Policy Agent typically runs on the destination service, I don't think routing based on a JWT claim would work at a Virtual Service -> Virtual Router level in App Mesh (these resources actually result in client configuration). For your use case, here's what I think would work:
Does this sound about like what you're looking for? Alternatively, we're also looking into native support for JWT (#81) at a later date, which could be an alternative way to do what you're describing (likely using a Virtual Gateway again). |
Hello, Customers can configure External Authorization using a local sidecar agent that supports Envoy's GRPC Client API. The Authorization sidecar agent could be an Open Policy Agent or customers could bring their own sidecar. API Design
We'd love to hear your feedback on this proposal to see whether it fit your use cases in the comments. |
@rajal-amzn hello, I have a scenario where I'm using Envoy and using the ext_authz filter to talk to an opa instance on the host. In our setup we have envoy authenticating end-users via Our config looks like:
Will that scenario be covered by your proposal? |
Hey @danielpops. In this initial iteration of external authorization support I don't believe we would support the |
One of the use case is to verify external signed http requests. It requires comparison of the Envoy's I hope there'll be an option to enable this with app mesh's extauthz implementation. - name: envoy.filters.http.ext_authz
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz
transport_api_version: V3
grpc_service:
envoy_grpc:
cluster_name: api-gateway-ext-authz
timeout: 0.25s
with_request_body: # 👈
max_request_bytes: 10240 # 👈
allow_partial_message: false # 👈
failure_mode_allow: false
include_peer_certificate: true |
When using client certificates to authenticate to the mesh, how will the client information be presented to the external authz interface? Will AppMesh support Envoy's X-Forwarded-Client-Cert? |
@danielpops I'm currently testing App Mesh for some deployments and it does seem AppMesh doesn't set forward_client_cert_details so Sadly, this is limiting the usefulness of mTLS in App Mesh a lot... Any workarounds? |
@CrawX @danielpops Thanks for pointing this out. I am also going down the route myself of trying to put Envoy with an opa sidecar in an Appmesh mutated podspec to sit in front of the Appmesh Envoy sidecar for ext_authz stuffs. I also noticed in the opa-agent the |
This would be an immensely useful feature to be able to activate this flag somehow. I'm running Fargate on EKS and App Mesh is the only option (seeing as Istio etc are not supported right now). The only way I could see this working is to run a patched version of envoy that has a different default for this flag baked in. But I'm relying on IRSA for permissions which is only available in the (closed-source) default envoy image as #182 is not merged upstream yet. So no way to reproduce this build. Not sure how to proceed yet, not having mTLS (incl. |
Late to the party, but our answers to your questions:
Primarily from outside the mesh.
JWT, arbitrary
Currently, they're the same across a large subset of services. There are services, however, that don't require the auth policies. The auth policies apply to anything that has external ingress through the mesh.
The external auth service is deployed as a k8s daemonset. A sidecar approach is feasible, just not as efficient.
We're rolling our own solution. In our particular case, we need to do request signing validation so we need access to the request body as well. |
hello, any timelines for this feature ? |
[Request to AppMesh team]Can you please provide an update on this LONG OPEN ISSUE (~ 2Y 3M)? Would really like to see how AppMesh team is planning to implement access control? Any progress being done? ETA? Any AWS or 3rd party document/blog we can refer to see/learn how to implement/integrate AWS AppMesh/Envoy with external Authorization? @shwetasahuit |
Any updates on this issue? @shsahu @suniltheta ? Thanks a ton! |
Upvoting. This feature will allow the Aperture Flow Control platform to work with AWS AppMesh. Aperture provides advanced flow control features such as prioritized load shedding (adaptive concurrency limiting) and distributed rate limiting. It leverages external authz protocol to make per-request decisions. See documentation and how it integrates with Istio Mesh. |
Any update/roadmap on AppMesh to support cross cutting concerns such as external Auth/Rate limit etc? |
@vnid, it's not on our immediate roadmap. We continue collecting customer feedback that will help us prioritize external Auth and other feature requests. |
More answer to the questionnaire above:
Right now for traffic from outside the mesh, though I'm sure we'll have use cases for traffic within the mesh in future.
Primarily JWT, but it's likely that X.509 would come in the picture in the near future.
Initial idea is as a sidecar, however as daemonset if that is more cost effective or if it improves latency.
Open Policy Agent is the front runner right now. |
Hi team, any plans to support AWS VPC Lattice integration? |
If you want to see App Mesh implement this idea, please upvote with a 👍.
Tell us about your request
Once a client has been identified (e.g. via a certificate, request token, or IP address), it would be useful to perform an authorization check to further restrict the scope of access to a given service. For example, restricting certain identified clients to only specific HTTP verbs and paths.
Envoy supports authorizing a client using an external authorization provider, which allows you to bring an existing solution in (such as Open Policy Agent), or write your own.
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
After identifying a caller, there is a need to further restrict access to an endpoint such that only certain actions may be performed. Authorization can be performed on HTTP for example by only allowing GET requests on specific paths.
Being able to authorize a client through a separate application provides a flexible interface that can be customized to fit many needs.
Are you currently working around this issue?
This issue can be worked around by implementing authorization in the application code, or some other middle hop, but represents additional complexity that doesn't fit the primary benefits and uses of a service mesh.
The text was updated successfully, but these errors were encountered: