ASP.NET Core Azure Key Vault構成プロバイダーを使用する

この記事では、Azure Key Vault 構成プロバイダーを使用してKey Vaultシークレットからアプリ構成値を読み込む方法について説明します。 Key Vault は、アプリやサービスで使用される暗号化キーとシークレットを保護するのに役立つクラウドベースのサービスです。 ASP.NET Core アプリでKey Vaultを使用する一般的なシナリオは次のとおりです。

  • 機密性の高い構成データへのアクセスを制御する。
  • 構成データを保存するときに、FIPS 140-2 Level 2 で検証されたハードウェア セキュリティ モジュール (HSM) の要件を満たす。

Packages

次のパッケージのパッケージ参照を追加します。

サンプル アプリ

サンプル アプリは、#define先頭にある プリプロセッサ ディレクティブによって決定される 2 つのモードのいずれかで実行されます。

  • Certificate: Key Vault クライアント ID と X.509 証明書を使用して、key vaultに格納されているシークレットにアクセスする方法を示します。 サンプルは、Azure App Serviceまたは ASP.NET Core アプリを提供できる任意のホストにデプロイされているかどうかにかかわらず、任意の場所から実行できます。

  • Managed: Azure リソースのマネージド ID を使用する方法を示します。 マネージド ID は、アプリケーション コードまたは構成に資格情報を格納せずに、Azure リソースのマネージド ID でKey Vaultするようにアプリを認証します。 サンプルの Managed バージョンは、Azure にデプロイする必要があります。 「Azure リソースのマネージド ID を使用する」セクションのガイダンスに従ってください。

#defineを使用したサンプル アプリの構成の詳細については、サンプル コードのプリプロセッサ ディレクティブを参照してください。

サンプル コードを表示またはダウンロードする (ダウンロード方法)

開発環境でのシークレット ストレージ

シークレット マネージャー ツールを使用して、シークレットをローカルに設定します。 Development環境のローカル コンピューターでサンプル アプリを実行すると、ローカル ユーザー シークレット ストアからシークレットが読み込まれます。

Secret Manager には、アプリケーション プロジェクト ファイルに <UserSecretsId> プロパティが必要です。 プロパティの値 ({GUID}) を任意の一意の GUID に設定します。

<PropertyGroup>
  <UserSecretsId>{GUID}</UserSecretsId>
</PropertyGroup>

シークレットは、名前と値のペアとして作成されます。 階層値 (構成セクション) では、: キー名の区切り記号としてコロン () が使用されます。

Secret Manager は、プロジェクトの コンテンツ ルートに対して開かれたコマンド シェル (またはターミナル) で使用されます。ここで、 {SECRET NAME} は名前、 {SECRET VALUE} は値です。

dotnet user-secrets set "{SECRET NAME}" "{SECRET VALUE}"

プロジェクトの コンテンツ ルートからコマンド シェルで次のコマンドを実行します。 このコマンドは、サンプル アプリのシークレットを設定します。

dotnet user-secrets set "SecretName" "secret_value_1_dev"
dotnet user-secrets set "Section:SecretName" "secret_value_2_dev"

これらのシークレットが Key Vault に格納されている場合は、「secret storage in the Production environment with Key Vault」セクションで説明されているように、_dev サフィックスが _prod に変更されます。 サフィックスは、構成値のソースを示す視覚的なキューをアプリケーション出力に提供します。

Key Vaultを使用した運用環境でのシークレット ストレージ

次の手順を実行して、Azureキー コンテナーを作成し、サンプル アプリケーション シークレットを格納します。 詳細については、「Quickstart: Azure CLIを参照してください。

  1. Azure Cloud Shellを開くには、Azure ポータルで次のいずれかの方法を使用します。

    • コード ブロックの右上隅にある [使ってみる] を選択します。 テキスト ボックスで検索文字列 "Azure CLI" を使います。
    • [Cloud Shell を起動する] ボタンを使って、ブラウザーで Cloud Shell を開きます。
    • Azure portal の右上隅にあるメニューの [Cloud Shell] ボタンを選択します。

    詳細については、Azure CLIドキュメントおよびAzure Cloud Shellの概要を参照してください。

  2. まだ認証されていない場合は、az login コマンドでサインインします。

  3. 次のコマンドを使用してリソース グループを作成します。ここで、{RESOURCE GROUP NAME} は新しいリソース グループの名前、{LOCATION} はAzureリージョンです。

    az group create --name "{RESOURCE GROUP NAME}" --location {LOCATION}

  4. 次のコマンドを使用して、リソース グループに Azure キー コンテナーを作成します。ここで、{KEY VAULT NAME} は新しいコンテナーの名前、{LOCATION} はAzureリージョンです。

    az keyvault create --name {KEY VAULT NAME} --resource-group "{RESOURCE GROUP NAME}" --location {LOCATION}

  5. 名前と値のペアとしてコンテナーにシークレットを作成します。

    Key Vaultシークレット名は、英数字とダッシュ (-) で構成できます。 階層値 (構成セクション) では、区切り記号として 2 つのダッシュまたはハイフン (--) が使用されます。 Key Vaultシークレット名ではコロン文字を使用できません。 ASP.NET Core の構成では、セクションとサブキーをコロンで区切ります。 シークレットがアプリケーション構成に読み込まれると、2 ダッシュ シーケンスはコロンに置き換えられます。

    次のシークレットは、サンプル アプリで使用するためのものです。 値には_prodサフィックスが含まれており、これは Secret Manager を介してDevelopment環境に読み込まれる_devサフィックス付きの値と区別するためのものです。 {KEY VAULT NAME}は、前に作成したキー コンテナーの名前に置き換えます。

    az keyvault secret set --vault-name {KEY VAULT NAME} --name "SecretName" --value "secret_value_1_prod"
az keyvault secret set --vault-name {KEY VAULT NAME} --name "Section--SecretName" --value "secret_value_2_prod"

Azure でホストされていないアプリにアプリケーション ID と X.509 証明書を使用する

Azure の外部でアプリがホストされている場合に、Microsoft Entra ID アプリケーション ID と X.509 証明書を使用してボールトに対して認証するよう、Key Vault とアプリを構成します。 詳細については、「About keys, secrets, and certificates (キー、シークレット、証明書について)」を参照してください。

Note

アプリケーション ID と X.509 証明書の使用は、Azureでホストされているアプリでサポートされていますが、この方法はお勧めしません。 Azure でアプリをホストするときは、代わりに、Azure リソースのマネージド ID を使います。 マネージド ID では、証明書をアプリまたは Development 環境に格納する必要はありません。

