PLFM-8102: Use Admin Access

[xschildw]

This PR switches from specifying the permissions to using a role created by cdk bootstrap that allows assuming a set of policies covering these permissions (also created by cdk bootstrap).

[xschildw]

Not sure if this is going to cause an error when used in SynapseProd account (where this particular policy does not exist).

[ConsoleCatzirl]

This is a cross-account policy reference, the policy only needs to exist in 449435941126. as long as all of our other accounts have been granted access to this policy, it should be fine

[zaro0508]

First, I'm doubtful that this will work. Second, where is this policy created? Third, It's probably not a good practice to depend on a policy from a different account. I recommend not taking this approach, instead you should probably create this policy in every account you plan to deploy this stack to then you can just set ManagedPolicyArns to arn:aws:iam::aws:policy/cdk-assume-role-policy

[xschildw]

This was a temporary test (i.e. not intended for prod use) but @zaro0508 's right, the cdk-assume-role-policy should be created by the 'cdk bootstrap' command in every account, I think it should be referred to as ' arn:aws:iam::${AWS::AccountId}:policy/cdk-assume-role-policy ' since it's user-managed.
Note re: if it works, I created an oidc role manually in the dev account using the policy and was able to use it to update a stack from a GH workflow.

[ConsoleCatzirl]

This is a cross-account policy reference, the policy only needs to exist in 449435941126. as long as all of our other accounts have been granted access to this policy, it should be fine

[zaro0508]

First, I'm doubtful that this will work. Second, where is this policy created? Third, It's probably not a good practice to depend on a policy from a different account. I recommend not taking this approach, instead you should probably create this policy in every account you plan to deploy this stack to then you can just set ManagedPolicyArns to arn:aws:iam::aws:policy/cdk-assume-role-policy

[xschildw]

Turns out that 'cdk-assume-role-policy' was not created by the CDK so I just use an equivalent inline policy.

[zaro0508]

to be more precise, how about arn:aws:iam::${AWS::AccountId}:role/cdk-*-cfn-exec-role-${AWS::AccountId}-us-east-1?

[zaro0508]

The idea here doesn't really make sense to me because if you look at the policy for the cdk cloudformation execution role you'll see that it is given AdministratorAccess therefore it would be equivalent to giving this OIDC admin access directly. Why give this role the runaround of assuming another role with admin access when you can give this role admin access directly?

[xschildw]

Yeah, I was reading about it afterwards... As I understand the way to solve this is to create a custom policy then redo the bootstrap such that the default Admin perms are changed to more constrained permissions (I'm a bit lost as that set of permissions would have to cover all the cases in a given account...). Maybe you're right and we may as well be explicit. I'll change it.

[xschildw]

Changed to explicitly use AdministratorAccess.

[zaro0508]

This resource is now basically the same as the existing GithubOidcSageBionetworksSynapseDockerRegistry. Do you think it would make sense to consolidate these to a single generic GithubOidcSageBionetworksSynapse resource that gives access to multiple repos? The benefit is that when new repos pop up to deploy lambda or CDK they can just use the generic resource.

[xschildw]

Good idea! Renamed, added registry repo.

[zaro0508]

Generally looks good. Just remember to update the synapse-docker-registry with the new role.

[zaro0508]

do you plan to also replace the role used by GH actions in synapse-docker-registry repo with the one generated from this new GithubOidcSageBionetworksSynapse resource? And then of course also remove GithubOidcSageBionetworksSynapseDockerRegistry?

[xschildw]

Correct.