App Service と Azure Functions でマネージド ID を使用する方法

[アーティクル]
09/30/2024

Note

2024 年 6 月 1 日より、新しく作成されたすべての App Service アプリには、名前付け規則 <app-name>-<random-hash>.<region>.azurewebsites.net を使用して一意の既定のホスト名を生成するオプションが備わります。既存のアプリ名は変更されません。

例: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

詳細については、App Service リソースの一意の既定のホスト名に関するページを参照してください。

このトピックでは、App Service と Azure Functions アプリケーションでマネージド ID を作成し、それを使用して他のリソースにアクセスする方法を説明します。

重要

マネージド ID はディレクトリ間のシナリオをサポートしていないため、アプリがサブスクリプション間またはテナント間で移行された場合、想定どおりには動作しません。そのような移行後にマネージド ID をもう一度作成するには、「サブスクリプションを別のディレクトリに移動する場合、マネージド ID は自動的に再作成されますか?」をご覧ください。また、ダウンストリームリソースでも新しい ID が使用されるように、アクセスポリシーを更新する必要があります。

Note

マネージド ID は、Azure Arc にデプロイされているアプリでは使用できません。

アプリで Microsoft Entra ID のマネージド ID を使用すると、他の Microsoft Entra で保護されたリソース (Azure Key Vault など) に簡単にアクセスできます。 ID は Azure プラットフォームによって管理され、ユーザーがシークレットをプロビジョニングまたはローテーションする必要はありません。 Microsoft Entra ID のマネージド ID の詳細については、「Azure リソースのマネージド ID」を参照してください。

アプリケーションには 2 種類の ID を付与できます。

システム割り当て ID はアプリに関連付けられ、そのアプリが削除されると削除されます。アプリは 1 つのシステム割り当て ID しか持つことはできません。
ユーザー割り当て ID は、アプリに割り当てることができるスタンドアロン Azure リソースです。アプリは複数のユーザー割り当て ID を持つことができ、1 つのユーザー割り当て ID を複数の Azure リソース (2 つの App Service アプリなど) に割り当てることができます。

マネージド ID の構成はスロットに固有です。ポータルでデプロイスロットのマネージド ID を構成するには、まずスロットに移動します。 Azure portal で Microsoft Entra テナント内の Web アプリまたはデプロイスロットのマネージド ID を検索するには、テナントの [概要] ページで直接検索します。通常、スロット名は <app-name>/slots/<slot-name> に似ています。

このビデオは、App Service に対しマネージド ID を使用する方法を示しています。

ビデオの手順については、次のセクションでも説明します。

システム割り当て ID を追加する

左側のナビゲーションウィンドウの [設定] グループで、Azure portal でアプリの設定にアクセスします。
[ID] を選択します。
[システム割り当て済み] タブで、 [状態] を [オン] に切り替えます。 [保存] をクリックします。

az webapp identity assignコマンドを実行して、システム割り当て ID を作成します。

az webapp identity assign --name myApp --resource-group myResourceGroup

App Service の場合

Set-AzWebApp -AssignIdentityコマンドを実行して、App Service のシステム割り当て ID を作成します。

Set-AzWebApp -AssignIdentity $true -Name <app-name> -ResourceGroupName <group-name>

関数の場合

Update-AzFunctionApp -IdentityTypeコマンドを実行して、関数アプリのシステム割り当て ID を作成します。

Update-AzFunctionApp -Name $functionAppName -ResourceGroupName $resourceGroupName -IdentityType SystemAssigned

Azure Resource Manager テンプレートを使って、Azure リソースのデプロイを自動化できます。 App Service および Functions へのデプロイについて詳しくは、「Automating resource deployment in App Service」(App Service でのリソースのデプロイの自動化) および「Azure Functions の関数アプリのリソースデプロイを自動化」をご覧ください。

種類が Microsoft.Web/sites であるすべてのリソースは、リソース定義に次のプロパティを含めることにより、ID を使って作成できます。

"identity": {
    "type": "SystemAssigned"
}

システム割り当てタイプを追加すると、Azure に対してアプリケーション用の ID を作成して管理するように指示されます。

たとえば、Web アプリのテンプレートは次の JSON のようになります。

