do I need

az

cli present in the image?

No, you shouldn’t need the Azure CLI in your container image if you’re using workload identity or service principal env vars. The error you’re seeing means the AzureAD provider didn’t find any other usable credential and fell back to “Azure CLI” in its chain, which then fails because az isn’t present. For the AzureAD provider to pick up your workload identity, you need to supply the right environment variables so the provider can use Azure’s workload identity federation flow. The provider’s credential chain looks for, in order: environment variables, workload identity/managed identity, then developer tools like az. If neither env nor workload identity are correctly configured, it tries az login and emits the message you saw. What to set in your pod/container: • AZURE_TENANT_ID: your Entra tenant ID • AZURE_CLIENT_ID: the Application (client) ID of the app registration or user-assigned managed identity you federated to your EKS service account • AZURE_FEDERATED_TOKEN_FILE: path to the projected service account token file in the pod (for Kubernetes service account token projected volume) • Optionally AZURE_AUTHORITY_HOST if you use a sovereign or private cloud BTW, Pulumi ESC handles this kind of use case really well. 😁

@green-answer-22914 I found out that it is actually a bug 😞 1. AZURE_ credentials mean nothing to

azuread

provider https://www.pulumi.com/registry/packages/azuread/installation-configuration/ I had to set

export ARM_USE_OIDC=true
export ARM_CLIENT_ID=$AZURE_CLIENT_ID
export ARM_TENANT_ID=$AZURE_TENANT_ID
export ARM_OIDC_TOKEN=$(cat $AZURE_FEDERATED_TOKEN_FILE)

then I experienced another bug where the provider tried to query created resource immediately and due to eventual consistency or something was returned with 404. Fun fact is that the resource was created, is just provider error. I am going to have to follow this up with upstream terraform provider.