PLFM-9253: Changes to support using Code Pipeline with Synapse #1512
Conversation
…to acess Synapse dev' account
brucehoff
changed the title
| { "Fn::Sub": "arn:aws:iam::${AWS::AccountId}:role/sagebase-github-oidc-sage-bionetworks-it" }, | ||
| { "Fn::Sub": "arn:aws:iam::${AWS::AccountId}:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_Administrator_693a85eb20cd5043" } | ||
| ] | ||
| "AWS": "*" |
There was a problem hiding this comment.
Why is this being changed to *? Is there something preventing us from maintaining least privilege?
There was a problem hiding this comment.
Good question: In this policy the 'allow' and 'deny' sections have the same list of IAM entities, creating unnecessary duplication. By simplifying the 'allow' to '*' and leaving the 'deny' in place, we get the same level of 'least privilege' while simplifying the policy document. This begs the question, "why not keep the 'allow' and eliminate the 'deny' part of the policy?" The reason is because the 'deny' section allows the use of wildcards and we need to use the pattern, Synapse-Build-*-CodeBuildServiceRole.
| } | ||
| }, | ||
| { | ||
| "Sid": "Allow root administration of the key", |
There was a problem hiding this comment.
Nit: This statement is more expansive than just root administration, can you update the description?
| { "Fn::Sub": "arn:aws:iam::${AWS::AccountId}:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_Administrator_693a85eb20cd5043" } | ||
| { "Fn::Sub": "arn:aws:iam::${AWS::AccountId}:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_Administrator_693a85eb20cd5043" }, | ||
| { "Fn::Sub": "arn:aws:iam::${AWS::AccountId}:role/Synapse-Build-*-CodeBuildServiceRole" }, | ||
| { "Fn::Sub": "arn:aws:iam::${AWS::AccountId}:role/Deployment-Pipeline-CodeBuildServiceRole" } |
3 participants
Allow code pipeline roles to access synapse dev KMS key;
Allow Stack-Builder workflow to use AS OIDC integration