AWS Secret Engine: Support Session Tokens

[grahamc]

Sometimes people will give you an AWS access key and secret and not
be interested in setting up a better approach for key exchange.

In cases like this, options are limited for distributing access to
the key material. However, AWS's STS GetSessionToken can be used
to general ephemeral credentials "underneath" that token. This
at least limits the spread of that root key, and the duration of
its users' access.

It should almost definitely not be used for other use cases, since
it does not limit behavior on an otherwise probably administrative
key.

Closes #12734

[hashicorp-cla]

All committers have signed the CLA.

[grahamc]

@taoism4504 Sorry to bother, but I have a changelog file -- did I mess up the process? Or does pr/no-changelog mean something different?

[grahamc]

I just rebased against main, and all the checks are passing. The test failure from before was caused by the test infrastructure failing on the LetsEncrypt certificate expiration thing.

[amanjeev]

Thank you @grahamc for this work. This will really help us where we might have to pass stuff around for remote labs.

[hashishaw]

Thank you for adding the UI changes too, they look great!

[taoism4504]

Reviewed the docs portion; LGTM

[grahamc]

Is there something I can / should do here? I'm a bit surprised by the 2x approvals and then the drop of all the other review requests. I feel stuck.

[heatherezell]

Hi @grahamc - apologies for that bad experience for you. We have several teams that have specialists to review specific parts of our PRs. For example, @taoism4504 reviewed your docs changes and @hashishaw reviewed your UI changes. I will get this in front of another engineer for the remaining code portions. In the meantime, can you resolve the merge conflicts? I appreciate your patience, and thank you so much for raising this up again.

[kalafut]

Thanks for the PR, @grahamc! We’ve been discussing this internally and would like to understand a bit more about the usage. In particular, can you describe the case where a Session Token is needed and one of the other credential types (such as AssumeRole or Federation Token) can’t be used? By “not be interested in setting up a better approach for key exchange” are you referring to not configuring Vault for other types of credentials?

[heatherezell]

As it has been some time since we've heard from you, I'm going to go ahead and close this PR and linked issue. Again, I apologize for what feels like a poor experience. Please feel free to re-open your issue or open a new one - we highly encourage contributors to open the issue first to discuss the problem and proposed solutions, so that any PR created to resolve the issue doesn't end up feeling like throw-away work. We appreciate your time and your desire to help make Vault a better product.

[grahamc]

This problem persists. The S3 credentials are provided by an external organization, who is not able or willing to implement better key sharing.

[robmonte]

Hi @grahamc. Our thinking was perhaps your issue was solved by other means after our last check-in. Since you've reported that the problem persists I've reopened it. Any further context or details you can provide to walk us through the use case here would also assist any future reviewers. Thank you!

[grahamc]

I don’t know how to be more clear about the use case. Can you share what is unclear to help me out?

On July 21, 2023, GitHub ***@***.***> wrote: Hi @grahamc <https://github.com/grahamc>. Our thinking was perhaps your issue was solved by other means after our last check-in. Since you've reported that the problem persists I've reopened it. Any further context or details you can provide to walk us through the use case here would also assist any future reviewers. Thank you!

— Reply to this email directly, view it on GitHub <#12735 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe- auth/AAASXLGMDFUIJVIDBVBKQ43XRL6DFANCNFSM5FKU2VEA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[robmonte]

I don’t know how to be more clear about the use case. Can you share what is unclear to help me out?

Sorry, it may be my own personal unfamiliarity with AWS session tokens for why I am asking. Can you explain why STS credentials are unable to solve the problem you have?

[grahamc]

I'm confused: this addition adds support for session tokens. The user loads a long term key and secret, where the key/secret has highly restricted access within AWS, and allows users to get short lived, unique session tokens back.

[schavis]

Thanks for submitting an update to the docs. I made some suggestions to keep the language in line with our style guide. Let me know if you have any questions.

[schavis]

Suggested change

	~> **Note:** Due to AWS eventual consistency, after calling this endpoint,
	subsequent calls from Vault to AWS may fail for a few seconds until AWS
	becomes consistent again. See the [AWS secrets engine API](/api/secret/aws#rotate-root-iam-credentials) for further information on rotate-root functionality.
	<Note>
	Calls from Vault to AWS may fail immediately after calling
	`aws/config/rotate-root` until AWS becomes consistent again.
	Refer to the
	<a href="/api/secret/aws#rotate-root-iam-credentials">AWS secrets engine API</a>
	reference for additional information on rotating IAM credentials.
	</Note>

style correction: use new aside notation (<Note>) and active voice.

[schavis]

Suggested change

	~> **Notice:** Due to limitations in AWS, in order to use the `session_token`
	credential type, Vault **must** be configured with IAM user credentials. AWS
	does not allow temporary credentials (such as those from an IAM instance
	profile) to be used.
	<Important>
	AWS does not allow temporary credentials like those from an IAM instance
	profile. To use session tokens with Vault and AWS, you must configure Vault
	to use IAM user credentials.
	</Important>

style correction: use new aside notation, mark the aside as important, and use active voice

[schavis]

Suggested change

	An STS session token inherits the exact same set of permissions which are
	granted to the `aws/config/root` credentials.
	STS session tokens inherit whatever permissions are granted to the `aws/config/root` credentials.

style correction: active voice

[schavis]

Suggested change

	A `root_access` role would then assign an inline policy with the same `ec2:*`
	permissions.
	Then the `root_access` role assigns an inline policy with the same `ec2:*` permissions.

style correction: active voice

[schavis]

Suggested change

	To generate a new set of STS federation token credentials, we simply write to
	the role using the aws/creds endpoint:
	To generate a new set of STS federation token credentials, write to the `root_access` role using the `aws/creds` endpoint:

style correction: accessibility, compassionate lanugage

[grahamc]

Thanks for the edits, they're on point. The saga of trying to contribute what amounts to less than 200loc, being bounced between various statuses, labels, edits, rebases, and misunderstandings has left me pretty tired and disenchanted. I understand Hashicorp's projects have a lot of PR activity, and it is hard to keep up, so no worries at all. Y'all own the code now, though, so feel free to pick up the mantle if you'd like. I hope some day the feature offers enough utility to enough customers for my use case to be addressed upstream.