-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request - AWS Secret Backend: Policy support to STS #3751
Comments
joelthompson
added a commit
to joelthompson/vault
that referenced
this issue
Apr 15, 2018
The AWS secret engine had a lot of confusing overloading with role paramemters and how they mapped to each of the three credential types supported. This now adds parameters to remove the overloading while maintaining backwards compatibility. With the change, it also becomes easier to add other feature requests. Attaching multiple managed policies to IAM users and adding a policy document to STS AssumedRole credentials is now also supported. Fixes hashicorp#4229 Fixes hashicorp#3751 Fixes hashicorp#2817
Hey @flyinbutrs -- I have a PR in #4360 that should support this use case (with an RFC in #4229 that should explain the desired behavior without having to read through the code). I'd love feedback on the approach! |
jefferai
pushed a commit
that referenced
this issue
Aug 16, 2018
* Make AWS credential types more explicit The AWS secret engine had a lot of confusing overloading with role paramemters and how they mapped to each of the three credential types supported. This now adds parameters to remove the overloading while maintaining backwards compatibility. With the change, it also becomes easier to add other feature requests. Attaching multiple managed policies to IAM users and adding a policy document to STS AssumedRole credentials is now also supported. Fixes #4229 Fixes #3751 Fixes #2817 * Add missing write action to STS endpoint * Allow unsetting policy_document with empty string This allows unsetting the policy_document by passing in an empty string. Previously, it would fail because the empty string isn't a valid JSON document. * Respond to some PR feedback * Refactor and simplify role reading/upgrading This gets rid of the duplicated role upgrade code between both role reading and role writing by handling the upgrade all in the role reading. * Eliminate duplicated AWS secret test code The testAccStepReadUser and testAccStepReadSTS were virtually identical, so they are consolidated into a single method with the path passed in. * Switch to use AWS ARN parser
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Feature Request:
The AWS Secret Backend supports STS for cross account privileges. However, if you try to provide both an ARN and a Policy when defining a role, it does not accept it, returning the error "Only one of policy or arn should be provided". The STS API supports overlay policies for restricting access to cross account roles. This provides for the ability to give least privileges credentials to multiple accounts without having to create a role in each account for each permission.
Documentation of inputs in SDK
The text was updated successfully, but these errors were encountered: