Closed gsantos-hc closed 2 months ago
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?
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.
Force-pushed to rebase from main
and leverage min
in Go 1.21
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.
Thanks for reviewing and testing, @Zlaticanin. I've updated the changelog.
Force-pushed to rebase from the latest main
and squash commits
Overview
Add
explicit_max_ttl
to Azure role attributes. When set, Application Secrets in Azure AD will be created with a maximum lifetime equal toexplicit_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