First pass at JWT auto-deletion flag #11969

tdsacilowski · 2021-06-30T21:45:41Z

Fixes #11968

Still need to write tests.

hashicorp-cla · 2021-06-30T21:45:45Z

All committers have signed the CLA.

calvn · 2021-06-30T21:57:03Z

Are there potential (re-)authentication issues that could arise if we don't delete a stale JWT?

calvn · 2021-06-30T21:58:26Z

website/content/docs/agent/autoauth/methods/jwt.mdx

@@ -17,3 +17,7 @@ JWT to perform a reauthentication.
 - `path` `(string: required)` - The path to the JWT file

 - `role` `(string: required)` - The role to authenticate against on Vault
+
+- `remove_jwt_after_reading` `(bool: optional, defaults to true)` -


Can we flip this around and have it be keep_after_reading or something along those lines? This way the default value is also the zero value (false).

I thought about that but I thought it more prudent to retain the current default behavior and opt-out if needed. I'd assume that in most cases, the default behavior is more appropriate. This change is mostly to allow for using Kubernetes bound service account tokens with JWT auth. In this use case, Kubernetes automatically rotates the JWT based on a configurable TTL.

keep_after_reading with it being defaulted false should still retain the current behavior though. Note that we're flipping the naming and also the default so keeping the file would still be an opt-in. We'd only not delete the file if this gets set to true explicitly.

Ah ok, I see what you mean. I was following the same model that the AppRole auto-auth was using but I can change this around if it makes more sense.

I think keep_jwt_after_reading works, but I am not convinced that it needs to be this verbose. I think any of : skip_jwt_cleanup, no_jwt_cleanup, preseve_jwt could probably work well.

I actually like remove_jwt_after_reading for its consistency with AppRole's option: https://www.vaultproject.io/docs/agent/autoauth/methods/approle#remove_secret_id_file_after_reading

IMO the bar to break from this pattern needs to be higher than making it terser. If it wasn't for the prior art, I would 100% agree with both the flip + naming comments above, but they're minor nits and they're secondary to preventing confusion for consumers.

tdsacilowski · 2021-06-30T22:12:22Z

Are there potential (re-)authentication issues that could arise if we don't delete a stale JWT?

I wouldn't think so. JWTs should have an expiration set so if re-auth is attempted with an expired JWT auth should fail. In this scenario, the underlying system that is responsible for delivering an updated JWT (e.g. Kubernetes) should have provided a newer JWT. But I may be missing some of the finer points here.

calvn · 2021-06-30T22:20:53Z

It looks like ingressToken() relies on the absence on the file to short-circuit from the function, so on non-kubernetes workflows in which someone opts in for this I could see Agent doing the opposite -- reading the file every 500ms. We do end up comparing the value of this token with the existing one so it's mostly benign, but it does result in more filesystem reads.

arianvp · 2021-10-13T20:11:17Z

As an alternative of using the absence as the edge trigger; we could use inotify to see when the token file is modified. That sounds like the better design here. This would be really cool to have as it makes a dedicated kubernetes auth method redundant! Since Kubernetes 1.21 k8s even has a /.well-known/openid-configuration endpoint so you can use the jwt auth method without any complicated configuration. Would be really cool if this could land

benashz · 2021-10-15T13:35:13Z

As an alternative of using the absence as the edge trigger; we could use inotify to see when the token file is modified. That sounds like the better design here. This would be really cool to have as it makes a dedicated kubernetes auth method redundant! Since Kubernetes 1.21 k8s even has a /.well-known/openid-configuration endpoint so you can use the jwt auth method without any complicated configuration. Would be really cool if this could land

That's a very interesting idea. I don't really see kubernetes being made redundant, rather it could be extended to support openid-connect-tokens as alternative to relying on the k8s TokenReview API.

arianvp · 2021-10-15T16:06:28Z

Just to avoid confusion. Note that the document you're linking to is the wrong side of the coin. That document is about kubernetes utilising an external openid connect provider to allow externals to authenticate to K8s.

We're talking about https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery instead.

Which is the opposite of that. Allow serviceaccounts to connect to external services like vault by registering the Kubernetes apiserver as an OpenID connect provider in vault

arianvp · 2021-10-18T12:10:03Z

@benashz here is the full example using the jwt auth method including an explanation why I'd like a (variant) of this PR merged.

https://github.com/arianvp/vault-k8s-jwt-auth-demo

aelbarkani · 2022-06-17T20:24:59Z

@arianvp @tdsacilowski since this PR was not merged, did you find a workaround ?

tomhjp

Taking another look as there has been some renewed interest in this. @tdsacilowski I'm happy to take this on if you'd prefer not to pick this up again.

tomhjp · 2022-07-18T14:49:44Z

website/content/docs/agent/autoauth/methods/jwt.mdx