{
    "apiVersion": "2022-03-01",
    "type": "Microsoft.Web/sites",
    "name": "[variables('appName')]",
    "location": "[resourceGroup().location]",
    "identity": {
        "type": "SystemAssigned"
    },
    "properties": {
        "name": "[variables('appName')]",
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
        "hostingEnvironment": "",
        "clientAffinityEnabled": false,
        "alwaysOn": true
    },
    "dependsOn": [
        "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]"
    ]
}

作成されるサイトには、次の追加プロパティが設定されます。

"identity": {
    "type": "SystemAssigned",
    "tenantId": "<tenant-id>",
    "principalId": "<principal-id>"
}

tenantId プロパティは、その ID が属する Microsoft Entra テナントを示します。 principalId は、アプリケーションの新しい ID の一意識別子です。 Microsoft Entra ID のサービスプリンシパル名は、お使いの App Service または Azure Functions のインスタンスに指定したものと同じです。

テンプレートの後の段階でこれらのプロパティを参照する必要がある場合は、次の例のように、'Full' フラグを指定した reference() テンプレート関数を使用して行うことができます。

{
    "tenantId": "[reference(resourceId('Microsoft.Web/sites', variables('appName')), '2018-02-01', 'Full').identity.tenantId]",
    "objectId": "[reference(resourceId('Microsoft.Web/sites', variables('appName')), '2018-02-01', 'Full').identity.principalId]",
}

ユーザー割り当て ID を追加する

ユーザー割り当て ID を持つアプリを作成するには、ID を作成してから、そのリソース ID をアプリ構成に追加する必要があります。

最初に、ユーザー割り当て ID リソースを作成する必要があります。

以下の手順に従って、ユーザー割り当てマネージド ID リソースを作成します。
アプリのページの左側のナビゲーションで、[設定] グループまで下にスクロールします。
[ID] を選択します。
[ユーザー割り当て済み]>[追加] を選びます。
先ほど作成した ID を検索して選び、[追加] を選びます。

[追加] を選ぶと、アプリが再起動します。

ユーザー割り当て ID を作成します。

az identity create --resource-group <group-name> --name <identity-name>

az webapp identity assignコマンドを実行して、ID をアプリに割り当てます。

az webapp identity assign --resource-group <group-name> --name <app-name> --identities <identity-id>

App Service の場合

App Service でユーザー割り当て ID を追加することは、現在サポートされていません。

関数の場合

ユーザー割り当て ID を作成します。

Install-Module -Name Az.ManagedServiceIdentity -AllowPrerelease
$userAssignedIdentity = New-AzUserAssignedIdentity -Name $userAssignedIdentityName -ResourceGroupName <group-name>

Update-AzFunctionApp -IdentityType UserAssigned -IdentityIdコマンドを実行して、Functions で ID を割り当てます。

Update-AzFunctionApp -Name <app-name> -ResourceGroupName <group-name> -IdentityType UserAssigned -IdentityId $userAssignedIdentity.Id

種類が Microsoft.Web/sites であるリソースは、リソース定義に次のブロックを含めて、<resource-id> を目的の ID のリソース ID と置き換えることで、ID を使って作成できます。

"identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
        "<resource-id>": {}
    }
}

Note

アプリケーションは、システム割り当て ID とユーザー割り当て ID の両方を同時に持つことができます。この場合、type プロパティは SystemAssigned,UserAssigned になります

ユーザー割り当ての型を追加すると、アプリケーションに対して指定されたユーザー割り当て ID を使用するように Azure に指示します。

たとえば、Web アプリのテンプレートは次の JSON のようになります。

{
    "apiVersion": "2022-03-01",
    "type": "Microsoft.Web/sites",
    "name": "[variables('appName')]",
    "location": "[resourceGroup().location]",
    "identity": {
        "type": "UserAssigned",
        "userAssignedIdentities": {
            "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', variables('identityName'))]": {}
        }
    },
    "properties": {
        "name": "[variables('appName')]",
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
        "hostingEnvironment": "",
        "clientAffinityEnabled": false,
        "alwaysOn": true
    },
    "dependsOn": [
        "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
        "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', variables('identityName'))]"
    ]
}

作成されるサイトには、次の追加プロパティが設定されます。

"identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
        "<resource-id>": {
            "principalId": "<principal-id>",
            "clientId": "<client-id>"
        }
    }
}

