I was wondering if there’s been movement on this item https://github.com/pulumi/pulumi/issues/14509. TLDR: Using OIDC from ESC within IaC you are currently unable to lock down roles to specific environments as the subject is “wrong”

We've made some progress here...

As Komal mentioned, we recommend using Subject Customization. We created that option as an alternate solution. a. Instead of the default subject if you use

pulumi.user.login

and/or

pulumi.organization.login

subject attributes, you can ensure the subject claims are consistent across Pulumi IaC operations (

pulumi up/refresh/destroy

) and esc commands (like

esc open

,

esc run

). Example subject claims based on your definition: i.

pulumi:environments:pulumi.organization.login:{ORGANIZATION_NAME}

ii.

pulumi:environments:pulumi.organization.login:{ORGANIZATION_NAME}:pulumi.user.login:{USER_LOGIN}

b. If you use the

currentEnvironment.name

and

rootEnvironment.name

subject attributes with Pulumi IaC Operations, you will still have the subject as

pulumi:environments:org:contoso:env:<yaml>

. However, for esc commands, you will have the subject as per your definition: (For example:

pulumi:environments:pulumi.organization.login:{ORGANIZATION_NAME}:currentEnvironment.name:<CURRENT_ENVIRONMENT_NAME>

)

I think there is still a tricky issue if I understand correctly. As these are both user controlled fields

I think there is still a tricky issue if I understand correctly. As these are both user controlled fields

They are not, these values are provided by the environment.

User controlled as in a member in the org can create a new environment setting the role and the name to use

You can't set those strings in ESC. These are pre-defined keys that will be evaluated when opening the environment.

I think(?) Matt means the strings for the admin role arn

Oh I see it isn’t an override it is a list of keys to append

Ok I think I have the same issue with trying to lock it down though since it will be <yaml> regardless of the the env it is

Yeah, if you are thinking of locking down using env name when using IaC, then it gets tricky.

Yep

Definitely appreciate you raising this, it's an ongoing conversation on how best to solve this going forward.

Hi @brash-gigabyte-81569 I got late to the conversation. The problem with that is that by default it lacks of a root env (the one in IaC importing the first env) to define the subject. You can customize the subject using the

currentEnvironment.name

and

rootEnvironment.name

subject attributes which will resolve to a proper name when used from a stored environment: • current env is the name of the environment using the provider • root env is the name of the "rootest" environment (the one being imported from Iac) Using the example of the issue, you can create a new

prod_keys

environment

values:
  azure:
    login:
      fn::open::azure-login:
        subjectAttributes:
          - currentEnvironment.name
        clientId: your-client-id
        tenantId: you-tenant-id
        subscriptionId: your-subscription-id # without the `/subscriptions/` prefix
        oidc: true