When using a PolicyAttachment with a “default” pol...
# aws
b
When using a PolicyAttachment with a “default” policy like
AmazonS3FullAccess
it appears there’s a few scenarios where the PolicyWon’t be correctly attached to a role. As an example if I rename the resource name of the policy attachment it appears that it “creates” and then “deletes” the policy attachment leaving the attachment empty. There’s a few other ways that this seems to occur. What’s the best strategy to ensure the expected policy is always attached to a role?
l
A post-deployment automated check?
I've never seen that behaviour, I'm interested to know how often it happens.
b
Mmm seems to happen somewhat often. I have multiple stacks running in the same account. I tested a scenario whereby I “renamed” the resource to try and force the policy to reattach. When I look at the role it has no attached policies but the execution is marked successful.
I renamed this resource from
-s3write
to
-s3full
to try and force the reattach:
Copy code
aws.iam.PolicyAttachment(f"{cluster_name}-sa-attach-s3full",
                         roles=[role_sa.iam_role_name],
                         policy_arn="arn:aws:iam::aws:policy/AmazonS3FullAccess",
                         opts=pulumi.ResourceOptions(depends_on=[role_sa]))
l
That must be a bug. I'm confident it has never happened to me. I've just checked all the roles that I can think of and that are similar to what you've described, and they all have all the policy attachments I expect them to have...
Maybe the python bindings? Maybe there's a hashset involved somewhere that's causing problems?
TBF, I'm not much of a sample case.. I've checked 3 roles with AWS-provided policies attached, x2 accounts / stacks.
b
I’m using an S3 backend with multiple stacks. I don’t have permission to use the public Pulumi backend in the org I’m working with. I could try building a minimal testcase with Typescript since that seems the best supported language.