principalId は、Microsoft Entra の管理に使用される ID の一意識別子です。 clientId は、ランタイム呼び出し中に使用する ID を指定するために使用されるアプリケーションの新しい ID の一意識別子です。

ターゲットリソースを構成する

アプリまたは関数からのアクセスを許可するようにターゲットリソースを構成する必要がある場合があります。例えば、Key Vault にアクセスするためにトークンを要求する場合、アプリや関数のマネージド ID を含むアクセスポリシーも追加する必要があります。それ以外の場合は、有効なトークンを使用する場合でも、Key Vault への呼び出しは拒否されます。同じことが Azure SQL Database にも当てはまります。 Microsoft Entra トークンをサポートしているリソースの詳細については、「Microsoft Entra 認証をサポートしている Azure サービス」をご覧ください。

重要

マネージド ID のバックエンドサービスは、リソース URI ごとのキャッシュを約 24 時間保持します。これは、マネージド ID のグループまたはロールメンバーシップの変更が有効になるまでに数時間かかる可能性があることを意味します。現時点では、マネージド ID のトークンの有効期限が切れる前にトークンを強制的に更新することはできません。そのため、マネージド ID のグループまたはロールのメンバーシップを変更してアクセス許可を追加または削除する場合には、ID を使用する Azure リソースに適切なアクセス権が付与されるまでに、数時間の待ち時間が発生することがあります。グループまたはロールメンバーシップの代替については、「認可にマネージド ID を使用する場合の制限」を参照してください。

アプリコードでの Azure サービスへの接続

アプリはマネージド ID を使用して、Azure SQL Database、Azure キーコンテナー、Azure ストレージなど、Microsoft Entra ID によって保護されている Azure リソースのトークンを取得できます。これらのトークンは、アプリケーションの特定のユーザーではなく、リソースにアクセスしているアプリケーションを表します。

App Service と Azure Functions は、トークン取得のために、内部でアクセス可能なRES Tエンドポイントを提供します。 REST エンドポイントは、標準の HTTP GET を使用してアプリ内からアクセスでき、すべての言語で汎用 HTTP クライアントを実装できます。 NET、JavaScript、Java、Python の場合、Azure ID クライアントライブラリは、この REST エンドポイントを抽象化し、開発環境を簡素化します。他の Azure サービスへの接続は、サービス固有のクライアントに資格情報オブジェクトを追加するのと同じくらい簡単です。

生の HTTP GET 要求では、指定された 2 つの環境変数が使用され、次の例のようになります。

GET /MSI/token?resource=https://vault.azure.net&api-version=2019-08-01 HTTP/1.1
Host: <ip-address-:-port-in-IDENTITY_ENDPOINT>
X-IDENTITY-HEADER: <value-of-IDENTITY_HEADER>

応答の例は次のようになります。

HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token": "eyJ0eXAi…",
    "expires_on": "1586984735",
    "resource": "https://vault.azure.net",
    "token_type": "Bearer",
    "client_id": "00001111-aaaa-2222-bbbb-3333cccc4444"
}

この応答は、Microsoft Entra のサービス間アクセストークン要求に対する応答と同じです。 Key Vault にアクセスするには、access_tokenの値をコンテナーとのクライアント接続に追加します。

注意

Entity Framework Core で Azure SQ Lデータソースに接続する場合、マネージド ID 接続のための特別な接続文字列を提供する Microsoft.Data.SqlClient の使用をご検討下さい。例については、「チュートリアル: マネージド ID を使用したApp Service からの Azure SQL Database接続をセキュリティ保護」を参照してください。

.NET のアプリと関数の場合、マネージド ID を利用する最も簡単な方法は、.NET 用の Azure ID クライアントライブラリを使用することです。詳細なガイダンスについては、「チュートリアル: マネージド ID を使用してシークレットなしで App Service から Azure データベースに接続する」を参照してください。

詳細については、クライアントライブラリの各ドキュメントの見出しを参照してください。

リンクされた例では、DefaultAzureCredentialを使用します。これは、Azure (マネージド ID を使用) とローカルコンピューター (マネージド ID を除く) で同じパターンが動作するため、ほとんどのシナリオで役立ちます。

Node.js アプリや JavaScript 関数の場合、マネージド ID を扱う最も簡単な方法は、.NET 用の Azure ID クライアントライブラリを使用することです。詳細なガイダンスについては、「チュートリアル: マネージド ID を使用してシークレットなしで App Service から Azure データベースに接続する」を参照してください。

詳細については、クライアントライブラリの各ドキュメントの見出しを参照してください。

JavaScript 用 Azure ID クライアントライブラリのコード例詳細については、「Azure ID の例」を参照してください。

Python アプリと関数の場合、マネージド ID を利用する最も簡単な方法は、Python 用の Azure ID クライアントライブラリを使用することです。詳細なガイダンスについては、「チュートリアル: マネージド ID を使用してシークレットなしで App Service から Azure データベースに接続する」を参照してください。

詳細については、クライアントライブラリの各ドキュメントの見出しを参照してください。

Java のアプリと関数の場合、マネージド ID を利用する最も簡単な方法は、Java 用の Azure ID クライアントライブラリを使用することです。詳細なガイダンスについては、「チュートリアル: マネージド ID を使用してシークレットなしで App Service から Azure データベースに接続する」を参照してください。

詳細については、クライアントライブラリの各ドキュメントの見出しを参照してください。

Java 用 Azure ID クライアントライブラリのコード例詳細については、「Azure ID の例」を参照してください。

次のスクリプトを使用して、Azure サービスのリソース URI を指定してローカルエンドポイントからトークンを取得します。

$resourceURI = "https://<AAD-resource-URI-for-resource-to-obtain-token>"
$tokenAuthURI = $env:IDENTITY_ENDPOINT + "?resource=$resourceURI&api-version=2019-08-01"
$tokenResponse = Invoke-RestMethod -Method Get -Headers @{"X-IDENTITY-HEADER"="$env:IDENTITY_HEADER"} -Uri $tokenAuthURI
$accessToken = $tokenResponse.access_token

REST エンドポイントの詳細については、「REST エンドポイントリファレンス」を参照してください。

ID を削除する

システム割り当て ID を削除すると、Microsoft Entra ID から削除されます。また、アプリリソース自体を削除すると、システム割り当て ID も Microsoft Entra ID から自動的に削除されます。

アプリのページの左側のナビゲーションで、[設定] グループまで下にスクロールします。
[ID] を選択します。次に、ID の種類に基づいて、次の手順に従います。
- システムに割り当てられた ID: [システム割り当て済み] タブで [状態] を [オフ] に切り替えます。 [保存] をクリックします。
- ユーザーに割り当てられたID: [ユーザ割り当て済み] タブを選択し、ID のチェックボックスを選択し、[削除] を選択します。 [はい] を選択して確定します。

システム割り当て ID を削除するには、次の手順を実行します。

az webapp identity remove --name <app-name> --resource-group <group-name>

1 つ以上のユーザー割り当て ID を削除するには、次の手順を実行します。

az webapp identity remove --name <app-name> --resource-group <group-name> --identities <identity-id1> <identity-id2> ...

また、--identitiesで[system]を指定して、システム割り当て ID を削除することもできます。

App Service の場合

App Service のシステム割り当て ID を削除するには、Set-AzWebApp -AssignIdentityコマンドを実行します。

Set-AzWebApp -AssignIdentity $false -Name <app-name> -ResourceGroupName <group-name>

関数の場合

Azure PowerShell のすべての ID を削除するには (Azure Functions のみ) 次のようにします。

# Update an existing function app to have IdentityType "None".
Update-AzFunctionApp -Name $functionAppName -ResourceGroupName $resourceGroupName -IdentityType None

ARM テンプレートのすべての ID を削除するには、次のようにします。

"identity": {
    "type": "None"
}

Note

また、単純にローカルトークンサービスを無効にする、設定可能なアプリケーション設定 WEBSITE_DISABLE_MSI もあります。ただし、ID はその場所に残り、ツールには引き続きマネージド ID が "オン" または "有効" と表示されます。そのため、この設定の使用はお勧めしません。

REST エンドポイントの参照

マネージド ID を持つアプリは、次の 2 つの環境変数を定義することによってこのエンドポイントを使用できます。

IDENTITY_ENDPOINT - ローカルトークンサービスに対する URL。
IDENTITY_HEADER - サーバー側のリクエストフォージェリ (SSRF) 攻撃を回避するために使用するヘッダー。値は、プラットフォームによってローテーションされます。