サンプル アプリでは、#define先頭にある プリプロセッサ ディレクティブが Certificate に設定されている場合、アプリケーション ID と X.509 証明書を使用します。

  1. PKCS#12 アーカイブ (.pfx) 証明書を作成します。 証明書を作成するためのオプションには、Windows 上の New-SelfSignedCertificate と OpenSSL があります。

  2. 現在のユーザーの個人証明書ストアに証明書をインストールします。 キーをエクスポート可能としてマークするのは任意です。 このプロセスで後ほど使うので、証明書のサムプリントを記録しておきます。

  3. PKCS#12 アーカイブ (.pfx) 証明書を、DER でエンコードされた証明書 (.cer) としてエクスポートします。

  4. アプリを Microsoft Entra ID に登録します (アプリの登録)。

  5. DER でエンコードされた証明書 (.cer) をMicrosoft Entra IDにアップロードします。

    1. Microsoft Entra ID でアプリを選択します。
    2. [証明書とシークレット] に移動します。
    3. [証明書のアップロード] を選んで、公開キーが含まれる証明書をアップロードします。 .cer、.pem、または .crt の証明書を使用できます。

  6. キー コンテナー名、アプリケーション ID、証明書の拇印をアプリケーション appsettings.json ファイルに格納します。

  7. Azure ポータルで、Key Vaults に移動します。

  8. 運用環境で Azure Key Vault を使用したシークレット ストレージ セクションで作成したキー コンテナーを選択します。

  9. アクセス ポリシーを選択してから 、アクセス ポリシーの追加を選択します。

  10. [シークレットのアクセス許可] を開き、アプリに Get と List のアクセス許可を付与します。

  11. プリンシパルを選択 を選択します。 名前で登録済みのアプリを選択し、次に Select を選択します。

  12. OK を選択し、保存を選択します。

  13. アプリケーションをデプロイします。

Certificate サンプル アプリは、シークレット名と同じ名前の IConfigurationRoot から構成値を取得します。

  • 非階層値: SecretName の値は、 config["SecretName"]で取得されます。
  • 階層値 (セクション): コロン (:) 表記または GetSection メソッドを使用します。 構成値を取得するには、次のいずれかの方法を使用します。
    • config["Section:SecretName"]
    • config.GetSection("Section")["SecretName"]

オペレーティング システムは X.509 証明書を管理します。 アプリは、appsettings.jsonファイルによって指定された値を使用して、AddAzureKeyVault メソッドを呼び出します。


using System.Security.Cryptography.X509Certificates;
using Azure.Identity;

var builder = WebApplication.CreateBuilder(args);

if (builder.Environment.IsProduction())
{
    using var x509Store = new X509Store(StoreLocation.CurrentUser);

    x509Store.Open(OpenFlags.ReadOnly);

    var x509Certificate = x509Store.Certificates
        .Find(
            X509FindType.FindByThumbprint,
            builder.Configuration["AzureADCertThumbprint"],
            validOnly: false)
        .OfType<X509Certificate2>()
        .Single();

    builder.Configuration.AddAzureKeyVault(
        new Uri($"https://{builder.Configuration["KeyVaultName"]}.vault.azure.net/"),
        new ClientCertificateCredential(
            builder.Configuration["AzureADDirectoryId"],
            builder.Configuration["AzureADApplicationId"],
            x509Certificate));
}

var app = builder.Build();

値の例:

  • キー コンテナー名: contosovault
  • アプリケーション ID: 00001111-aaaa-2222-bbbb-3333cccc4444
  • 証明書のサムプリント: fe14593dd66b2406c5269d742d04b6e1ab03adb1

appsettings.json ファイル内の値:

{
  "KeyVaultName": "Key Vault Name",
  "AzureADApplicationId": "Azure AD Application ID",
  "AzureADCertThumbprint": "Azure AD Certificate Thumbprint",
  "AzureADDirectoryId": "Azure AD Directory ID"
}

アプリを実行すると、Web ページに読み込まれたシークレット値が表示されます。 Development環境では、シークレット値は_devサフィックスと共に読み込まれます。 Production環境では、値は _prod サフィックスと共に読み込まれます。

Azure リソースのマネージド ID を使用する

Azure にデプロイされたアプリでは、Azure リソースのマネージド ID を利用できます。 マネージド ID を使用すると、アプリケーションコードや構成に資格情報を格納することなく、Microsoft Entra ID認証を使用してアプリをAzure Key Vaultで認証できます。

サンプル アプリでは、#define先頭にある プリプロセッサ ディレクティブが Managed に設定されている場合、システム割り当てマネージド ID が使用されます。 Azure App Service アプリのマネージド ID を作成するには、「App Service と Azure Functions のマネージド ID を使用する方法」を参照してください。 マネージド ID が作成されたら、App Service の Identity パネルの Azure ポータルに表示されているアプリケーション オブジェクト ID を書き留めます。

アプリケーションappsettings.jsonファイルにキー コンテナー名 を 入力します。 Managed バージョンに設定すると、サンプル アプリにアプリケーション ID とパスワード (クライアント シークレット) は必要ないため、それらの構成エントリは無視してかまいません。 アプリはAzureにデプロイされ、Azureは、appsettings.json ファイルに格納されているコンテナー名を使用してのみKey Vaultにアクセスするようにアプリを認証します。

サンプル アプリを Azure App Service にデプロイします。

Azure CLIとアプリのオブジェクト ID を使用して、キー コンテナーにアクセスするための list および get アクセス許可をアプリに提供します。

az keyvault set-policy --name {KEY VAULT NAME} --object-id {OBJECT ID} --secret-permissions get list

Azure CLI、Azure PowerShell、またはAzure ポータルを使用して、アプリを開始します。

サンプル アプリによって、DefaultAzureCredential クラスのインスタンスが作成されます。 資格情報を使って、Azure リソースの環境からアクセス トークンの取得が試行されます。

using Azure.Identity;

var builder = WebApplication.CreateBuilder(args);

if (builder.Environment.IsProduction())
{
    builder.Configuration.AddAzureKeyVault(
        new Uri($"https://{builder.Configuration["KeyVaultName"]}.vault.azure.net/"),
        new DefaultAzureCredential());
}

Note

前の例では、DefaultAzureCredential クラスを使用して、Azureに展開するアプリを開発するときに認証を簡略化します。 この方法では、Azure ホスティング環境で使用される資格情報と、ローカル開発で使用される資格情報が組み合わせられています。 実装を運用環境に移行する場合は、 ManagedIdentityCredential クラスなどの代替手段を使用することをお勧めします。 詳細については、「Azure でホストされる .NET アプリをシステム割り当てマネージド ID を使用して Azure リソースに認証する」を参照してください。

キー ボールト名の例: contosovault

appsettings.json ファイル内の名前の値:

{
  "KeyVaultName": "Key Vault Name"
}

ユーザー割り当てマネージド ID を使用するアプリの場合は、次のいずれかの方法を使用してマネージド ID のクライアント ID を構成します。

  • AZURE_CLIENT_ID 環境変数を設定します。

  • DefaultAzureCredentialOptions.ManagedIdentityClientId メソッドを呼び出すときに、AddAzureKeyVault プロパティを設定します。

    builder.Configuration.AddAzureKeyVault(
    new Uri($"https://{builder.Configuration["KeyVaultName"]}.vault.azure.net/"),
    new DefaultAzureCredential(new DefaultAzureCredentialOptions
    {
        ManagedIdentityClientId = builder.Configuration["AzureADManagedIdentityClientId"]
    }));

アプリを実行すると、Web ページに読み込まれたシークレット値が表示されます。 Development環境では、シークレット値はシークレット マネージャーによって提供されるため、_devサフィックスを持ちます。 Production環境では、値は Azure Key Vault によって提供されるため、_prod サフィックスを使用して読み込まれます。

Access denied エラーが発生した場合は、アプリが Microsoft Entra ID に登録され、コンテナーにアクセスできるかどうかを確認します。 Azureでサービスを再起動したことを確認します。

マネージド ID とAzure Pipelinesでプロバイダーを使用する方法については、「connect to Azure with an Azure Resource Manager service connection」を参照してください。

構成オプション

AddAzureKeyVault メソッドは、AzureKeyVaultConfigurationOptions オブジェクトを受け取ることができます。

// using Azure.Extensions.AspNetCore.Configuration.Secrets;

builder.Configuration.AddAzureKeyVault(
    new Uri($"https://{builder.Configuration["KeyVaultName"]}.vault.azure.net/"),
    new DefaultAzureCredential(),
    new AzureKeyVaultConfigurationOptions
    {
        // ...
    });

AzureKeyVaultConfigurationOptions オブジェクトには次のプロパティがあります。

Property Description
Manager シークレットの読み込みを制御するために使用する KeyVaultSecretManager インスタンスを指定します。
ReloadInterval キー ボールトの変更をポーリングして確認する際に、試行間で待機する TimeSpan を指定します。 既定値は null です (構成が再度読み込まれることはありません)。

キー名のプレフィックスを使用する

AddAzureKeyVault メソッドは、KeyVaultSecretManager の実装を受け入れるオーバーロードを提供します。これにより、Key Vaultシークレットを構成キーに変換する方法を制御できます。 たとえば、アプリの起動時に指定するプレフィックス値に基づいてシークレット値を読み込むように、インターフェイスを実装できます。 この手法を使用すると、たとえば、アプリのバージョンに基づいてシークレットを読み込むことができます。

Important

次を行う目的で、Key Vault シークレットにプレフィックスを使用しないでください。

  • 複数のアプリのシークレットを同じキー コンテナーに配置します。
  • 環境シークレット (たとえば、 Development シークレットと Production シークレット) を同じキー コンテナーに配置します。

アプリと開発/運用環境が異なる場合は、アプリ環境を分離して最高レベルのセキュリティを確保するために、個別のキー コンテナーを使用する必要があります。

次の例では、Development 環境に Secret Manager を使用して、5000-AppSecret 用のシークレットが Key Vault に設定されます（Key Vault のシークレット名にはピリオドを使用できないため）。 このシークレットは、アプリのバージョン 5.0.0.0 のアプリ シークレットを表します。 別のバージョンのアプリ 5.1.0.0 では、シークレットが (Secret Manager を使用して) 5100-AppSecret同じキー コンテナーに追加されます。 各アプリ バージョンで、そのバージョン管理されたシークレット値が AppSecret として構成に読み込まれ、シークレットを読み込んだバージョンは削除されます。

AddAzureKeyVault メソッドは、カスタムのKeyVaultSecretManager実装で呼び出されます。

// using Azure.Extensions.AspNetCore.Configuration.Secrets;

builder.Configuration.AddAzureKeyVault(
    new Uri($"https://{builder.Configuration["KeyVaultName"]}.vault.azure.net/"),
    new DefaultAzureCredential(),
    new SamplePrefixKeyVaultSecretManager("5000"));

実装は、シークレットのバージョン プレフィックスに対応して、適切なシークレットを構成に読み込みます。

  • Load メソッドは、名前がプレフィックスで始まるときにシークレットを読み込みます。 それ以外のシークレットは読み込まれません。
  • GetKeyメソッド:
    • シークレット名からプレフィックスを削除します。
    • 任意の名前の 2 つのダッシュ (--) を KeyDelimiterに置き換えます。 この区切り記号 (通常はコロン :) は Key Vault、シークレット名にコロン (:) を許可しないため、構成で使用されます。
public class SamplePrefixKeyVaultSecretManager : KeyVaultSecretManager
{
    private readonly string _prefix;

    public SamplePrefixKeyVaultSecretManager(string prefix)
        => _prefix = $"{prefix}-";

    public override bool Load(SecretProperties properties)
        => properties.Name.StartsWith(_prefix);

    public override string GetKey(KeyVaultSecret secret)
        => secret.Name[_prefix.Length..].Replace("--", ConfigurationPath.KeyDelimiter);
}

プロバイダー アルゴリズムは、 Load メソッドを呼び出し、キー コンテナー シークレットを反復処理して、バージョン プレフィックス付きのシークレットを検索します。 Load でバージョン プレフィックスが見つかった場合、アルゴリズムで GetKey メソッドを使用してシークレット名の構成名が返されます。 シークレットの名前からはバージョン プレフィックスが削除されます。 アプリケーション構成の名前と値のペアに読み込むため、シークレット名の残りの部分が返されます。

この方法を実装する場合は、次の手順を実行します。

  1. アプリケーション プロジェクト ファイルでアプリケーションのバージョンを指定します。 次の例では、アプリケーションのバージョンが 5.0.0.0 に設定されています。

    <PropertyGroup>
  <Version>5.0.0.0</Version>
</PropertyGroup>

  2. <UserSecretsId> プロパティがアプリケーション プロジェクト ファイルで定義されていることを確認します。ここで、{GUID}はユーザー指定の GUID です。

    <PropertyGroup>
  <UserSecretsId>{GUID}</UserSecretsId>
</PropertyGroup>

    シークレット マネージャーを使用して、次のシークレットをローカルに保存します。

    dotnet user-secrets set "5000-AppSecret" "5.0.0.0_secret_value_dev"
