Блог

Я создаю Azure KeyVault с помощью 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    
  }
});
 

Как вы можете видеть, я не только создал KeyVault, но и добавил текущий идентификатор объекта в качестве политики доступа.

Сразу после этого я пытаюсь добавить запись в KeyVault:

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

Это отлично работает локально при работе с логином пользователя ( az login ) Но при использовании принципа обслуживания (DevOps) создание хранилища по-прежнему работает, но добавление секретов завершается неудачно из-за проблем с разрешениями:

azure: keyvault: ошибка создания секретных строк подключения-blobstorageaccountkey: проверка наличия существующего секретного «connectionstrings-blobstorageaccountkey» (хранилище ключей «https:// (vaultname).vault.azure.net /»): keyvault.BaseClient#GetSecret: сбой при ответе на запрос: StatusCode= 403 — Исходная ошибка: autorest / azure: служба вернула ошибку. Статус = 403 Код =»Запрещено» Сообщение =»Пользователь, группа или приложение ‘appid =;oid = (ObjectId);iss = https: // sts.windows.net /***/’ не имеет секретов, чтобы получить разрешение на хранилище ключей ‘; местоположение = westeurope’.

Я использую «классический» (не nextgen)-вариант в Pulumi.Azure

Причиной этой проблемы было то, что я pulumi up локально с моей личной учетной записью Azure. При последующем запуске pulumi up в качестве сервисного соединения доступ был невозможен из-за разных учетных данных.

При использовании другого стека (и разных ресурсов) для службы все работает нормально.

Поэтому при тестировании конфигурации pulumi вы всегда должны использовать другой стек при локальном тестировании, если требуются разрешения (которые они почти всегда есть).

Я оставлю этот вопрос здесь, потому что подозреваю, что еще несколько человек попадут в ту же яму.