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

HashiCorp Vault: Add token rotation mechanism #3610

Closed
paullatzelsperger opened this issue Nov 15, 2023 · 2 comments · Fixed by #3782
Closed

HashiCorp Vault: Add token rotation mechanism #3610

paullatzelsperger opened this issue Nov 15, 2023 · 2 comments · Fixed by #3782
Assignees
Labels
enhancement New feature or request good first issue Good for newcomers
Milestone

Comments

@paullatzelsperger
Copy link
Member

paullatzelsperger commented Nov 15, 2023

Feature Request

HashiCorp Vault (HCV) supports multiple types of tokens to authenticate. So far, we've only ever used the root token, which has an infinite TTL and cannot be renewed. Using the root token is not recommended for obvious reasons, and might not even be possible in managed situations.

All other tokens have a finite TTL, thus they must be renewed. Non-renewable tokens exist, but they are not relevant here.

There are several ways to renew a token through the REST API:

  • renew a token (doc)
  • renew a token by its accessor (doc)
  • renew a token "itself" (doc)

The most useful to us will likely be either the accessor or the "self" renewal.

Which Areas Would Be Affected?

HashiCorp Vault extension

Why Is the Feature Desired?

Security: should not use root token
Convenience: could be impractical or even impossible to use root token (managed environments)
Necessity: all tokens other than the root token have a finite lifespan

Solution Proposal

  • the edc.vault.hashicorp.token property contains the non-root token
  • a new edc.vault.hashicorp.token.ttl property is added containing the TTL in seconds, defaulting to 300 (5 min)
  • upon boot-up, the implementation checks if the token is renewable (via token lookup)
  • if the token is not renewable, a warning is logged
  • the token is immediately renewed, setting it to the configured TTL
  • a scheduled executor is created to run at TTL - 10 seconds (to account for transient network errors) that performs the renewal

Q&A

  • how will this behave in a clustered environment? most likely, it will just work, as the token itself will not change, only it's TTL. At worst, the token will get renewed much more often than necessary.
  • how does one create the "initial" token? This is out of scope of this issue
  • what happens if my runtime crashes? Most likely nothing, as the token string will still be the same. No reconfiguration is needed
  • Can I still use my root token? Yes, but you really shouldn't.
@paullatzelsperger paullatzelsperger added good first issue Good for newcomers feature_request New feature request, awaiting triage triage all new issues awaiting classification labels Nov 15, 2023
@paullatzelsperger paullatzelsperger added this to the Milestone 12 milestone Nov 15, 2023
@ndr-brt ndr-brt modified the milestones: Milestone 12, Milestone 13 Nov 15, 2023
@ndr-brt ndr-brt added enhancement New feature or request and removed feature_request New feature request, awaiting triage triage all new issues awaiting classification labels Nov 29, 2023
@hamidonos
Copy link
Contributor

@paullatzelsperger May I grab this issue?

@paullatzelsperger
Copy link
Member Author

@hamidonos knock yourself out :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment