简体   繁体   English

为什么在使用 @azure/keyvault-keys 和 @azure/identity 时需要租户,但在使用 azure-keyvault 时不需要?

[英]Why do I need a tenant when using @azure/keyvault-keys with @azure/identity, but not when using azure-keyvault?

I was using azure-keyvault but it's now deprecated.我使用的是azure-keyvault ,但现在已弃用。 I'm using for encrypting and decrypting stuff.我用于加密和解密东西。 All I needed to operate was clientId, clientSecret and the key identifier.我只需要操作clientId、clientSecret和密钥标识符。

Because now azure-keyvault is deprecated I switched to @azure/keyvault-keys / @azure/identity .因为现在azure-keyvault已弃用,所以我切换到@azure/keyvault-keys / @azure/identity For this I need a tenant ( ClientSecretCredential ) which I previously didn't need.为此,我需要一个以前不需要的租户( ClientSecretCredential )。 Why is that or is there a way to not needing it?为什么会这样,或者有没有办法不需要它?

When using a ClientSecretCredential , because a service principal belongs to a particular tenant, you have to specify that tenant rather than it coming back in a callback like the older code.使用ClientSecretCredential时,由于服务主体属于特定租户,因此您必须指定该租户,而不是像旧代码那样在回调中返回。

There are many different credential types, but our recommendation is to use DefaultAzureCredential which supports MSI, environment credentials (service principal using $AZURE_TENANT_ID , $AZURE_CLIENT_ID , and $AZURE_CLIENT_SECRET ), and interactive browser login for most languages - soon with more credentials like azure CLI and Visual Studio.有许多不同的凭据类型,但我们的建议是使用支持 MSI、环境凭据(使用$AZURE_TENANT_ID DefaultAzureCredential $AZURE_CLIENT_ID$AZURE_CLIENT_SECRET的服务主体)和大多数语言的交互式浏览器登录的 DefaultAzureCredential - 很快就会使用更多凭据,例如 azure CLI和视觉工作室。 With support for azure CLI, that provides parity with the older packages like you used and then some.通过对 azure CLI 的支持,它提供了与您使用的旧软件包的奇偶性,然后是一些。 Just by using DefaultAzureCredential you get all that and it supports different environments by default, so you don't have to change your code to use different credentials for dev, staging, or production environments.只需使用DefaultAzureCredential即可获得所有功能,并且默认情况下它支持不同的环境,因此您无需更改代码即可为开发、暂存或生产环境使用不同的凭据。

So like in the referenced example, you just instantiate a DefaultAzureCredenial and thats it.因此,就像在引用的示例中一样,您只需实例化一个DefaultAzureCredenial即可。 If you have your service principal environment variables defined, they will be used if Managed Identity (MSI) wasn't detected.如果您定义了服务主体环境变量,则在未检测到托管标识 (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);

The order of credentials is optimized for production workloads, but supports developer machines - pretty close to the order I listed them above.凭证的顺序针对生产工作负载进行了优化,但支持开发人员机器 - 非常接近我在上面列出的顺序。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM