-
-
Notifications
You must be signed in to change notification settings - Fork 65
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
Add permission boundary attachment logic #50
base: main
Are you sure you want to change the base?
Conversation
attaching boundary to Permission set is done by policy name, it requires this policy to exist on the target AWS Account when assignment will be done. and module doesn't create anything in target accounts. this at least has to be written somewhere in a doc, if this PR will get merged |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aaronrea good work here -- I like it. Couple small requests that I'd like to see but we can move this forward once we have those in 💯
@@ -11,6 +11,10 @@ variable "permission_sets" { | |||
name = string | |||
path = string | |||
})) | |||
boundary_policy_attachments = list(object({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aaronrea can you make this optional with a default of []
. This feels like a solid feature add, but I don't believe 90% of module consumers will have to use this functionality because permission boundaries are only necessary in large environments. Considering that, I want to make the barrier to upgrading + future usage as easy as possible. Keeping it optional with a default feels like it will be available for people, but we won't force them into it. And since we're already on TF 1.3+ here, we can use those features without a version bump requirement.
Thanks!
boundary_policy_map = { for ps in var.permission_sets : ps.name => ps.boundary_policy_attachments if length(ps.boundary_policy_attachments) > 0 } | ||
boundary_policy_attachments = flatten([ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mind including a comment or two explaining your data manipulations here? I think that will be helpful.
] | ||
]) | ||
boundary_policy_attachments_map = { | ||
for policy in local.boundary_policy_attachments : "${policy.policy_set}.${policy.policy_path}${policy.policy_name}" => policy |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 👍
@aaronrea also, when you're done with your updates, please run some automation to pass our tests by doing the following locally, adding + committing the result, and pushing to your branch.
Thanks! |
Thanks @aaronrea for creating this pull request! A maintainer will review your changes shortly. Please don't be discouraged if it takes a while. While you wait, make sure to review our contributor guidelines. Tip Need help or want to ask for a PR review to be expedited?Join us on Slack in the |
what
This commit adds a variable and logic to attach permission boundaries to permission sets.
why
This functionality is useful in the context of deploying permission sets.
references
fixed #37
Notes
Just in time (?) provisioning for the boundary to the target account doesn't seem to work so the boundary policy needs to exist in the target account prior to attempting to attach it.