Azure Container Appsで Functions ホストキーストレージを構成する

Functions アクセスキーは、Functions ランタイムが HTTP によってトリガーされるエンドポイントをセキュリティで保護するために使用する認証トークンです。呼び出し元が HTTP 関数を呼び出すと、 ?code= クエリパラメーターまたは x-functions-key ヘッダーとしてキーが含まれます。ランタイムはキーを検証し、要求を承認または拒否します。

アクセスキーは、アプリレベルのシークレットと同じではありません。アクセスキーは 関数を呼び出すことができるユーザーを保護しますが、アプリレベルのシークレットは 関数の接続先を保護します。

アクセスキーを使用するタイミング

Scenario	アクセスキーが適合する理由
サードパーティのウェブフック	GitHub、Stripe、Twilio などのプロバイダーは、URL とシークレットを使用して関数を呼び出します。アクセスキーは、期待される`?code=`パターンに直接挿入されます。
サービス間呼び出し	バックエンドサービス A は HTTP 経由で関数 B を呼び出します。内部専用の呼び出しにおいては、Microsoft Entraアプリの登録を設定するよりも、共有キーの方が簡単です。
Event Grid サブスクリプション	Event Grid は、プラットフォームが自動的に管理するシステムキーを使用して、関数エンドポイントを検証して呼び出します。
開発/テスト認証	開発中は、完全な OAuth/OIDC を構成せずに基本認証を行う必要があります。アクセスキーは、ID 構成なしで低摩擦の認証ゲートを提供します。
移行の互換性	既存のAzure Functions アプリでは既にアクセスキーが使用されています。 Container Apps に移行する場合は、呼び出し元の中断を回避するために、同じキーベースの認証が必要です。

Note

ユーザー向け API、ゼロトラストワークロード、またはユーザーごとの承認シナリオでは、アクセスキーの代わりに Microsoft Entra ID/ OAuth 2.0 を使用します。アクセスキーは、ID レベルの監査証跡のない共有シークレットです。

[前提条件]

アクティブなサブスクリプションを持つ Azure アカウント。無料でアカウントを作成できます。
Azure CLI バージョン 2.40.0 以降。
Container Apps 内の既存の Azure Functions アプリ、またはこうしたアプリを作成するためのアクセス許可。

アクセスキーの種類

Functions ランタイムは、次の 4 種類のキーを管理します。

キーの種類	Scope	Purpose
マスターキー (`_master`)	関数アプリ全体	すべての機能と `/admin/*` 管理エンドポイントへの管理者レベルのアクセス。取り消すことはできません。回転するのみです。
ホストキー (`default` + カスタム)	関数アプリ全体	アプリで HTTP によってトリガーされる関数の呼び出しを承認します。
ファンクションキー (`default` + カスタム)	単一関数	1 つの特定の関数の呼び出しを承認します。ホストキーよりも詳細な制御を提供します。
システムキー	拡張機能エンドポイント	Event Grid webhook サブスクリプションやDurable Functionsなどのプラットフォーム拡張機能によって使用されます。自動的に管理されます。

ストレージバックエンドを選択する

AzureWebJobsSecretStorageType環境変数を設定して、ランタイムがアクセスキーを保持する場所を制御します。 Azure Container Appsでは、3 つの運用グレードのバックエンドがサポートされます。

バックエンド	値を設定する	キーの自動生成	外部依存関係	最適な用途
Container Apps シークレットストア	`containerapps`	いいえ - キーを Container Apps シークレットとしてプロビジョニングします	None	ほとんどのワークロード (推奨)
Azure Key Vault	`keyvault`	いいえ - トリガーの作成を手動で行う	Key Vault インスタンス	一元化されたガバナンス、コンプライアンス監査
Azure Blob Storage	`blob`	はい	ストレージアカウント	レガシアプリまたは既存の `AzureWebJobsStorage` アカウント

以下のバックエンドの考慮事項を念頭に置いてください:

ランタイムはコンテナアプリの秘密ストレージを自動的に選択しません。 AzureWebJobsSecretStorageTypeを設定しなかったり、認識されない値に設定した場合、FunctionsホストはAzureWebJobsStorage利用可能なときに使うBlob Storageを使用します。
ストレージの健康チェックやストレージ依存機能の設定 AzureWebJobsStorage 保持してください。
AzureWebJobsSecretStorageTypeを files に設定しないでください。コンテナアプリのファイルシステムは一時的であるため、このバックエンドに保存された鍵は、アプリがゼロにスケールしたり再起動したり、新しいリビジョンを展開したりすると失われます。

シークレット名のパターン

格納されているキーの名前付け規則は、ストレージバックエンドによって異なります。

