-
Notifications
You must be signed in to change notification settings - Fork 504
Feature request: inline session policies for assuming role #229
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
Comments
Thanks for the feature request @spyoungtech ! I agree this sounds like it would be a great addition |
This issue has not received any attention in 1 year. If you want to keep this issue open, please leave a comment below and auto-close will be canceled. |
Hello 👋 #739 is my attempt at implementing this feature request. Any feedback is welcome and will be useful! 🙂 |
Fixed by #739, this is now included on |
Comments on closed issues are hard for our team to see. |
Request
It would be great if this action could support session policies (the
Policy
parameter for AssumeRole operation) for assumed roles.Problem being solved
Inline policies help IAM users apply permission boundaries to roles being assumed. This may help prevent accidents in a job or otherwise limit the scope in which the assumed role can be used thus improving security posture.
Use cases
Limiting permissions of a role based on action being taken
For example, a role may be specified as an organization secret with access to update many CloudFormation stacks. An inline policy might be used to reduce the permissions to a subset of resources, such as denying access to RDS resources or denying access when tags do not match expected tags for the project.
An example inline policy denying CloudFormation actions to resources with unexpected tags:
Limiting source IP for assumed role dynamically
One might use a session policy to ensure the temporary credentials generated by this action are limited to the source IP address of the GitHub action runner. Thus, if the temporary credentials are exfiltrated, they won't be (as) useful to an attacker.
For example, an inline policy may be generated dynamically by resolving the public IP of the GitHub runner, only allowing AWS actions to be taken from the current IP address (could be used with haythem/public-ip action)
Ref: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_deny-ip.html
Proposed usage
Usage might look like this:
The text was updated successfully, but these errors were encountered: