No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

Using the code from <https://leebriggs.co.uk/blog/2022/01/23/gha-cloud-credentials|this blog post> (NOT pointing any fingers, just to be clear),  and not being entirely sure what exactly has occurred (because I currently have no access at all) I get the same error almost everywhere in AWS right now. Can anyone share some insight as to whats going on?
```user_X is not authorized to perform: iam:XXX on resource: resource_Y because no identity-based policy allows the iam:X action```

did `user_X` have access before? if so, you maybe modified the policies for that user/role to be `ReadOnlyAccess` as in the blog post :shrug: in the blog post they're only doing `aws sts get-caller-identity` in the workflow so  `ReadOnlyAccess` is enough

It’s a test account, so I added `AdministratorAccess` to make it easier while we tested. I just don’t understand why `pulumi down` would remove everything (for all users, not just the Pulumi user).

Basically the exact same as in the example, except changing the role.

It did behave a bit odd, because I had to take it down because it tried to recreate the provider already existing instead of replacing it.

so you didn't create a new role but used an existing role instead? other users should only be affected if they're using the same role (federated sso role or smth) :thinking_face:

I created a new role, and attached `AdministratorAccess`to it. Removing either should not remove the policy from everyone (I assumed).

to clarify, you mean the role that's called `secure-cloud-access` in the blog post?

well that's weird :smile: either there's a typo somewhere, some cached file was used or the planets are not aligned :shrug:

I am going to try to reproduce it now, but even with a typo it should just have removed the assigned role for that user, not nuked every user in the account.

yeah it definitely shouldn't touch anything else than the role &amp; policy attachment :confused:

I have a new account now, I’ll try to reproduce.

Oh. I think I see whats going on here. <https://www.pulumi.com/registry/packages/aws/api-docs/iam/policyattachment/>

&gt; This means that even any users/roles/groups that have the attached policy via any other mechanism (including other resources managed by this provider) will have that attached policy revoked by this resource.

I’ll update with a comment under this thread in the main chat, just to make sure nobody panics.

so adminaccess was revoked from everyone?

I mean that is my assumption, it does say so in the docs and that is what happens with my test account and test users. And since this was just a test account as well, everyone was just given that policy to ease my burden.

yeah, so instead of a policyattachment you'd use the `managedPolicyArns` instead (sry dunno what the actual property name is in js/ts)

`UserPolicyAttachment` seems like the one I want to use.

attach the policy to a specific user, and not mess with the entire account.