Container Apps シークレットストアでは、別の規則が使用されます。 Functions ホストは、 /run/secrets/functions-keys/でボリュームマウントされたファイルからキーを読み取ります。各ファイルは点線の名前 ( host.master など) を使用しますが、Container Apps のシークレット名では 小文字の英数字とダッシュのみを使用できます。シークレットボリュームをマウントする場合は、Functions ホストで想定される点線のファイル名 (たとえば、path → secretRef: host-master) にpath: host.master フィールドを明示的に設定する必要があります。プラットフォームでは、名前の自動変換は実行されません。

キーの種類	Container Apps のシークレット名 (ダッシュ)	ボリュームマウント `path` (ドット)
マスターキー	`host-master`	`host.master`
既定のホストキー	`host-function-default`	`host.function.default`
カスタムホストキー	`host-function-<name>`	`host.function.<name>`
特定の関数の既定の関数キー	`functions-<functionname>-default`	`functions.<functionName>.default`
特定の関数のカスタム関数キー	`functions-<functionname>-<keyname>`	`functions.<functionName>.<keyName>`
システムキー	`host-systemkey-<extension>`	`host.systemKey.<extension>`

Key Vault バックエンドは、二重ダッシュ (--) 規則を使用して、各キーを個々のKey Vault シークレットとして格納します。

キーの種類	シークレット名パターン	例
マスターキー	`host--masterKey--master`	`host--masterKey--master`
関数キー (既定値)	`host--functionKey--default`	`host--functionKey--default`
関数キー (カスタム)	`host--functionKey--<name>`	`host--functionKey--MyApiClient`
システムキー	`host--systemKey--<extension>`	`host--systemKey--eventgrid_extension`
関数ごとのキー	`function--<functionName>--<keyName>`	`function--myhttpfunc--default`

Blob Storage バックエンドは、キーを JSON ファイルとして azure-webjobs-secrets BLOB コンテナーに格納します。すべてのホストレベルのキー (マスター、ファンクションキー、およびシステムキー) は、1 つの host.json BLOB にまとめて格納されます。関数ごとのキーは、関数ごとに名前が付けられた個別の BLOB に格納されます。

ブロブパス	内容
`<SITE_SLOT_NAME>/host.json`	JSONファイルには`masterKey`、`functionKeys`、および`systemKeys`が含まれています。
`<SITE_SLOT_NAME>/<FUNCTION_NAME>.json`	特定の関数のキーを含む JSON ファイル

Tip

トラブルシューティングを行うときは、バックエンドストアでこれらのパターンを検索して、キーが正しく構成されていることを確認します。

Container Apps シークレットストアを構成する

Container Apps シークレットストアが推奨されるバックエンドです。キーは Container Apps プラットフォーム内に留まり、外部ストレージやKey Vaultは必要ありません。 Azure Resource Managerアクティビティログは、シークレットと環境変数への変更を追跡します。

このバックエンドでは、Functions ホストは、 /run/secrets/functions-keys/でボリュームマウントされたファイルからキーを読み取ります。ホスト はキーを自動生成しません。各キーは Container Apps シークレットとして作成する必要があります。プラットフォームでは、ホストが読み取るファイルとしてマウントします。

Important

Container Apps シークレットストアは、 ホストの観点から読み取り専用です。ホストはマウントされたキーファイルを読み取りますが、書き込むことはありません。必要なキーがない場合、ホストによって自動的に生成されることはありません。

Azure ポータルで Functions コンテナーアプリに移動します。
[設定] で、[環境変数] を選択します。
[ 追加] を選択し、次の値を入力します。

財産価値

氏名 AzureWebJobsSecretStorageType

価値 containerapps
[ 保存] を選択し、[ 適用 ] を選択して変更を確定します。

財産	価値
氏名	`AzureWebJobsSecretStorageType`
価値	`containerapps`

az containerapp update \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --set-env-vars "AzureWebJobsSecretStorageType=containerapps"

手順 2: アクセスキーシークレットを生成して格納する

キー値を生成し、Container Apps シークレットとして格納します。少なくとも、 マスターキー と 既定のホストキーが必要です。

ポータル
Azure CLI

Functions コンテナーアプリの [設定] で、[シークレット] を選択 します。

[ 追加] を選択し、次の値を入力します。

財産	価値
氏名	`host-master`
Type	コンテナアプリのシークレット
価値	ランダムに生成されたキー値。

[] を選択し、[] を追加します。
ランダムに生成された別の値で host-function-default を繰り返します。
関数ごとのキーを追加するには、 functions-<functionname>-default (すべて小文字) という名前のシークレットを追加します。

