Conversation
|
I've manually deployed the dependencies stack to create the new role, but before testing the rest, I'd like to get a review. |
| # - PolicyName: CloudformationPackage | ||
| # PolicyDocument: | ||
| # Statement: | ||
| # - Effect: Allow | ||
| # Action: | ||
| # - TBD | ||
| # Resource: TBD |
There was a problem hiding this comment.
We might need this permission
unlox775-code-dot-org
left a comment
unlox775-code-dot-org
left a comment
There was a problem hiding this comment.
This looks great. I spent some time digging into how we were using IAM-DevPermissions as a Permission boundary. The part that didn't sit well with me was using a automated system that in any way referenced the role used by human users. As a permission boundary, I don't think it harms the security here. And everything else looks good, so I'm happing shipping this PR as-is
In future I am thinking I would prefer to make sandbox-style allow list permission boundaries. The main thing I would propose, at least to start the discussion, is to move away from block-list style rulesets, that is using negative rule logic, Deny, or NotAction or StringNotEquals.
Though not specifically for this PR, I put together a POC to test some of my thoughts on blocklist style access. See here: https://github.com/unlox775/security_poc/tree/main/passrole_star
don't remember the context for this...
2 participants
No description provided.