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

feat: explicit max ttl for secrets #199

Merged
merged 1 commit into from
Jul 3, 2024

Conversation

gsantos-hc
Copy link
Contributor

@gsantos-hc gsantos-hc commented May 1, 2024

Overview

Add explicit_max_ttl to Azure role attributes. When set, Application Secrets in Azure AD will be created with a maximum lifetime equal to explicit_max_ttl, instead of the hard-coded 10-year default in effect until now.

This enables organizations with compliance requirements to limit secret lifetimes to implement a hard ceiling on the secret's lifetime. This also serves as a backstop against the possibility of Vault failing to revoke the secret when the lease expires.

Design of Change

How was this change implemented?

Related Issues/Pull Requests

Contributor Checklist

  • Add relevant docs to upstream Vault repository, or sufficient reasoning why docs won’t be added yet: Example
  • Add output for any tests not ran in CI to the PR description (eg, acceptance tests)
  • Backwards compatible

@gsantos-hc
Copy link
Contributor Author

gsantos-hc commented May 3, 2024

One thing missing from this is communicating to the client that the secret won't be renewed beyond its initial explicit_max_ttl. Any ideas for that? Maybe the lease could be marked non-renewable when the remaining lifetime under explicit_max_ttl is less than the role's TTL?

@Zlaticanin
Copy link
Contributor

Thank you for working on this! 👏 Everything looks good to me. I am currently testing it locally, not running into any issues so far. As for the secret renewal, I think that it makes sense for it not to be renewed if < role's ttl, we just need to make sure we document it as well.

@gsantos-hc
Copy link
Contributor Author

Force-pushed to rebase from main and leverage min in Go 1.21

@Zlaticanin
Copy link
Contributor

Can we please add changelog entry?

We can update CHANGELOG.md file, we can add an entry here, something like

FEATURES:

* Adds ability to set `explicit_max_ttl` to specify the expiration for secrets associated with service principals [[GH-199]](https://github.com/hashicorp/vault-plugin-secrets-azure/pull/199)

After the PR is merged, I will open a PR on Vault side to update the documentation.

@gsantos-hc
Copy link
Contributor Author

Thanks for reviewing and testing, @Zlaticanin. I've updated the changelog.

Add `explicit_max_ttl` to Azure role attributes. If set, Application
Secrets in Azure AD will be created with a maximum lifetime equal to
`explicit_max_ttl` instead of the hard-coded 10-year default in effect
until now.

Leases are renewable unless or until the remaining Azure-side lifetime
is shorter than the role's configured TTL. Marking a lease as
non-renewable signals to clients that they must obtain a new
lease/secret when the existing one is approaching the limit that was
originally set through `explicit_max_ttl`.

Fixes hashicorp#178
Fixes VAULT-12316
@gsantos-hc
Copy link
Contributor Author

Force-pushed to rebase from the latest main and squash commits

Copy link
Contributor

@Zlaticanin Zlaticanin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Thank you for working on this! 🎉

After we merge this, I will update the docs

@Zlaticanin Zlaticanin merged commit bfe49f2 into hashicorp:main Jul 3, 2024
4 checks passed
@gsantos-hc gsantos-hc deleted the feat/explicit-max-ttl branch July 4, 2024 01:39
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

Successfully merging this pull request may close these issues.

Azure secrets engine, ability to specify static SPN secret expiry
2 participants