Skip to content
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

Option to relax bound_issuer validation (domain vs URL) #74

Open
thomasgl-orange opened this issue May 16, 2023 · 0 comments
Open

Option to relax bound_issuer validation (domain vs URL) #74

thomasgl-orange opened this issue May 16, 2023 · 0 comments

Comments

@thomasgl-orange
Copy link

Is your feature request related to a problem? Please describe.
GitLab is in the process of modifying the JWT tokens it provides in CI jobs, and in particular it is changing the iss (Issuer) claim value:

  • it was gitlab.something.com in old-style tokens (deprecated but widely used)
  • it is https://gitlab.something.com in new tokens (obtained via a new pipeline keyword)

It's a legitimate change, but transition is painful in the context of GitLab/Vault interactions, because on Vault side it requires two JWT auth URLs; one for each style of tokens (for each specific bound_issuer). GitLab users (pipelines authors) must take into account that when they update the way they obtain a JWT token, they must also adapt their target Vault auth URL. In our case it will affect many people across many project/teams.

Describe the solution you'd like
I'd like to have the option to configure JWT auth plugin only once in Vault, in such a way it tolerates both forms of Issuer claim (FQDN and https://FQDN). It could be a boolean option to enable the special case (something like "ignore protocol in iss: claim if bound_issuer is a domain name"), or the ability to provide a list of bound_issuers.
At least the "special case" option would not be too difficult to take into account in cap/jwt, I think, here:

cap/jwt/jwt.go

Line 141 in 6d1e00a

if expected.Issuer != "" && expected.Issuer != claims.Issuer {

Describe alternatives you've considered
The alternative is to live with two JWT auth URL in Vault during the transition period, until deprecated tokens disappear, like this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant