You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem
I ran into an issue where I kept having AWS iam_user credentials generated by vault expire before their TTL was reached which was about 3 mins after creation when the TTL on the lease for the credentials was 1 hour. This was very hard to track down and was counter intuitive to what the TTL represented on the lease. I eventually found out that the generated credentials are tied to the TTL of the vault role that generated them. For security purposes we want to have a low TTL on the actual role an end user or service gets but have a larger TTL for the generated/retrieved credentials. It appears that this is not the case and the generated/retrieved credentials are limited to the max TTL of the token that generated them.
It appears that someone else has also ran into this same exact issue and solved this by increasing the max TTL on the role used for credential generation. We would not like to do this if possible for security purposes.
Solution
I would like to introduce the ability to orphan the credentials retrieved/generated from the parent role. This would allow for the TTL of the generated/retrieved credentials to actually be independent and work as one would think. This option already exists when creating a vault token itself and would be appreciated if this option could also exist for secret engine credentials.
alternatives
The only alternative that I have considered is making the parent roles TTL as large as the max of the generated/retrieved credentials which we would like to avoid if possible for security purposes.
Problem
I ran into an issue where I kept having AWS
iam_user
credentials generated by vault expire before their TTL was reached which was about 3 mins after creation when the TTL on the lease for the credentials was 1 hour. This was very hard to track down and was counter intuitive to what the TTL represented on the lease. I eventually found out that the generated credentials are tied to the TTL of the vault role that generated them. For security purposes we want to have a low TTL on the actual role an end user or service gets but have a larger TTL for the generated/retrieved credentials. It appears that this is not the case and the generated/retrieved credentials are limited to the max TTL of the token that generated them.It appears that someone else has also ran into this same exact issue and solved this by increasing the max TTL on the role used for credential generation. We would not like to do this if possible for security purposes.
Solution
I would like to introduce the ability to orphan the credentials retrieved/generated from the parent role. This would allow for the TTL of the generated/retrieved credentials to actually be independent and work as one would think. This option already exists when creating a vault token itself and would be appreciated if this option could also exist for secret engine credentials.
alternatives
The only alternative that I have considered is making the parent roles TTL as large as the max of the generated/retrieved credentials which we would like to avoid if possible for security purposes.
Additional context
References:
The text was updated successfully, but these errors were encountered: