Hello everyone, I'm trying to set up a secure, CI/CD pipeline for my Pulumi infrastructure using GitHub Actions. My goal is to use an Azure Managed Identity with a federated credential to authenticate. I am following this documentation "https://www.pulumi.com/docs/iac/using-pulumi/continuous-delivery/github-actions/" 1. Login to Azure, using the federated idendity 2. try to login to Pulumi, to the azure storage blob, that hold the pulumi state. Expectation: Pulumi use already the token from azure login that was done a step before, and automatically login from: "https://www.pulumi.com/blog/oidc-with-azure/" > First, tell the Pulumi provider to use OIDC by setting the environment variable

ARM_USE_OIDC

or the Pulumi configuration

azure-native:useOidc

to true. Next, you’re in luck if your program runs on GitHub Actions: you’re done. GitHub exports the necessary values in form of variables that Pulumi understands. it always returns an authentication error. I tested in the bash (using az) before calling the PULUMI login, to fetch the resources that is needed, and that included in the error, and everything works perfectly. so I am logged in correctly, and the identity, has access to the needed resrouces. error: > AZURE_STORAGE_ACCOUNT=* > error: problem logging in: read ".pulumi/meta.yaml": blob (key ".pulumi/meta.yaml") (code=Unknown): GET https://****.blob.core.windows.net/pulumi-environment-state/.pulumi/meta.yaml anyone has the same experience? or struggled with logging in via azure?

I think you mixed 2 concepts together. 1. Using an Azure storage account as a DIY backend for Pulumi state. 2. Authenticate with Azure to provision Azure resources using Pulumi Azure native provider. For 1, Pulumi does not support authenticate itself with a backend storage account via managed identity. You will need storage account access keys. This is a risk of using DIY backend while Pulumi Cloud backend support short-lived keys and OIDC, not to mention RBAC. The instructions for setting up a DIY backend are https://www.pulumi.com/docs/iac/concepts/state-and-backends/#using-a-diy-backend and https://www.pulumi.com/docs/iac/concepts/state-and-backends/#azure-blob-storage For 2 to work, you will need to complete setup 1 and create a Pulumi stack. To set up Pulumi Azure native provider with Azure to create resources like resource group etc., refer to https://www.pulumi.com/registry/packages/azure-native/installation-configuration/#authentication-methods

Ah, good to know, this is actually the "workaround" that I did, I generated a static key and using it now. and for provisioning, it is apparently has access from the az login that is done before. However, I thought, this should work as written here. as when I did that locally with my "user account" it worked. but in the CI, logging in with the federated credential, it didn't work

Pulumi uses https://gocloud.dev lib for cross-cloud object store access for the backend state. That library uses Azure SDK to provide access to Azure Blob Storage. However, the env vars it uses vs. the env vars that the provider (both classic Azure and Azure Native) have a different prefix. I think the providers look for

ARM_*

vs. GoCloud SDK uses

AZURE_*

. The reason it works on your local machine without any env vars is that the Azure SDK is likely using your

az

CLI creds when it goes through the default credential chain. (I misread you testing in bash in the workflow as you running it locally but yeah the

azure/login

GH action logs in to the

az

CLI which is why that works.) https://github.com/google/go-cloud/blob/master/blob/azureblob/azureblob.go#L27 > from: "https://www.pulumi.com/blog/oidc-with-azure/" >> First, tell the Pulumi provider to use OIDC by setting the environment variable

ARM_USE_OIDC

or the Pulumi configuration

azure-native:useOidc

to true. Next, you’re in luck if your program runs on GitHub Actions: you’re done. GitHub exports the necessary values in form of variables that Pulumi understands. I don't know what you have in your GHA workflow but maybe try setting

AZURE_TENANT_ID

additionally (once again, note the prefix is

AZURE_

.) Also see https://aka.ms/azsdk/go/identity/credential-chains#defaultazurecredential-overview

Thanks for the insights guys!