dotnet user-secrets set "5100-AppSecret" "5.1.0.0_secret_value_dev"

  3. 次のAzure CLI コマンドを使用して、シークレットをAzure Key Vaultに保存します。

    az keyvault secret set --vault-name {KEY VAULT NAME} --name "5000-AppSecret" --value "5.0.0.0_secret_value_prod"
az keyvault secret set --vault-name {KEY VAULT NAME} --name "5100-AppSecret" --value "5.1.0.0_secret_value_prod"

このプロセスでは、次のタスクが完了します。

  • アプリの実行時に、実装によって Key Vault のシークレットが読み込まれます。 5000-AppSecretの文字列シークレットは、アプリのプロジェクト ファイル (5.0.0.0) で指定されたアプリケーションのバージョンと一致します。

  • バージョン 5000 (およびダッシュ) が、キー名から除去されます。 アプリ全体で、キー AppSecret を使用して構成を読み取ると、 シークレットの値が読み込まれます。

  • プロジェクト ファイルでアプリケーションのバージョンが5.1.0.0に変更され、アプリが再度実行された場合、返されるシークレット値は5.1.0.0_secret_value_dev環境でDevelopmentされ、5.1.0.0_secret_value_prodでProductionされます。

Note

また、SecretClient メソッドに独自のAddAzureKeyVault実装を提供することもできます。 カスタム クライアントを使用すると、アプリ全体でクライアントの 1 つのインスタンスを共有できます。

配列をクラスにバインドする

プロバイダーで、構成の値を、POCO 配列にバインドするための配列に読み取ることができます。

キーにコロン (:) 区切り記号を含めることができる構成ソースから読み取る場合、配列 (:0:、:1:、… :{n}:) を構成するキーを区別するために、数値キー セグメントが使用されます。 詳しくは、構成での配列からクラスへのバインドに関する記事をご覧ください。

Key Vaultキーでは、コロン (:) を区切り記号として使用することはできません。 この記事で説明する方法では、階層値 (セクション) の区切り記号として二重ダッシュ (--) を使用します。 配列キーは、二重ダッシュと数値キー セグメント (--0--、--1--、..) を使用してKey Vaultに格納されます。--{n}--)。

JSON ファイルに指定されている次の Serilog ログ プロバイダーの構成を確認します。 WriteTo 配列では、2 つの Serilog "シンク" を反映した 2 つのオブジェクト リテラルが定義されており、ログ出力の宛先が記述されています。

"Serilog": {
  "WriteTo": [
    {
      "Name": "AzureTableStorage",
      "Args": {
        "storageTableName": "logs",
        "connectionString": "DefaultEnd...ountKey=Eby8...GMGw=="
      }
    },
    {
      "Name": "AzureDocumentDB",
      "Args": {
        "endpointUrl": "https://contoso.documents.azure.com:443",
        "authorizationKey": "Eby8...GMGw=="
      }
    }
  ]
}

JSON ファイルの構成は、二重ダッシュ (--) 表記と数値セグメントを使用してKey Vaultに格納されます。

Key Value
Serilog--WriteTo--0--Name AzureTableStorage
Serilog--WriteTo--0--Args--storageTableName logs
Serilog--WriteTo--0--Args--connectionString DefaultEnd...ountKey=Eby8...GMGw==
Serilog--WriteTo--1--Name AzureDocumentDB
Serilog--WriteTo--1--Args--endpointUrl https://contoso.documents.azure.com:443
Serilog--WriteTo--1--Args--authorizationKey Eby8...GMGw==

シークレットを再読み込みする

既定では、構成プロバイダーはアプリケーションの有効期間中にシークレットをキャッシュします。 アプリは、後でキー コンテナーで無効または更新されたシークレットを無視します。

シークレットを再読み込みするには、 IConfigurationRoot.Reload メソッドを呼び出します。

config.Reload();

指定した間隔で定期的にシークレットを再度読み込むには、AzureKeyVaultConfigurationOptions.ReloadInterval プロパティを設定します。 詳しくは、「構成オプション」をご覧ください。

無効なシークレットと期限切れのシークレット

期限切れのシークレットは、構成プロバイダーに既定で含まれます。 アプリ構成でこれらのシークレットの値を除外するには、期限切れのシークレットを更新するか、カスタム構成プロバイダーを使用して構成を指定します。

class SampleKeyVaultSecretManager : KeyVaultSecretManager
{
  public override bool Load(SecretProperties properties) =>
    properties.ExpiresOn.HasValue &&
    properties.ExpiresOn.Value > DateTimeOffset.Now;
}

このカスタム KeyVaultSecretManager プロバイダーを AddAzureKeyVault メソッドに渡します。

// using Azure.Extensions.AspNetCore.Configuration.Secrets;

builder.Configuration.AddAzureKeyVault(
    new Uri($"https://{builder.Configuration["KeyVaultName"]}.vault.azure.net/"),
    new DefaultAzureCredential(),
    new SampleKeyVaultSecretManager());

無効なシークレットはKey Vaultから取得できないため、含まれません。

Note

前の例では、DefaultAzureCredential クラスを使用して、Azureに展開するアプリを開発するときに認証を簡略化します。 この方法では、Azure ホスティング環境で使用される資格情報と、ローカル開発で使用される資格情報が組み合わせられています。 実装を運用環境に移行する場合は、 ManagedIdentityCredential クラスなどの代替手段を使用することをお勧めします。 詳細については、「Azure でホストされる .NET アプリをシステム割り当てマネージド ID を使用して Azure リソースに認証する」を参照してください。

構成の読み込みに関する問題に対処する

プロバイダーを使用してアプリが構成の読み込みに失敗すると、エラー メッセージが ASP.NET Core ログ 記録インフラストラクチャに書き込まれます。

次の条件では、構成の読み込みを妨げる可能性があります。

  • アプリまたは証明書が Microsoft Entra ID で正しく構成されていない。
  • コンテナーは Azure Key Vault に存在しない。
  • アプリには Vault へのアクセスが許可されていない。
  • アクセス ポリシーに、Get と List のアクセス許可が含まれません。
  • コンテナーで、構成データ (名前と値のペア) の名前が間違っているか、欠落しているか、無効になっている。
  • アプリのキー コンテナー名 (KeyVaultName)、Microsoft Entra ID アプリケーション ID (AzureADApplicationId)、Microsoft Entra ID 証明書の拇印 (AzureADCertThumbprint)、または Microsoft Entra ID ディレクトリ ID (AzureADDirectoryId) のいずれかが正しくありません。
  • アプリにKey Vaultアクセス ポリシーが追加されると、ポリシーは正常に作成されますが、ユーザーは Access ポリシー ダイアログで Save を選択しませんでした。

関連するコンテンツ

この記事では、Azure Key Vault 構成プロバイダーを使用して、Azure Key Vault シークレットからアプリ構成値を読み込む方法について説明します。 Azure Key Vault はクラウドベースのサービスで、アプリとサービスで使われる暗号化キーとシークレットを保護するのに役立ちます。 ASP.NET Core アプリで Azure Key Vault を使用する一般的なシナリオは次のとおりです。

  • 機密性の高い構成データへのアクセスを制御する。
  • 構成データを保存するときに、FIPS 140-2 Level 2 で検証されたハードウェア セキュリティ モジュール (HSM) の要件を満たす。

Packages

次のパッケージのパッケージ参照を追加します。

サンプル アプリ

サンプル アプリは、#define の先頭にある Program.cs プリプロセッサ ディレクティブによって決まる 2 つのモードのどちらかで実行されます。

  • Certificate: Azure Key Vault クライアント ID と X.509 証明書を使用して、Azure Key Vault に格納されているシークレットにアクセスする方法を示します。 このサンプルは、Azure App Service または ASP.NET Core アプリにサービスを提供できる任意のホストのどちらにデプロイされるかに関係なく、どこからでも実行できます。
  • Managed: Azure リソースのマネージド ID を使用する方法を示します。 マネージド ID は、アプリのコードまたは構成に資格情報を格納せずに、Azure リソースのマネージド ID を使用して Azure Key Vault に対してアプリを認証します。 マネージド ID を使用して認証する場合、Azure リソースのアプリ ID とパスワードのマネージド ID (クライアント シークレット) は必要ありません。 サンプルの Managed バージョンは、Azure にデプロイする必要があります。 「Azure リソースのマネージド ID を使用する」セクションのガイダンスに従ってください。

プリプロセッサ ディレクティブ (#define) を使用したサンプル アプリの構成に関する詳細については、ASP.NET Core の概要に関する記事を参照してください。

サンプル コードを表示またはダウンロードする (ダウンロード方法)

Development環境でのシークレット ストレージ

Secret Manager を使用して、シークレットをローカル環境に設定します。 Development環境のローカル コンピューターでサンプル アプリを実行すると、ローカル ユーザー シークレット ストアからシークレットが読み込まれます。

Secret Manager には、アプリのプロジェクト ファイル内の <UserSecretsId> プロパティが必要です。 プロパティの値 ({GUID}) を任意の一意の GUID に設定します。

<PropertyGroup>
  <UserSecretsId>{GUID}</UserSecretsId>
</PropertyGroup>

シークレットは、名前と値のペアとして作成されます。 階層値 (構成セクション) では、:のキー名の区切り記号として (コロン) を使用します。

Secret Manager は、プロジェクトのコンテンツ ルートで開いたコマンド シェルから使用します。{SECRET NAME} は名前で、{SECRET VALUE} は値です。

dotnet user-secrets set "{SECRET NAME}" "{SECRET VALUE}"

プロジェクトのコンテンツ ルートからコマンド シェルで次のコマンドを実行して、サンプル アプリのシークレットを設定します。

dotnet user-secrets set "SecretName" "secret_value_1_dev"
dotnet user-secrets set "Section:SecretName" "secret_value_2_dev"

これらのシークレットが Azure Key Vault セクションを使用してProduction環境のシークレット ストレージ内の Azure Key Vault に格納されている場合、_dev サフィックスは _prod に変更されます。 サフィックスにより、アプリの出力を見ると構成値のソースがわかるようにします。

Azure Key Vault を使用した Production 環境でのシークレット ストレージ

次の手順のようにして、Azure Key Vault を作成し、サンプル アプリのシークレットをその中に格納します。 詳細については、「クイック スタート: Azure CLI を使用して Azure Key Vault との間でシークレットの設定と取得を行う」を参照してください。

  1. Azure portal で次のいずれかの方法を使って Azure Cloud Shell を開きます。

    • コード ブロックの右上隅にある [使ってみる] を選択します。 テキスト ボックスで検索文字列 "Azure CLI" を使います。
    • [Cloud Shell を起動する] ボタンを使って、ブラウザーで Cloud Shell を開きます。
    • Azure portal の右上隅にあるメニューの [Cloud Shell] ボタンを選択します。

    詳しくは、Azure CLI に関するページと、「Azure Cloud Shell の概要」をご覧ください。

  2. まだ認証されていない場合は、az login コマンドでサインインします。

  3. 次のコマンドを使ってリソース グループを作成します。{RESOURCE GROUP NAME} は新しいリソース グループの名前、{LOCATION} は Azure リージョンです。

    az group create --name "{RESOURCE GROUP NAME}" --location {LOCATION}

  4. 次のコマンドを使用して、リソース グループに Key Vault を作成します。ここで、{KEY VAULT NAME} は新しいコンテナーの名前、{LOCATION} は Azure リージョンです。

    az keyvault create --name {KEY VAULT NAME} --resource-group "{RESOURCE GROUP NAME}" --location {LOCATION}

  5. 名前と値のペアとしてコンテナーにシークレットを作成します。

    Azure Key Vault のシークレット名では、英数字とダッシュだけを使用できます。 Key Vault のシークレット名ではコロンが使えないため、階層値 (構成セクション) では区切り記号として -- (2 つのダッシュ) を使います。 ASP.NET Core の構成では、セクションとサブキーをコロンで区切ります。 アプリの構成にシークレットが読み込まれるときに、2 つのダッシュのシーケンスはコロンで置き換えられます。

    次のシークレットは、サンプル アプリで使用するためのものです。 値には、シークレット マネージャーから_prod環境に読み込まれた_devサフィックス値と区別するためのDevelopmentサフィックスが含まれています。 {KEY VAULT NAME} を、前のステップで作成した Key Vault の名前に置き換えます。

    az keyvault secret set --vault-name {KEY VAULT NAME} --name "SecretName" --value "secret_value_1_prod"
az keyvault secret set --vault-name {KEY VAULT NAME} --name "Section--SecretName" --value "secret_value_2_prod"

Azure でホストされていないアプリにアプリケーション ID と X.509 証明書を使用する

Azure の外部でアプリが ホストされている場合に、Microsoft Entra ID アプリケーション ID と X.509 証明書を使用してコンテナーに対して認証するように Azure Key Vault とアプリを構成します。 詳細については、「About keys, secrets, and certificates (キー、シークレット、証明書について)」を参照してください。

Note

Azure でホストされているアプリについても、アプリケーション ID と X.509 証明書を使用できますが、お勧めしません。 Azure でアプリをホストするときは、代わりに、Azure リソースのマネージド ID を使います。 マネージド ID では、証明書をアプリまたは Development 環境に格納する必要はありません。

#define の先頭にある Program.cs プリプロセッサ ディレクティブを Certificate に設定した場合、サンプル アプリにはアプリケーション ID と X.509 証明書が使われます。

  1. PKCS#12 アーカイブ (.pfx) 証明書を作成します。 証明書を作成するためのオプションには、Windows 上の New-SelfSignedCertificate と OpenSSL があります。
  2. 現在のユーザーの個人証明書ストアに証明書をインストールします。 キーをエクスポート可能としてマークするのは任意です。 このプロセスで後ほど使うので、証明書のサムプリントを記録しておきます。
  3. PKCS#12 アーカイブ (.pfx) 証明書を、DER でエンコードされた証明書 (.cer) としてエクスポートします。
  4. アプリを Microsoft Entra ID に登録します (アプリの登録)。
  5. DER でエンコードされた証明書 (.cer) を Microsoft Entra ID にアップロードします。
    1. Microsoft Entra ID でアプリを選択します。
    2. [証明書とシークレット] に移動します。
    3. [証明書のアップロード] を選んで、公開キーが含まれる証明書をアップロードします。 .cer、.pem、または .crt の証明書を使用できます。
  6. Key Vault 名、アプリケーション ID、証明書の母音を、アプリの appsettings.json ファイルに格納します。
  7. Azure portal で [Key Vault] に移動します。
  8. [Azure Key Vault を使用してProduction環境のシークレット ストレージ] セクションで作成した Key Vault を選択します。
  9. [アクセス ポリシー] を選択します。
  10. [アクセス ポリシーの追加] を選択します。
  11. [シークレットのアクセス許可] を開き、アプリに Get と List のアクセス許可を付与します。
  12. [プリンシパルの選択] を選び、登録済みのアプリの名前を選びます。 [選択] ボタンを選択します。
  13. [OK] を選択.
  14. 保存 を選択します。
  15. アプリケーションをデプロイします。

Certificate サンプル アプリは、シークレット名と同じ名前の IConfigurationRoot から構成値を取得します。

  • 非階層値: SecretName の値は、config["SecretName"] で取得されます。
  • 階層値 (セクション): : (コロン) 表記または GetSection メソッドを使用します。 次のいずれかの方法を使用して、構成値を取得します。
    • config["Section:SecretName"]
    • config.GetSection("Section")["SecretName"]

X.509 証明書は OS によって管理されます。 アプリでは、AddAzureKeyVault ファイルによって提供された値を使用して appsettings.json を呼び出します。

// using System.Linq;
// using System.Security.Cryptography.X509Certificates;
// using Azure.Extensions.AspNetCore.Configuration.Secrets;
// using Azure.Identity;

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureAppConfiguration((context, config) =>
        {
            if (context.HostingEnvironment.IsProduction())
            {
                var builtConfig = config.Build();

                using var store = new X509Store(StoreLocation.CurrentUser);
                store.Open(OpenFlags.ReadOnly);
                var certs = store.Certificates.Find(
                    X509FindType.FindByThumbprint,
                    builtConfig["AzureADCertThumbprint"], false);

                config.AddAzureKeyVault(new Uri($"https://{builtConfig["KeyVaultName"]}.vault.azure.net/"),
                                        new ClientCertificateCredential(builtConfig["AzureADDirectoryId"], builtConfig["AzureADApplicationId"], certs.OfType<X509Certificate2>().Single()),
                                        new KeyVaultSecretManager());

                store.Close();
            }
        })
        .ConfigureWebHostDefaults(webBuilder => webBuilder.UseStartup<Startup>());

値の例:

  • Key Vault 名: contosovault
  • アプリケーション ID: 00001111-aaaa-2222-bbbb-3333cccc4444
  • 証明書のサムプリント: fe14593dd66b2406c5269d742d04b6e1ab03adb1

appsettings.json:

{
  "KeyVaultName": "Key Vault Name",
  "AzureADApplicationId": "Azure AD Application ID",
  "AzureADCertThumbprint": "Azure AD Certificate Thumbprint",
  "AzureADDirectoryId": "Azure AD Directory ID"
}

アプリを実行すると、Web ページに読み込まれたシークレット値が表示されます。 Development環境では、シークレット値は_devサフィックスと共に読み込まれます。 Production環境では、値は _prod サフィックスと共に読み込まれます。

Azure リソースのマネージド ID を使用する

Azure にデプロイされたアプリでは、Azure リソースのマネージド ID を利用できます。 マネージド ID を使用すると、アプリは、アプリに格納されている資格情報 (アプリケーション ID とパスワード/クライアント シークレット) なしで Microsoft Entra ID 認証を使用して Azure Key Vault で認証できます。

#define の先頭にある Program.cs プリプロセッサ ディレクティブを Managed に設定した場合、サンプル アプリには Azure リソースのマネージド ID が使われます。

アプリの appsettings.json ファイルにコンテナー名を入力します。 Managed バージョンに設定すると、サンプル アプリにアプリケーション ID とパスワード (クライアント シークレット) は必要ないため、それらの構成エントリは無視してかまいません。 アプリは Azure にデプロイされており、Azure は、appsettings.json ファイルに格納されているコンテナー名のみを使用して、アプリによる Azure Key Vault へのアクセスを認証します。

サンプル アプリを Azure App Service にデプロイします。

Azure App Service にデプロイされたアプリは、サービスの作成時に Microsoft Entra ID に自動的に登録されます。 次のコマンドで使用するために、デプロイからオブジェクト ID を取得します。 オブジェクト ID は、Azure portal の App Service の Identity パネルに表示されます。

Azure CLI とアプリのオブジェクト ID を使用して、アプリにコンテナーにアクセスするための list および get のアクセス許可を付与します。

az keyvault set-policy --name {KEY VAULT NAME} --object-id {OBJECT ID} --secret-permissions get list

Azure CLI、PowerShell、または Azure portal を使って、アプリを再起動します。

サンプル アプリで次のことが行われます。

  • DefaultAzureCredential クラスのインスタンスを作成します。 資格情報によって、Azure リソースの環境からアクセス トークンの取得が試みられます。
  • SecretClient のインスタンスで、新しい DefaultAzureCredential が作成されます。
  • SecretClient インスタンスと共に使用される KeyVaultSecretManager インスタンスによって、シークレット値が読み込まれ、キー名の二重ダッシュ (--) がコロン (:) に置き換えられます。
// using Azure.Security.KeyVault.Secrets;
// using Azure.Identity;
// using Azure.Extensions.AspNetCore.Configuration.Secrets;

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureAppConfiguration((context, config) =>
        {
            if (context.HostingEnvironment.IsProduction())
            {
                var builtConfig = config.Build();
                var secretClient = new SecretClient(
                    new Uri($"https://{builtConfig["KeyVaultName"]}.vault.azure.net/"),
                    new DefaultAzureCredential());
                config.AddAzureKeyVault(secretClient, new KeyVaultSecretManager());
            }
        })
        .ConfigureWebHostDefaults(webBuilder => webBuilder.UseStartup<Startup>());

Note

前の例では、 DefaultAzureCredential を使用して認証を簡略化し、Azure ホスティング環境で使用される資格情報とローカル開発で使用される資格情報を組み合わせて Azure にデプロイするアプリを開発しています。 運用環境に移行する場合は、 ManagedIdentityCredentialなど、別の選択肢を選択することをお勧めします。 詳細については、「 システム割り当てマネージド ID を使用して Azure リソースに対して Azure でホストされる .NET アプリを認証する」を参照してください。

Key Vault 名の値の例: contosovault

appsettings.json:

{
  "KeyVaultName": "Key Vault Name"
}

アプリを実行すると、Web ページに読み込まれたシークレット値が表示されます。 Development環境では、シークレット値はシークレット マネージャーによって提供されるため、_devサフィックスを持ちます。 Production環境では、値は Azure Key Vault によって提供されるため、_prod サフィックスを使用して読み込まれます。

Access denied エラーが表示された場合は、アプリが Microsoft Entra ID に登録されており、コンテナーへのアクセスが提供されていることを確認してください。 Azure でサービスを再起動したことを確認します。

マネージド ID と Azure Pipelines でプロバイダーを使用する方法については、「マネージド サービス ID を持 つ VM への Azure Resource Manager サービス接続を作成する」を参照してください。

構成オプション

AddAzureKeyVault は、AzureKeyVaultConfigurationOptions オブジェクトを受け入れることができます。

config.AddAzureKeyVault(
    new SecretClient(
        new Uri("Your Key Vault Endpoint"),
        new DefaultAzureCredential(),
        new AzureKeyVaultConfigurationOptions())
    {
        ...
    });

Note

前の例では、 DefaultAzureCredential を使用して認証を簡略化し、Azure ホスティング環境で使用される資格情報とローカル開発で使用される資格情報を組み合わせて Azure にデプロイするアプリを開発しています。 運用環境に移行する場合は、 ManagedIdentityCredentialなど、別の選択肢を選択することをお勧めします。 詳細については、「 システム割り当てマネージド ID を使用して Azure リソースに対して Azure でホストされる .NET アプリを認証する」を参照してください。

AzureKeyVaultConfigurationOptions オブジェクトには次のプロパティが含まれます。

Property Description
Manager シークレットの読み込みの制御に使用される KeyVaultSecretManager インスタンス。
ReloadInterval コンテナーの変更をポーリングする試行の合間に待機する TimeSpan。 既定値は null です (構成が再度読み込まれることはありません)。

キー名のプレフィックスを使用する

AddAzureKeyVault は、KeyVaultSecretManager の実装を受け入れるオーバーロードを提供します。これにより、Key Vault シークレットを構成キーに変換する方法を制御できます。 たとえば、アプリの起動時に指定するプレフィックス値に基づいてシークレット値を読み込むように、インターフェイスを実装できます。 この手法を使用すると、たとえば、アプリのバージョンに基づいてシークレットを読み込むことができます。

Warning

次を行う目的で、Key Vault シークレットにプレフィックスを使用しないでください。

  • 複数のアプリ用のシークレットを同じコンテナーに配置する。
  • 環境シークレット (たとえば、"開発" と "運用" シークレット) を同じコンテナーに配置する。

異なるアプリおよび開発と運用環境には、個別の Key Vault を使用し、最高レベルのセキュリティのためにアプリ環境を分離する必要があります。

次の例では、Development (Key Vault シークレット名ではピリオドは使用できません) に対して、Key Vault でシークレットが確立されます (5000-AppSecret環境ではシークレット マネージャーを使用します)。 このシークレットは、アプリのバージョン 5.0.0.0 のアプリ シークレットを表します。 アプリの別のバージョン (5.1.0.0) では、5100-AppSecret のシークレットがコンテナーに追加され (シークレット マネージャーが使用され) ます。 各アプリ バージョンで、そのバージョン管理されたシークレット値が AppSecret として構成に読み込まれ、シークレットを読み込んだバージョンは削除されます。

AddAzureKeyVault は、KeyVaultSecretManager のカスタム実装で呼び出されます。

config.AddAzureKeyVault(
    $"https://{builtConfig["KeyVaultName"]}.vault.azure.net/",
    builtConfig["AzureADApplicationId"],
    certs.OfType<X509Certificate2>().Single(),
    new PrefixKeyVaultSecretManager(versionPrefix));

実装は、シークレットのバージョン プレフィックスに対応して、適切なシークレットを構成に読み込みます。

  • シークレットの名前がプレフィックスで始まっていると、Load によって読み込まれます。 それ以外のシークレットは読み込まれません。
  • GetKey:
    • シークレット名からプレフィックスを削除します。
    • 名前の 2 つのダッシュを、構成で使用される区切り記号 (通常はコロン) である KeyDelimiter に置き換えます。 Azure Key Vault では、シークレット名にコロンを使用することはできません。
public class PrefixKeyVaultSecretManager : KeyVaultSecretManager
{
    private readonly string _prefix;

    public PrefixKeyVaultSecretManager(string prefix)
    {
        _prefix = $"{prefix}-";
    }

    public override bool Load(SecretProperties secret)
    {
        return secret.Name.StartsWith(_prefix);
    }

    public override string GetKey(KeyVaultSecret secret)
    {
        return secret.Name
            .Substring(_prefix.Length)
            .Replace("--", ConfigurationPath.KeyDelimiter);
    }
}

Load メソッドは、コンテナー シークレットを反復処理してバージョン プレフィックス付きのシークレットを検索するプロバイダー アルゴリズムによって呼び出されます。 Load でバージョン プレフィックスが見つかった場合、アルゴリズムで GetKey メソッドを使用してシークレット名の構成名が返されます。 シークレットの名前からはバージョン プレフィックスが削除されます。 シークレット名の残りの部分は、アプリの構成名と値のペアに読み込むために返されます。

このアプローチが実装されている場合:

  1. アプリのプロジェクト ファイルで指定されているアプリのバージョン。 次の例では、アプリのバージョンは 5.0.0.0 に設定されています。

    <PropertyGroup>
  <Version>5.0.0.0</Version>
</PropertyGroup>

  2. アプリのプロジェクト ファイルに <UserSecretsId> プロパティが存在することが確認されます。{GUID} はユーザー指定の GUID です。

    <PropertyGroup>
  <UserSecretsId>{GUID}</UserSecretsId>
</PropertyGroup>

    Secret Manager を使用して、次のシークレットをローカル環境に保存します。

    dotnet user-secrets set "5000-AppSecret" "5.0.0.0_secret_value_dev"
dotnet user-secrets set "5100-AppSecret" "5.1.0.0_secret_value_dev"

  3. シークレットは、次の Azure CLI コマンドを使って Azure Key Vault に保存されます。

    az keyvault secret set --vault-name {KEY VAULT NAME} --name "5000-AppSecret" --value "5.0.0.0_secret_value_prod"
az keyvault secret set --vault-name {KEY VAULT NAME} --name "5100-AppSecret" --value "5.1.0.0_secret_value_prod"

  4. アプリが実行されると、Key Vault シークレットが読み込まれます。 5000-AppSecret の文字列シークレットが、アプリのプロジェクト ファイル (5.0.0.0) で指定されているアプリのバージョンと照合されます。

  5. バージョン 5000 (およびダッシュ) が、キー名から除去されます。 アプリ全体で、キー AppSecret を使用して構成を読み取ると、 シークレットの値が読み込まれます。

  6. プロジェクト ファイルでアプリのバージョンが5.1.0.0に変更され、アプリが再度実行された場合、返されるシークレット値は5.1.0.0_secret_value_dev環境でDevelopmentされ、5.1.0.0_secret_value_prodでProductionされます。

Note

また、独自の SecretClient の実装を AddAzureKeyVault に提供することもできます。 カスタム クライアントを使用すると、アプリ全体でクライアントの 1 つのインスタンスを共有できます。

配列をクラスにバインドする

プロバイダーで、構成の値を、POCO 配列にバインドするための配列に読み取ることができます。

キーにコロン (:) 区切り記号を含めることができる構成ソースから読み取る場合、配列 (:0:、:1:、… :{n}:) を構成するキーを区別するために、数値キー セグメントが使用されます。 詳しくは、構成での配列からクラスへのバインドに関する記事をご覧ください。

Azure Key Vault キーでは、区切り記号としてコロンを使用することはできません。 この記事で説明する方法では、階層値 (セクション) の区切り記号として二重ダッシュ (--) を使用します。 配列キーは、二重ダッシュと数値キー セグメント (--0--、--1--、… --{n}--) を使用して、Azure Key Vault に格納されます。

JSON ファイルによって提供される次の Serilog ログ プロバイダーの構成を調べてください。 WriteTo 配列では、2 つの Serilog "シンク" を反映した 2 つのオブジェクト リテラルが定義されており、ログ出力の宛先が記述されています。

"Serilog": {
  "WriteTo": [
    {
      "Name": "AzureTableStorage",
      "Args": {
        "storageTableName": "logs",
        "connectionString": "DefaultEnd...ountKey=Eby8...GMGw=="
      }
    },
    {
      "Name": "AzureDocumentDB",
      "Args": {
        "endpointUrl": "https://contoso.documents.azure.com:443",
        "authorizationKey": "Eby8...GMGw=="
      }
    }
  ]
}

前の JSON ファイルで示されている構成は、二重ダッシュ (--) の表記と数値セグメントを使用して Azure Key Vault に格納されます。

Key Value
Serilog--WriteTo--0--Name AzureTableStorage
Serilog--WriteTo--0--Args--storageTableName logs
Serilog--WriteTo--0--Args--connectionString DefaultEnd...ountKey=Eby8...GMGw==
Serilog--WriteTo--1--Name AzureDocumentDB
Serilog--WriteTo--1--Args--endpointUrl https://contoso.documents.azure.com:443
Serilog--WriteTo--1--Args--authorizationKey Eby8...GMGw==

シークレットを再読み込みする

シークレットは、IConfigurationRoot.Reload が呼び出されるまでキャッシュされます。 その後に無効化または更新されたコンテナー内のシークレットは、Reload が実行されるまでアプリでは尊重されません。

Configuration.Reload();

無効なシークレットと期限切れのシークレット

期限切れのシークレットは、構成プロバイダーに既定で含まれます。 アプリ構成でこれらのシークレットの値を除外するには、期限切れのシークレットを更新するか、カスタム構成プロバイダーを使用して構成を提供します。

class SampleKeyVaultSecretManager : KeyVaultSecretManager
{
  public override bool Load(SecretProperties properties) =>
    properties.ExpiresOn.HasValue &&
    properties.ExpiresOn.Value > DateTimeOffset.Now;
}

このカスタムの KeyVaultSecretManager を AddAzureKeyVault に渡します。

// using Azure.Extensions.AspNetCore.Configuration.Secrets;

config.AddAzureKeyVault(
    new Uri($"https://{builder.Configuration["KeyVaultName"]}.vault.azure.net/"),
    new DefaultAzureCredential(),
    new SampleKeyVaultSecretManager());

無効になったシークレットは Key Vault から取得できず、含まれることはありません。

Note

前の例では、 DefaultAzureCredential を使用して認証を簡略化し、Azure ホスティング環境で使用される資格情報とローカル開発で使用される資格情報を組み合わせて Azure にデプロイするアプリを開発しています。 運用環境に移行する場合は、 ManagedIdentityCredentialなど、別の選択肢を選択することをお勧めします。 詳細については、「 システム割り当てマネージド ID を使用して Azure リソースに対して Azure でホストされる .NET アプリを認証する」を参照してください。

Troubleshoot

アプリでプロバイダーを使用した構成の読み込みが失敗すると、エラー メッセージが ASP.NET Core ログ インフラストラクチャに書き込まれます。 次の状況では、構成を読み込むことができません。

  • アプリまたは証明書が Microsoft Entra ID で正しく構成されていない。
  • コンテナーは Azure Key Vault に存在しない。
  • アプリには Vault へのアクセスが許可されていない。
  • アクセス ポリシーに、Get と List のアクセス許可が含まれません。
  • コンテナーで、構成データ (名前と値のペア) の名前が間違っているか、欠落しているか、無効になっている。
  • アプリの Key Vault 名 (KeyVaultName)、Microsoft Entra ID アプリケーション ID (AzureADApplicationId)、Microsoft Entra ID 証明書の母音 (AzureADCertThumbprint)、または Microsoft Entra ID ディレクトリ ID (AzureADDirectoryId) が間違っている。
  • アプリの Key Vault のアクセス ポリシーを追加するときにポリシーが作成されましたが、[アクセス ポリシー] UI で [保存] ボタンが選択されなかった。

その他のリソース

  • Last updated on