Pulumi cannot access just created keyvault when running as serviceprinciple

Question

I create an Azure KeyVault using Pulumi:

 var currentConfig = Output.Create(GetClientConfig.InvokeAsync());
 var keyvault = new KeyVault(vaultname, new KeyVaultArgs
{
  Name = vaultname,
  Location = _resourceGroup.Location,
  ResourceGroupName = _resourceGroup.Name,
  TenantId = currentConfig.Apply(q => q.TenantId),
  SkuName = "standard",
  AccessPolicies =
  {
    new Pulumi.Azure.KeyVault.Inputs.KeyVaultAccessPolicyArgs
    {
      TenantId=currentConfig.Apply(q=>q.TenantId),
      ObjectId=currentConfig.Apply(q=>q.ObjectId),
      KeyPermissions={"get", "create", "list"},
      SecretPermissions={"set","get","delete","purge","recover", "list"}
    }, new Pulumi.Azure.KeyVault.Inputs.KeyVaultAccessPolicyArgs    
  }
});

As you can see I did not only create the KeyVault but also added the current ObjectId as an Access Policy.

Directly after that I try to add an entry to the KeyVault:

new Secret("secret",new SecretArgs
{
  Name = "secret",
  Value = "value",
  KeyVaultId = keyVault.Id
});

This works fine locally when working with a user login (az login) But when using a service principle (DevOps) instead the Vault-Creation still works but adding secrets fails because of permission issues:

azure:keyvault:Secret connectionstrings-blobstorageaccountkey creating error: checking for presence of existing Secret "connectionstrings-blobstorageaccountkey" (Key Vault "https://(vaultname).vault.azure.net/"): keyvault.BaseClient#GetSecret: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="Forbidden" Message="The user, group or application 'appid=;oid=(objectId);iss=https://sts.windows.net/***/' does not have secrets get permission on key vault ';location=westeurope'.

I am using the "classic" (non-nextgen)-variant at Pulumi.Azure

Ole Albers Ole Albers · Accepted Answer · 2021-02-23T10:38:11

The cause of this issue was that I an pulumi up locally with my personal azure account. When running pulumi up as a service connection afterwards access wasn't possible because of different credentials.

When using a different stack (and different resources) for the service everything works fine.

So if testing the pulumi configuration you should always use a different stack when testing locally if permissions are required (which they almost ever are).

I will leave this question here because I suspect a few more people will fall into the same pit.

Pulumi cannot access just created keyvault when running as serviceprinciple

1 Answers