feat(aws): add ability to provide a role session name when generating STS credentials #11345
Conversation
There was a problem hiding this comment.
Hi @RXC001, thanks for the contribution! I have a few minor suggestions, but a couple of questions too. Forgive me if I'm missing some context as CodeDeploy is new to me.
- You mention you can't renew the generated temporary credentials, but I'm unsure why you can't renew them using the Vault lease ID: https://www.vaultproject.io/api-docs/system/leases#renew-lease, the equivalent of
vault lease renew aws/creds/my-role/Dmlmy...using the CLI. With the features in this PR, how will you use the ARN to renew the credentials; will it be through Vault or a different mechanism? - Assuming you can't use Vault's built-in lease renewal, why do you need the generated ARN to be stable in addition to having the ARN returned in the response? As above, I don't have context on how you plan to handle renewals, but it seems to me like either feature would be enough for you to know the ARN. I feel like I'm probably missing a separate requirement here.
| roleSessionName, roleSessionNameWarning = genUsername(displayName, roleName, "iam_user") | ||
| } else { | ||
| roleSessionName = normalizeDisplayName(roleSessionName) | ||
| if len(roleSessionName) > 64 { |
There was a problem hiding this comment.
I know the code this is based on doesn't, but please could you add a comment with the source of this number? Is https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html#reference_iam-quotas-entity-length the right link?
|
I work with @RXC001 and was involved in the feature and code. @tomhjp Will have to check on lease renew method. We are using Vault Agent and haven't tried that method before.
CodeDeploy registers an on premise instance based on the session arn (role arn + session name) and as long as the full session arn remains the same across multiple STS provided access key, secret key, session token we can refresh the aws credentials without re-registering the instance. This is why we require a session arn that has a consistent session name associated. We also have a need outside of code deploy to be able to set a session name on our end when creating new STS creds to track the usage for the specific client in AWS CloudTrail as we have multiple VMs using the same AppRole and therefore currently the same session name with timestamp added. Right now we have to correlate Vault Audit logs and and timestamps to getting STS creds to find one when X VM requested from vault and then match to cloudtrail. From a security standpoint this is both painful and not a process we can automate. With having a settable session name that vault passes through to AWS through VaultAgent we can easily tag the instance requesting the sts creds and match the usage in CloudTrail with a quickly identifying session name. We can also trigger alerts in AWS for non expected session name or a session coming from an unexpected IP with ease. The reason we added the arn to the response is:
|
Co-authored-by: Tom Proctor <[email protected]>
|
Thanks for that extra context @ibspoof, that makes sense and I can see how this all fits together now. The lease renewal can be considered a separate issue as far as I'm concerned. I'll try and get this merged, although it looks like we have some unrelated failures in CI 😞 EDIT: Also just for posterity, I have pulled this down and tested it, and it all works as expected. |
… STS credentials (#11345) * feat(aws): add ability to provide a sessionName to sts credentials Co-authored-by: Brad Vernon <[email protected]> Co-authored-by: Jim Kalafut <[email protected]> Co-authored-by: Tom Proctor <[email protected]>
… STS credentials (#11345) (#11636) * feat(aws): add ability to provide a sessionName to sts credentials Co-authored-by: Brad Vernon <[email protected]> Co-authored-by: Jim Kalafut <[email protected]> Co-authored-by: Tom Proctor <[email protected]> Co-authored-by: Ricardo Cardenas <[email protected]>
|
@tomhjp Thanks! |
We have a need for an IAM session ARN to register an AWS CodeDeploy on-premises instance, more info here; the problem comes with renewing the temporary credentials. In Vault, the IAM session ARN associated with newly generated credentials (using this endpoint) is dynamically built with the current time and a random int. Because of this, renewing temporary credentials using the same IAM session ARN would be impossible, as the ARN would be changed when Vault generates new credentials.
The proposed solution comes in two parts. The first is to add a new parameter called
role_session_namewhen generating new credentials. With this, users can pass in a role session name and expect an ARN with a static role session name every time new STS credentials are read from Vault. Ifrole_session_nameisn't provided, then the previous behavior of dynamically creating a session name is followed.The second part of this solution is to return the IAM session ARN generated when Vault assumed the role. In the return payload, the IAM session ARN will be in the
arnfield. This provides transparency on which IAM user/role the returned credentials are associated with.