@@ -17,3 +17,7 @@ JWT to perform a reauthentication.
 - `path` `(string: required)` - The path to the JWT file

 - `role` `(string: required)` - The role to authenticate against on Vault
+
+- `remove_jwt_after_reading` `(bool: optional, defaults to true)` -


I actually like remove_jwt_after_reading for its consistency with AppRole's option: https://www.vaultproject.io/docs/agent/autoauth/methods/approle#remove_secret_id_file_after_reading

IMO the bar to break from this pattern needs to be higher than making it terser. If it wasn't for the prior art, I would 100% agree with both the flip + naming comments above, but they're minor nits and they're secondary to preventing confusion for consumers.

command/agent/auth/jwt/jwt.go

* Unit test to test default behaviour, and config parsing for delete_jwt_after_reading option * Slow down read period of token when we're not deleting it to 1 minute. This is fast enough for the shortest TTL possible in Kubernetes (10m), which seems like a sensible default. We may need to make this period configurable in the future though. * Remove usage of the deprecated ioutil library

tvoran

I'm ambivalent about the option name.

command/agent/auth/jwt/jwt.go

First pass at JWT auto-deletion flag

4572a9f

tdsacilowski requested a review from a team June 30, 2021 21:45

calvn reviewed Jun 30, 2021

View reviewed changes

heatherezell added ecosystem agent labels Jul 21, 2021

tomhjp reviewed Jul 18, 2022

View reviewed changes

tdsacilowski requested a review from taoism4504 as a code owner July 21, 2022 15:33

tomhjp added 2 commits July 21, 2022 16:38

Merge branch 'main' into Enable-JWT-auto-deletion-to-be-optional

e2def7f

Add changelog note

033c1cf

tomhjp requested review from benashz and calvn July 21, 2022 15:40

tomhjp added 2 commits July 21, 2022 16:44

Changelog typo

c713a6b

Another changelog typo

d07e975

tomhjp requested a review from tvoran July 22, 2022 15:47

tvoran approved these changes Jul 22, 2022

View reviewed changes

command/agent/auth/jwt/jwt.go Outdated Show resolved Hide resolved

Remove unnecessary second defaulting of value

174eaf8

tomhjp enabled auto-merge (squash) July 25, 2022 13:33

tomhjp merged commit dac99be into main Jul 25, 2022

tomhjp deleted the Enable-JWT-auto-deletion-to-be-optional branch September 12, 2022 09:17

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

First pass at JWT auto-deletion flag #11969

First pass at JWT auto-deletion flag #11969

tdsacilowski commented Jun 30, 2021

hashicorp-cla commented Jun 30, 2021 •

edited

Loading

calvn commented Jun 30, 2021

calvn Jun 30, 2021

tdsacilowski Jun 30, 2021

calvn Jun 30, 2021 •

edited

Loading

tdsacilowski Jun 30, 2021

benashz Oct 18, 2021

tomhjp Jul 18, 2022

tdsacilowski commented Jun 30, 2021

calvn commented Jun 30, 2021 •

edited

Loading

arianvp commented Oct 13, 2021

benashz commented Oct 15, 2021

arianvp commented Oct 15, 2021 •

edited

Loading

arianvp commented Oct 18, 2021

aelbarkani commented Jun 17, 2022 •

edited

Loading

tomhjp left a comment

tomhjp Jul 18, 2022

tvoran left a comment

First pass at JWT auto-deletion flag #11969

First pass at JWT auto-deletion flag #11969

Conversation

tdsacilowski commented Jun 30, 2021

hashicorp-cla commented Jun 30, 2021 • edited Loading

calvn commented Jun 30, 2021

calvn Jun 30, 2021

Choose a reason for hiding this comment

tdsacilowski Jun 30, 2021

Choose a reason for hiding this comment

calvn Jun 30, 2021 • edited Loading

Choose a reason for hiding this comment

tdsacilowski Jun 30, 2021

Choose a reason for hiding this comment

benashz Oct 18, 2021

Choose a reason for hiding this comment

tomhjp Jul 18, 2022

Choose a reason for hiding this comment

tdsacilowski commented Jun 30, 2021

calvn commented Jun 30, 2021 • edited Loading

arianvp commented Oct 13, 2021

benashz commented Oct 15, 2021

arianvp commented Oct 15, 2021 • edited Loading

arianvp commented Oct 18, 2021

aelbarkani commented Jun 17, 2022 • edited Loading

tomhjp left a comment

Choose a reason for hiding this comment

tomhjp Jul 18, 2022

Choose a reason for hiding this comment

tvoran left a comment

Choose a reason for hiding this comment

hashicorp-cla commented Jun 30, 2021 •

edited

Loading

calvn Jun 30, 2021 •

edited

Loading

calvn commented Jun 30, 2021 •

edited

Loading

arianvp commented Oct 15, 2021 •

edited

Loading

aelbarkani commented Jun 17, 2022 •

edited

Loading