-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
proposal: add a filter for injecting credentials into outgoing HTTP requests #21851
Comments
Could you give some more descriptions about the specific scenes? IMO, this may be useful in the mesh where the mTLS is disabled and authentication is necessary. |
We are also interested in this. We want/need Do you have a branch or image I could use for testing, if you're already implemented it, that is. |
Seriously, I need this feature, and I believe I'm not alone. There was an out of maintenance service (A) which runs robustly for years. But the service (B) this old service depends on, got updated, that introduced auth for existing apis. (A calls B) |
Sounds reasonable scene. |
I tagged this issue to Check this https://github.com/envoyproxy/envoy/blob/main/CONTRIBUTING.md#adding-new-extensions for more info. cc @yskopets |
It would be convenient if this can affect at route level. So in an istio mesh, we can create |
I'm keen to have this feature as well. There's a great use case for an outbound edge proxy, adding some protection against malicious code. Say for example an internal service A needs to access an external service like GitHub. Current practice is to inject a PAT into the container, which can be retrieved by either code execution on the container or privileged access at a node or cluster level. If we move the PAT token out of the container and/or cluster then we can protect against malicious actors with code execution. Authorisation could be managed with service account + outbound domain allowlists, with JWT validation? |
We would be very much interested in this feature getting implemented. +100 |
Can this be used to implement STS? E.g. exchange k8s service account for a Google service account when connecting to Google services? |
It seems that STS works like oauth Client Credentials Grant, so I think it would be possible to also include it in this new filter. However, the initial implementation will focus on oauth Client Credentials Grant flow. |
Our use case: Expose Kubernetes API server's OIDC metadata.
It'd be great to expose the OIDC metadata with Istio/envoy, without having to deploy an extra component to request the OIDC metadata from Kubernetes API using the ServiceAccount's token. Why? The OIDC metadata needs to be available for AWS IAM for AWS IAM Roles as Service Accounts (IRSA). This comes out-of-the-box in EKS, but in a private Kubernetes installation one needs to jump through hoops. |
When you talk about 'OIDC metadata', Do you mean ID token? Sounds this could be implemented as an extension tpye of the credentials injector, or use the existing 'Generic' credential extentension. #27769 |
No, I mean the OIDC metadata of the Kubernetes API Server. With AWS IRSA, one needs to create a new Identity Provider in AWS IAM, and its authentication can be OIDC. Then AWS IAM will retrieve the OIDC metadata of this Identity Provider, which in this case is the Kubernetes API server. Nowdays Kubernetes API server provides the OIDC metadata out-of-the-box. The problem is, in some case like ours, the metadata endpoint requires authentication. Because AWS IAM requires the OIDC metadata be publicly available, one needs to configure a proxy which provides AWS IAM with the OIDC metadata. In this case this proxy will authenticate to the Kubernetes API server OIDC endpoint using the ServiceAccount's credentials (Bearer token). It looks like this: ❯ curl https://public-proxy-hostname.example.com/.well-known/openid-configuration
{"issuer":"https://public-proxy-hostname.example.com","jwks_uri":"https://public-proxy-hostname.example.com/jwks","response_types_supported":["id_token"],"subject_types_supported":["public"],"id_token_signing_alg_values_supported":["RS256"]} And here the Now were are deploying our own simple proxy web server implementation for |
I'd be interested in this as well. Is there already a rough idea for when the work in #30850 might get released? |
i should imagine it will be included in the next release |
we are interesting in using it as upstream filter. For those apis that could be weight routing. |
Title: Add a filter for injecting credentials into outgoing HTTP requests
Description:
It would be conventient to have a standard filter that can inject credentials into outgoing HTTP requests (as a value of
Authorization
header).The most common use cases:
The primary focus of this proposal is on injecting OAuth2 access token credential.
Proposal:
Add an HTTP filter with the following configuration model:
If the list of rules is empty, the filter will have no effect.
With regards to OAuth2 support:
client_id
andclient_password
Usage examples:
Injecting OAuth2 access token
Injecting basic auth credentials
Injecting opaque bearer token credential
The text was updated successfully, but these errors were encountered: