Зачем мне нужен арендатор при использовании @ azure / keyvault-keys с @ azure / identity, а не при использовании azure -keyvault? - PullRequest
Новая
       17

Зачем мне нужен арендатор при использовании @ azure / keyvault-keys с @ azure / identity, а не при использовании azure -keyvault?

0 голосов
/ 09 апреля 2020

Я использовал azure-keyvault, но теперь он устарел. Я использую для шифрования и дешифрования вещей. Все, что мне нужно для работы - это clientId, clientSecret и идентификатор ключа.

Поскольку теперь azure-keyvault устарело, я переключился на @azure/keyvault-keys / @azure/identity. Для этого мне нужен арендатор (ClientSecretCredential), который мне ранее не был нужен. Почему это или есть способ не нуждаться в этом?

1 Ответ

2 голосов
/ 15 апреля 2020

При использовании ClientSecretCredential, поскольку субъект службы принадлежит определенному арендатору, вы должны указать этот арендатор, а не возвращаться в обратном вызове, как старый код.

Существует много разных учетных данных типов, но мы рекомендуем использовать DefaultAzureCredential, который поддерживает MSI, учетные данные среды (принципал службы, использующий $AZURE_TENANT_ID, $AZURE_CLIENT_ID и $AZURE_CLIENT_SECRET) и интерактивный вход в браузер для большинства языков - скоро с большим количеством учетных данных, таких как azure CLI и Visual Studio. С поддержкой azure CLI это обеспечивает паритет с более старыми пакетами, которые вы использовали, а затем с некоторыми. Просто используя DefaultAzureCredential, вы получаете все это, и он поддерживает различные среды по умолчанию, поэтому вам не нужно менять код для использования различных учетных данных для сред разработки, промежуточных или производственных сред.

Так же, как в В приведенном примере вы просто создаете экземпляр DefaultAzureCredenial и все. Если у вас определены переменные среды субъекта службы, они будут использоваться, если Managed Identity (MSI) не был обнаружен. 

import { SecretClient } from '@azure/keyvault-secrets';
import { DefaultAzureCredential } from '@azure/identity';
import { CosmosClient } from '@azure/cosmos';

const keyVaultUrl = process.env('APP_KEY_VAULT_URI');
const credential = new DefaultAzureCredential();
let storageClient;
let cosmosClient;

async function configureClients() {
    const kvClient = new SecretClient(keyVaultUrl, credential);
    const storageUri = await client.getSecret('storageUri');
    const cosmosDbConnectionString = await client.getSecret('cosmosDb');

    cosmosClient = new CosmosClient(cosmosDbConnectonString);
    storageClient = new BlobServiceClient(storageUri, credential);

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

...