don't create leases for AWS STS secrets #15869
Conversation
|
@bhowe34, when you're ready for this to be reviewed, please don't forget to add a changelog entry! Thanks. :) |
| "secret_key": *tokenResp.Credentials.SecretAccessKey, | ||
| "security_token": *tokenResp.Credentials.SessionToken, | ||
| "arn": *tokenResp.AssumedRoleUser.Arn, | ||
| "ttl": uint64(tokenResp.Credentials.Expiration.Sub(time.Now()).Seconds()), |
There was a problem hiding this comment.
compatible with api.Secret.TokenTTL()
|
Hi @bhowe34, we've discussed this internally and think that this is a reasonable enhancement request. We're currently wrapping up tasks for our next major release, but will continue to track this internally and prioritize reviewing this in the near future. |
|
Hello @bhowe34 Thanks for this contribution! I have reviewed the PR and I was wondering if you perhaps had a reason to not make this same change for federation tokens? The federation tokens are also short-lived STS secrets like the assumed role tokens, however maybe you have more insight into differences than I am aware of? Please let me know your thoughts! |
|
Hi @robmonte I didn't make the change for federation tokens because I haven't used them and I am not familiar with how they work. I'll look into them and see if the same change makes sense in that case. |
|
Looks like you are correct so I made the same change for federation tokens. |
AWS STS credentials can neither be renewed nor revoked on a per credential basis (credentials can be revoked by revoking all credentials for a role issued before a given time). Given these limitations creating a lease for the credentials isn't very useful and creates lots of requests to the storage backend, especially when vault processes all existing leases on startup. For these reasons it would make sense to not create leases for AWS STS credentials.
To support existing leases during upgrade the revoke and renew logic will still check for STS leases.