# Generate random key values
MASTER_KEY=$(openssl rand -hex 32)
HOST_DEFAULT_KEY=$(openssl rand -hex 32)

# Store as Container Apps secrets
az containerapp secret set \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --secrets "host-master=$MASTER_KEY" "host-function-default=$HOST_DEFAULT_KEY"

関数ごとのキーを追加するには (たとえば、 MyHttpFuncという名前の関数の場合)。

FUNC_KEY=$(openssl rand -hex 32)

az containerapp secret set \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --secrets "functions-myhttpfunc-default=$FUNC_KEY"

Note

Container Apps シークレット名では、小文字の英数字とダッシュのみを使用できます。ボリューム構成の path フィールドを、Functions ホストが想定する点線のファイル名 (たとえば、 secretRef: host-master → path: host.master) に明示的に設定する必要があります。明示的な pathがないと、ディスク上のファイルは破線の名前を保持し、Functions ホストはキーを見つけることができません。

手順 3: ボリュームマウントを構成する

シークレットをファイルとして /run/secrets/functions-keys/マウントします。

ポータル
Azure CLI

Functions コンテナーアプリの [ アプリケーション] で、[ リビジョンとレプリカ] を選択します。
[ 新しいリビジョンの作成] を選択します。
[ スケールとボリューム ] タブの [ ボリューム] で、[ 追加] を選択します。
次の値を入力します。

財産価値

ボリュームの種類 シークレット

氏名 functions-keys
シークレットごとに、[ パス ] フィールドを Functions ホストが想定する点線のファイル名に設定します (たとえば、 host-master をパス host.masterに設定し、 host-function-default をパス host.function.defaultに設定します)。
[] を選択し、[] を追加します。
[ コンテナー ] タブで、コンテナーを選択し、[ 編集] を選択します。
[ ボリュームマウント ] タブを選択し、[ 追加] を選択します。
次の値を入力します。

財産価値

ボリューム名 functions-keys

マウントパス /run/secrets/functions-keys
[保存] を選択し、[作成] を選択して新しいリビジョンをデプロイします。

財産	価値
ボリュームの種類	シークレット
氏名	`functions-keys`

財産	価値
ボリューム名	`functions-keys`
マウントパス	`/run/secrets/functions-keys`

アプリの YAML をエクスポートし、ボリュームとボリュームマウントを追加してから、適用します。

# Export current config
az containerapp show \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --output yaml > app.yaml

app.yaml を編集して、適切なセクションの下にボリュームとボリュームのマウントを追加します。

properties:
  template:
    volumes:
      - name: functions-keys
        storageType: Secret
        secrets:
          - secretRef: host-master
            path: host.master
          - secretRef: host-function-default
            path: host.function.default
    containers:
      - name: <CONTAINER_NAME>
        volumeMounts:
          - volumeName: functions-keys
            mountPath: /run/secrets/functions-keys

更新された構成を適用します。

az containerapp update \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --yaml app.yaml

手順 4: 確認する

アプリが再起動したら、キーが動作していることを確認します。

az containerapp function keys list \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --key-type hostKey

また、メッセージ Resolved secret storage provider ContainerAppsSecretsRepositoryのアプリログを確認することもできます。これは、ホストが Container Apps シークレットストアを使用されていることを確認します。

鍵を回転させる

キーをローテーションするには、Container Apps シークレットを更新し、アプリを再起動します。

NEW_KEY=$(openssl rand -hex 32)

az containerapp secret set \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --secrets "host-function-default=$NEW_KEY"

az containerapp revision restart \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --revision "<REVISION_NAME>"

Note

すべてのレプリカは、同じマウントされたシークレットを共有します。再起動後、すべてのレプリカが更新されたキー値を選択します。

Key VaultまたはBlob Storageをストアとして設定してください

Key Vaultの設定
Blob Storageの設定

Key Vault バックエンドは、アクセスキーをKey Vaultシークレットとして格納し、エンタープライズレベルの監査とアクセス制御を提供します。

Key Vaultを作成します (ない場合)。

az keyvault create \
  --name "<KEYVAULT_NAME>" \
  --resource-group "<RESOURCE_GROUP>" \
  --location "<LOCATION>"

コンテナーアプリでマネージド ID を有効にします (まだ有効になっていない場合)。

az containerapp identity assign \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --system-assigned

マネージド ID に Key Vault Secrets Officer ロールを付与します。ランタイムには、キーを作成および管理するための読み取りと書き込みアクセスが必要です。

PRINCIPAL_ID=$(az containerapp show \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --query identity.principalId \
  --output tsv)

KEYVAULT_ID=$(az keyvault show \
  --name "<KEYVAULT_NAME>" \
  --query id \
  --output tsv)

az role assignment create \
  --role "Key Vault Secrets Officer" \
  --assignee "$PRINCIPAL_ID" \
  --scope "$KEYVAULT_ID"

ストレージの種類とKey Vault URI を設定します。

システム割り当て ID の場合:

az containerapp update \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --set-env-vars \
    "AzureWebJobsSecretStorageType=keyvault" \
    "AzureWebJobsSecretStorageKeyVaultUri=https://<KEYVAULT_NAME>.vault.azure.net"

ユーザー割り当て ID の場合は、クライアント ID も設定します。

az containerapp update \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --set-env-vars \
    "AzureWebJobsSecretStorageType=keyvault" \
    "AzureWebJobsSecretStorageKeyVaultUri=https://<KEYVAULT_NAME>.vault.azure.net" \
    "AzureWebJobsSecretStorageKeyVaultClientId=<USER_ASSIGNED_IDENTITY_CLIENT_ID>"

キーを一覧表示してキーの作成をトリガーします。

az containerapp function keys list \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --key-type hostKey

Blob Storage バックエンドを使用すると、ランタイムはアクセスキーを自動生成および管理できます。このオプションは、 AzureWebJobsStorage 用のストレージアカウントが既にあり、一元的なガバナンスが不要な場合に使用します。

コンテナーアプリでマネージド ID を有効にします (まだ有効になっていない場合)。

az containerapp identity assign \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --system-assigned

ストレージアカウントの ストレージ BLOB データ共同作成者 ロールにマネージド ID を付与します。

PRINCIPAL_ID=$(az containerapp show \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --query identity.principalId \
  --output tsv)

STORAGE_ID=$(az storage account show \
  --name "<STORAGE_ACCOUNT_NAME>" \
  --resource-group "<RESOURCE_GROUP>" \
  --query id \
  --output tsv)

az role assignment create \
  --role "Storage Blob Data Contributor" \
  --assignee "$PRINCIPAL_ID" \
  --scope "$STORAGE_ID"

ストレージの種類を設定します。

az containerapp update \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --set-env-vars "AzureWebJobsSecretStorageType=blob"

ランタイムは、次のコールドスタート時にキーを自動生成します。確認：

az containerapp function keys list \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --key-type hostKey

アクセスキーを管理する

バックエンドに関係なく、次のコマンドを使用して、アクセスキーの一覧表示、作成、削除を行います。

Note

これらの鍵管理操作を実行するために、少なくとも1つのレプリカを稼働させておくこと。

すべてのホストキーをリストアップ:

az containerapp function keys list \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --key-type hostKey

マスターキーをリストアップ:

az containerapp function keys list \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --key-type masterKey

カスタムホストキーの作成または上書き:

az containerapp function keys set \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --key-name "MyCustomKey" \
  --key-value "<YOUR_KEY_VALUE>" \
  --key-type hostKey

特定のキーを表示:

az containerapp function keys show \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --key-name "<KEY_NAME>" \
  --key-type hostKey

ホストキーを削除する:

az containerapp function keys delete \
  --resource-group "<RESOURCE_GROUP>" \
  --name "<FUNCTIONS_APP_NAME>" \
  --key-name "MyCustomKey" \
  --key-type hostKey

アクセスキーを使用して関数を呼び出す

クエリパラメーターまたは要求ヘッダーとしてキーを渡します。

# Query parameter
curl "https://<FUNCTIONS_APP_URL>/api/<FUNCTION_NAME>?code=<HOST_KEY>"

# Header
curl "https://<FUNCTIONS_APP_URL>/api/<FUNCTION_NAME>" \
  -H "x-functions-key: <HOST_KEY>"

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-06-11

Azure Container Appsで Functions ホスト キー ストレージを構成する

アクセスキーを使用するタイミング

[前提条件]

アクセス キーの種類

ストレージ バックエンドを選択する

シークレット名のパターン

Container Apps シークレット ストアを構成する

手順 1: ストレージの種類を設定する

手順 2: アクセス キー シークレットを生成して格納する

手順 3: ボリューム マウントを構成する

手順 4: 確認する

鍵を回転させる

Key VaultまたはBlob Storageをストアとして設定してください

アクセス キーを管理する

アクセス キーを使用して関数を呼び出す

関連するコンテンツ

フィードバック

その他のリソース

Azure Container Appsで Functions ホストキーストレージを構成する

アクセスキーの種類

ストレージバックエンドを選択する

Container Apps シークレットストアを構成する

手順 2: アクセスキーシークレットを生成して格納する

手順 3: ボリュームマウントを構成する

アクセスキーを管理する

アクセスキーを使用して関数を呼び出す