don't create leases for AWS STS secrets

[bhowe34]

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.

[hsimon-hashicorp]

@bhowe34, when you're ready for this to be reviewed, please don't forget to add a changelog entry! Thanks. :)

[bhowe34]

compatible with api.Secret.TokenTTL()

[calvn]

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.

[robmonte]

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!

[bhowe34]

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.

[bhowe34]

Looks like you are correct so I made the same change for federation tokens.

[robmonte]

Thanks again for your submission! Looks good to me. There's a test case to update to accommodate this change but I'll take care of that in a separate PR.