IDENTITY_ENDPOINT は、お使いのアプリがトークンを要求するローカル URL です。リソースのトークンを取得するには、次のパラメーターを指定して、このエンドポイントに HTTP GET 要求を行います。

パラメーター名場所説明

resource クエリトークンを取得する必要のあるリソースの Microsoft Entra リソース URI。これは Microsoft Entra 認証をサポートしている Azure サービスの 1 つか、その他のリソース URI になります。

api-version クエリ使うトークン API のバージョン。 2019-08-01 を使用してください。

X-IDENTITY-HEADER ヘッダー IDENTITY_HEADER 環境変数の値。このヘッダーは、サーバー側のリクエストフォージェリ (SSRF) 攻撃を回避するために使用されます。

client_id クエリ (省略可能) 使用するユーザー割り当て ID のクライアント ID。 principal_id、mi_res_id、または object_id を含む要求では使用できません。すべての ID パラメーター (client_id、principal_id、object_id、および mi_res_id) を省略した場合、システム割り当て ID が使用されます。

principal_id クエリ (省略可能) 使用するユーザー割り当て ID のプリンシパル ID。 object_id は代わりに使用する別名です。 client_id、mi_res_id、または object_id を含む要求では使用できません。すべての ID パラメーター (client_id、principal_id、object_id、および mi_res_id) を省略した場合、システム割り当て ID が使用されます。

mi_res_id クエリ (省略可能) 使用するユーザー割り当て ID の Azure リソース ID。 principal_id、client_id、または object_id を含む要求では使用できません。すべての ID パラメーター (client_id、principal_id、object_id、および mi_res_id) を省略した場合、システム割り当て ID が使用されます。

パラメーター名	場所	説明
resource	クエリ	トークンを取得する必要のあるリソースの Microsoft Entra リソース URI。これは Microsoft Entra 認証をサポートしている Azure サービスの 1 つか、その他のリソース URI になります。
api-version	クエリ	使うトークン API のバージョン。 `2019-08-01` を使用してください。
X-IDENTITY-HEADER	ヘッダー	IDENTITY_HEADER 環境変数の値。このヘッダーは、サーバー側のリクエストフォージェリ (SSRF) 攻撃を回避するために使用されます。
client_id	クエリ	(省略可能) 使用するユーザー割り当て ID のクライアント ID。 `principal_id`、`mi_res_id`、または `object_id` を含む要求では使用できません。すべての ID パラメーター (`client_id`、`principal_id`、`object_id`、および `mi_res_id`) を省略した場合、システム割り当て ID が使用されます。
principal_id	クエリ	(省略可能) 使用するユーザー割り当て ID のプリンシパル ID。 `object_id` は代わりに使用する別名です。 client_id、mi_res_id、または object_id を含む要求では使用できません。すべての ID パラメーター (`client_id`、`principal_id`、`object_id`、および `mi_res_id`) を省略した場合、システム割り当て ID が使用されます。
mi_res_id	クエリ	(省略可能) 使用するユーザー割り当て ID の Azure リソース ID。 `principal_id`、`client_id`、または `object_id` を含む要求では使用できません。すべての ID パラメーター (`client_id`、`principal_id`、`object_id`、および `mi_res_id`) を省略した場合、システム割り当て ID が使用されます。

重要

ユーザー割り当て ID のトークンを取得する場合は、省略可能なプロパティの 1 つを含める必要があります。このようにしないと、トークンサービスは存在する場合と存在しない場合があるシステムが割り当てた ID のトークンを取得しようとします。

次の方法で共有

App Service と Azure Functions でマネージド ID を使用する方法

システム割り当て ID を追加する

App Service の場合

関数の場合

ユーザー割り当て ID を追加する

App Service の場合

関数の場合

ターゲットリソースを構成する

アプリコードでの Azure サービスへの接続

ID を削除する

App Service の場合

関数の場合

REST エンドポイントの参照

次のステップ

フィードバック

その他のリソース

次の方法で共有

App Service と Azure Functions でマネージド ID を使用する方法

システム割り当て ID を追加する

ユーザー割り当て ID を追加する

ターゲット リソースを構成する

アプリ コードでの Azure サービスへの接続

ID を削除する

REST エンドポイントの参照

次のステップ

フィードバック

その他のリソース

ターゲットリソースを構成する

アプリコードでの Azure サービスへの接続