You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the feature request/bug
The Kubernetes Auth Method plugin maintains a token_reviewer_jwt configuration option which is being used as a predefined token used to access the TokenReview API to validate other JWTs during login.
If this configuration option is not set then the passed in JWT token is used. This token is sent by Vault. Code
// If we have a configured TokenReviewer JWT use it as the bearer, otherwise// try to use the passed in JWT.bearer:=fmt.Sprintf("Bearer %s", jwt)
iflen(t.config.TokenReviewerJWT) >0 {
bearer=fmt.Sprintf("Bearer %s", t.config.TokenReviewerJWT)
}
bearer=strings.TrimSpace(bearer)
To then sent in the preconfigured configuration JWT token to Kubernetes as the Bearer, and to verify the response of this TokenReview request to the previously constructed internal serviceAccount struct could bring invalid behaviour.
The problem
Even though the sent-in (through request) JWT token should be used: the configured JWT token (token_reviewer_jwt) is used as authentication when sending a TokenReview request to the kube-apiserver.
Describe the solution you'd like
Remove the token_reviewer_jwt configuration option completely and use the sent in (through request) JWT token to validate locally AND as a Bearer when sending a TokenReview request to the kube-apiserver.
Alternatives
Support various deployment models, (for external clusters) support the refreshing of the token_reviewer_jwt through f.e. TokenRequest API rather than a static secret-based service account token. Or different ways to integrate with Kubernetes outside of the TokenReview API such as: OIDC issuer validation.
Side effects
When using this solution, every single service account token attached to the entity attempting to Authenticate to Vault will require to have the system:auth-delegator RoleBinding attached to it. This is necessary to access the TokenReview API.
Other notes
This issue could supersede #12937 (and underlying issues). Removing the need of a cached token reader.
The text was updated successfully, but these errors were encountered:
Describe the feature request/bug
The Kubernetes Auth Method plugin maintains a
token_reviewer_jwt
configuration option which is being used as a predefined token used to access the TokenReview API to validate other JWTs during login.If this configuration option is not set then the passed in JWT token is used. This token is sent by Vault.
Code
To then sent in the preconfigured configuration JWT token to Kubernetes as the Bearer, and to verify the response of this TokenReview request to the previously constructed internal
serviceAccount
struct could bring invalid behaviour.The problem
Even though the sent-in (through request) JWT token should be used: the configured JWT token (
token_reviewer_jwt
) is used as authentication when sending a TokenReview request to the kube-apiserver.Describe the solution you'd like
Remove the
token_reviewer_jwt
configuration option completely and use the sent in (through request) JWT token to validate locally AND as a Bearer when sending aTokenReview
request to the kube-apiserver.Alternatives
Support various deployment models, (for external clusters) support the refreshing of the token_reviewer_jwt through f.e. TokenRequest API rather than a static secret-based service account token. Or different ways to integrate with Kubernetes outside of the TokenReview API such as: OIDC issuer validation.
Side effects
When using this solution, every single service account token attached to the entity attempting to Authenticate to Vault will require to have the
system:auth-delegator
RoleBinding attached to it. This is necessary to access the TokenReview API.Other notes
This issue could supersede #12937 (and underlying issues). Removing the need of a cached token reader.
The text was updated successfully, but these errors were encountered: