What is the right way to self assume an aws Role with Pulumi? (required based on https://aws.amazon.com/blogs/security/announcing-an-update-to-iam-role-trust-policy-behavior/). Specifically, how to have a physical resource created and then updated inside a single

pulumi up

. ? My use case is: The aws Role must be created prior to passing a statement like

if (selfAssume) {
                    statements.push({
                        // yes this is self-assuming
                        // see <https://aws.amazon.com/blogs/security/announcing-an-update-to-iam-role-trust-policy-behavior/>
                        effect: 'Allow',
                        actions: ['sts:AssumeRole'],
                        principals: [{type: 'AWS', identifiers: [roleArn]}]
                    })
                }

Lest ye get the dreaded

* creating IAM Role ({redacted): MalformedPolicyDocument: Invalid principal in policy: "AWS":"arn:aws:iam::REDACTED:role/REDACTED
        status code: 400, request id: 432f4a8f-813b-413e-83b2-d2b6bf18cfd6

This error occurs because the resource doesnt exist when it is being created with its self-assuming ARN. Any ideas?

You want to create a role, then assume it, in a single program? You will need two projects: it cannot be done in a single project. You can have two projects in a single program if you use automation-api. Also, you would have to change the profile you're using, so that would probably involve a change to env vars, too. It seems like an odd thing to want to do. Since you're already logged in at the time you create the role, why not let the new role trust whatever role you're already using? Then there'd be no self-assumption.

It's a mandate from AWS (link above) unfortunately and is needed when using something like GH actions oidc provider. TF also still struggles with this aws peculiarity: https://github.com/hashicorp/terraform-provider-aws/issues/27034

As I read that page, the mandate is about how to use self-assuming roles, if you have to use them. There is no mandate to use self-assuming roles. I use GH actions, OIDC, etc, and I don't use self-assuming roles. Also, I use one project to set up the roles used with OIDC. That project does nothing else - there's no reason to, because nothing else is deployed with those roles, they're completely independent of all "functional" projects. There is no way to have Pulumi use a role for auth purposes that you have created in the same project. You need to split the projects. I think it is likely that you don't need to do any of this, since there have been no other similar queries here. And the idea of authenticating using one method, then creating a role that allows you to do your work and is allowed assume itself, then unauthenticating from your original method, authenticating with the new role, redundantly assuming that same role before continuing on with your intended work, is more than a little confusing. It seems to make life unnecessarily hard. I would work very hard to eliminate that sort of rigmarole, if I worked at AWS.

I'll try again to implement without it, but I'm pretty sure I only ended up there because of the need for it. The idea being a temporary role while mapping to a service account in EKS for deploying into the cluster during a deployment from GH Actions. Point taken though to take another hard look on whether I need it or not.

You may need to use a temporary role, but can you assume into that role from somewhere else? Do you need to assume into it from itself?