Azure ロールベースのアクセス制御 (Azure RBAC) を使用して Azure AI Search に接続する

[アーティクル]
03/20/2024

Azure には、プラットフォームで実行されるすべてのサービスに対し、グローバルなロールベースのアクセス制御承認システムが用意されています。 Azure AI Search では、次の用途に Azure ロールを使用できます。

コントロールプレーン操作 (Azure Resource Manager によるサービス管理タスク)。
インデックスの作成、読込、クエリなどのデータプレーン操作。

検索結果に対するユーザーアクセスごとに (行レベルセキュリティまたはドキュメントレベルセキュリティと呼ばれることもあります) はサポートされていません。回避策としては、[セキュリティフィルターの作成] を使用してユーザー ID 別に結果を整理し、要求者がアクセスしてはならないドキュメントを削除します。

Note

Azure AI Search では、"コントロールプレーン" は、Management REST API または同等のクライアントライブラリでサポートされる操作を意味します。 "データプレーン" は、インデックス作成やクエリなどの検索サービスエンドポイントに対する操作、または Search REST API または同等のクライアントライブラリで指定されるその他の操作を意味します。

Search で使用される組み込みロール

次のロールが組み込まれています。これらのロールが不十分な場合は、カスタムロールを作成します。

役割	プレーン	説明
所有者	コントロールとデータ	Azure ロールを割り当てる機能を含む、検索リソースのコントロールプレーンへのフルアクセス。所有者ロールだけが、認証オプションを有効または無効にしたり、他のユーザーのロールを管理したりできます。サブスクリプション管理者は既定でメンバーになります。データプレーンでは、このロールには、Search サービス共同作成者ロールと同じアクセス権があります。これには、検索インデックスまたはインデックスドキュメントのクエリを実行する機能を除く、すべてのデータプレーンアクションへのアクセス権が含まれます。
Contributor	コントロールとデータ	ロールの割り当て、認証オプションの変更を除いて、所有者と同じコントロールプレーンアクセスレベル。データプレーンでは、このロールには、Search サービス共同作成者ロールと同じアクセス権があります。これには、検索インデックスまたはインデックスドキュメントのクエリを実行する機能を除く、すべてのデータプレーンアクションへのアクセス権が含まれます。
Reader	コントロールとデータ	検索メトリック、コンテンツメトリック (消費されたストレージ、オブジェクトの数)、データプレーンリソース (インデックス、インデクサーなど) のオブジェクト定義など、サービス全体にわたる読み取りアクセス。閲覧者ロールは、API キーの読み取りやインデックス内のコンテンツの読み取りには引き続きアクセスできません。
Search Service Contributor	コントロールとデータ	オブジェクト定義 (インデックス、同意語マップ、インデクサー、データソース、スキルセット) への読み取り/書き込みアクセス。アクセス許可の一覧については、「`Microsoft.Search/searchServices/*`」を参照してください。このロールはインデックス内のコンテンツにアクセスできないため、クエリやインデックス作成は行われませんが、インデックスを作成、削除、一覧表示し、インデックス定義と統計情報を返し、アナライザーをテストすることができます。このロールは、検索サービスとそのオブジェクトを管理する必要がある検索サービス管理者を対象としています。ただし、コンテンツにはアクセスしません。
検索インデックスデータ共同作成者	データ	検索サービスですべてのインデックス内のコンテンツに対する読み取り/書き込みアクセス。このロールは、インデックスのドキュメントコレクションのインポート、更新、またはクエリを行う必要がある開発者またはインデックス所有者向けです。
検索インデックスデータ閲覧者	データ	検索サービスですべての検索インデックスへの読み取り専用アクセス。このロールは、クエリを実行するアプリおよびユーザー向けです。

Note

Azure ロールベースのアクセスを無効にした場合、コントロールパネルの組み込みロール (所有者、共同作成者、閲覧者) を引き続き使用できます。 Azure RBAC を無効にすると、これらのロールに関連付けられたデータ関連の権限だけが削除されます。 RBAC 無効シナリオでは、Search Service Contributor はコントロールプレーンの共同作成者とです。

制限事項

ロールベースのアクセス制御を採用すると、一部の要求の待機時間が長くなる可能性があります。要求で使われるサービスリソース (インデックス、インデクサーなど) とサービスプリンシパルの一意の組み合わせごとに、認可チェックがトリガーされます。これらの認可チェックにより、最大 200 ミリ秒の待機時間が要求に追加されます。
まれに、多数の異なるサービスプリンシパルから要求が送信され、すべてが異なるサービスリソース (インデックス、インデクサーなど) を対象としている場合、認可チェックによって調整が発生する可能性があります。調整が発生するのは、検索サービスリソースとサービスプリンシパルの一意の組み合わせが 1 秒間に何百も使われた場合のみです。

データプレーンにロールベースのアクセスを構成する

適用対象: Search インデックスデータ共同作成者、Search インデックスデータ閲覧者、Search サービス共同作成者

この手順では、OAuth2 アクセストークンを提供するデータ要求の承認ヘッダーを認識するように検索サービスを構成します。

Azure Portal
REST API

Azure portal にサインインし、検索サービスページを開きます。
左側のナビゲーションペインで [キー] を選択します。

[API アクセス制御] オプションを選択します。柔軟性を求める場合、あるいはアプリを移行する必要がある場合、[両方] をお勧めします。

オプション	説明
API キー	(既定) 承認するには、要求ヘッダーに管理者またはクエリの API キーが必要です。ロールは使用されません。
ロールベースのアクセス制御	次のステップで説明するように、タスクを完了するには、ロール割り当てのメンバーシップが必要です。また、Authorization ヘッダーも必要です。
両方	API キーまたはロールベースのアクセス制御のいずれかを使用する要求が有効です。

変更はすぐに有効になりますが、テストする前に数秒待ってください。

検索サービス操作とコンテンツに対するすべてのネットワーク呼び出しでは、選択したオプション (API キー、ベアラートークン、または [両方] を選択した場合はいずれか) が優先されます。

ポータルでロールベースのアクセス制御を有効にすると、認証に失敗したとき、失敗モードが "http401WithBearerChallenge" になります。

Management REST API のサービスの作成または更新を使用して、ロールベースのアクセス制御についてサービスを構成します。

Management REST API の呼び出しはすべて、Microsoft Entra ID と、共同作成者アクセス許可または所有者アクセス許可で認証されます。認証された要求を設定する方法については、REST を使用した Azure AI Search の管理に関するページを参照してください。

現在の構成を確認できるように、サービス設定を取得します。

GET https://management.azure.com/subscriptions/{{subscriptionId}}/providers/Microsoft.Search/searchServices?api-version=2023-11-01

PATCH を使用し、サービス構成を更新します。次の変更により、キーアクセスとロールベースアクセスの両方が有効になります。ロールのみの構成が必要な場合、API キーの無効化に関するセクションを参照してください。

"properties" の "authOptions" を "aadOrApiKey" に設定します。 "authOptions" を設定するには、"disableLocalAuth" プロパティを false にする必要があります。

必要に応じて、"aadAuthFailureMode" を設定して、認証に失敗した場合、403 ではなく 401 を返すかどうかを指定します。有効な値は "http401WithBearerChallenge" または "http403" です。
```
PATCH https://management.azure.com/subscriptions/{{subscriptionId}}/resourcegroups/{{resource-group}}/providers/Microsoft.Search/searchServices/{{search-service-name}}?api-version=2023-11-01
{
    "properties": {
        "disableLocalAuth": false,
        "authOptions": {
            "aadOrApiKey": {
                "aadAuthFailureMode": "http401WithBearerChallenge"
            }
        }
    }
}
```
次のステップの指示に従って、データプレーン操作にロールを割り当てます。

ロールの割り当て

ロールの割り当ては、すべてのツールとクライアントライブラリ全体に累積され、広く適用されます。ロールは、Azure のロールベースのアクセス制御のドキュメントで説明されている、サポートされている方法のいずれかを使用して割り当てることができます。

ロールの割り当てを管理するには、所有者であるか、Microsoft.Authorization/roleAssignments/write アクセス許可を持っている必要があります。

Azure Portal
PowerShell

ポータルでのロールの割り当ては、サービス全体です。単一のインデックスにアクセス許可を付与する場合は、代わりに PowerShell または Azure CLI を使用します。

Azure portal にサインインします。
お使いの検索サービスに移動します。
左側のナビゲーションペインで [アクセス制御 (IAM)] を選択します。
[+ 追加]>[ロール割り当ての追加] の順に選択します。
該当するロールを選びます。
- [所有者]
- Contributor
- Reader
- Search Service Contributor
- 検索インデックスデータ共同作成者
- 検索インデックスデータ閲覧者
[メンバー] タブで Microsoft Entra ユーザーまたはグループの ID を選びます。
[確認と割り当て] タブで、 [確認と割り当て] を選択してロールを割り当てます。

PowerShell を使用してロールを割り当てる場合は、New-AzRoleAssignment を呼び出して、Azure のユーザーまたはグループの名前と、割り当てのスコープを指定します。

始める前に、Az と AzureAD のモジュールを読み込み、Azure に接続していることを確認してください。

Import-Module -Name Az
Import-Module -Name AzureAD
Connect-AzAccount

この例では、検索サービスにスコープを設定したロールの割り当てを作成します。

New-AzRoleAssignment -SignInName <email> `
    -RoleDefinitionName "Search Index Data Contributor" `
    -Scope  "/subscriptions/<subscription>/resourceGroups/<resource-group>/providers/Microsoft.Search/searchServices/<search-service>"

この例では、特定のインデックスにスコープを設定したロールの割り当てを作成します。

New-AzRoleAssignment -SignInName <email> `
    -RoleDefinitionName "Search Index Data Contributor" `
    -Scope  "/subscriptions/<subscription>/resourceGroups/<resource-group>/providers/Microsoft.Search/searchServices/<search-service>/indexes/<index-name>"

インデックス、同義語マップ、インデクサー、データソース、スキルセットなど、最上位レベルのリソースにのみ、アクセスのスコープを設定できることを思い出してください。 Azure ロールでドキュメント (インデックスコンテンツ) の検索へのアクセスを制御することはできません。

ロールの割り当てをテストする

クライアントを使用して、ロールの割り当てをテストします。ロールは累積的であり、サブスクリプションまたはリソースグループを対象範囲とする継承されたロールは、リソース (検索サービス) レベルでは削除または拒否できないことに注意してください。

アクセスをテストする前に、Microsoft Entra ID にクライアントアプリケーションを登録し、ロールの割り当てを終えていることを確認します。

Azure portal にサインインします。
お使いの検索サービスに移動します。
[概要] ページで、[インデックス] タブを選択します。
- 共同作成者は、任意のオブジェクトを表示および作成できますが、検索エクスプローラーを使用してインデックスに対してクエリを実行することはできません。
- Search インデックスデータ閲覧者は、Search エクスプローラーを使用してインデックスのクエリを実行できます。任意の API バージョンを使用して、アクセスを確認できます。クエリを送信し、結果を表示できるようにする必要がありますが、インデックス定義を表示できる必要はありません。
- 検索インデックスデータ共同作成者は、[新しいインデックス] を選択して、新しいインデックスを作成できます。新しいインデックスを保存すると、サービスに対する書き込みアクセス権が検証されます。

このアプローチは、REST クライアント拡張機能を備えた Visual Studio Code を前提としています。

Azure CLI のコマンドシェルを開き、Azure サブスクリプションにサインインします。
```
az login
```
テナント ID とサブスクリプション ID を取得します。この ID は、今後の手順で変数として使用されます。
```
az account show
```

アクセストークンを取得します。

az account get-access-token --query accessToken --output tsv

Visual Studio Code の新しいテキストファイルに、次の変数を貼り付けます。

@baseUrl = PASTE-YOUR-SEARCH-SERVICE-URL-HERE
@index-name = PASTE-YOUR-INDEX-NAME-HERE
@token = PASTE-YOUR-TOKEN-HERE

指定した変数を使用する要求を貼り付けて送信します。 "検索インデックスデータ閲覧者" であればクエリを送信できます。サポートされている API バージョンを使用できます。

POST https://{{baseUrl}}/indexes/{{index-name}}/docs/search?api-version=2023-11-01 HTTP/1.1
  Content-type: application/json
  Authorization: Bearer {{token}}

    {
         "queryType": "simple",
         "search": "motel",
         "filter": "",
         "select": "HotelName,Description,Category,Tags",
         "count": true
     }

特定の環境のトークンを取得する方法の詳細については、「REST API を使用して Azure AI 検索サービスを管理する」および「Microsoft ID プラットフォームの認証ライブラリ」を参照してください。

Azure.Search.Documents パッケージを使用します。
トークン認証用に Azure.Identity for .NET を使用します。 Microsoft ではほとんどのシナリオで DefaultAzureCredential() を推奨します。
- OAuth トークンを取得する場合、スコープは "https://search.azure.com/.default" です。 SDK では、対象ユーザーを "https://search.azure.com" にする必要があります。 ".default" は、Microsoft Entra 規約です。
- SDK では、ユーザーが "user_impersonation" スコープを持っていることを検証します。このスコープは、アプリによって付与される必要がありますが、SDK 自体は "https://search.azure.com/.default" を要求するだけです。

DefaultAzureCredential() を使用したクライアント接続の例を次に示します。

// Create a SearchIndexClient to send create/delete index commands
SearchIndexClient adminClient = new SearchIndexClient(serviceEndpoint, new DefaultAzureCredential());

// Create a SearchClient to load and query documents
SearchClient srchclient = new SearchClient(serviceEndpoint, indexName, new DefaultAzureCredential());

クライアントシークレット資格情報の別の使用例を次に示します。

var tokenCredential =  new ClientSecretCredential(aadTenantId, aadClientId, aadSecret);
SearchClient srchclient = new SearchClient(serviceEndpoint, indexName, tokenCredential);

azure.search.documents (Azure SDK for Python) を使用します。
トークン認証用に Azure.Identity for Python を使用します。
Python クライアントがサーバー側で実行しているアプリケーションである場合、DefaultAzureCredential を使用します。アプリがブラウザーで実行している場合、対話型の認証を有効にします。

次に例を示します。

from azure.search.documents import SearchClient
from azure.identity import DefaultAzureCredential

credential = DefaultAzureCredential()
endpoint = "https://<mysearch>.search.windows.net"
index_name = "myindex"
client = SearchClient(endpoint=endpoint, index_name=index_name, credential=credential)

@azure/search-documents (Azure SDK for JavaScript) バージョン 11.3 を使用します。
トークン認証用に Azure.Identity for JavaScript を使用します。
React を使用している場合は、Search に対する Microsoft Entra 認証に InteractiveBrowserCredential を使用します。詳細については、「@azure/identity を使用する場合」を参照してください。

現在のユーザーとしてテスト

既に検索サービスの共同作成者または所有者である場合は、Azure AI Search への認証用のユーザー ID としてベアラートークンを提示できます。

Azure CLI を使用して現在のユーザーのベアラートークンを取得します。
```
az account get-access-token --scope https://search.azure.com/.default
```
または PowerShell を使用する方法:
```
Get-AzAccessToken -ResourceUrl "https://graph.microsoft.com/"
```

Visual Studio Code の新しいテキストファイルに、次の変数を貼り付けます。

@baseUrl = PASTE-YOUR-SEARCH-SERVICE-URL-HERE
@index-name = PASTE-YOUR-INDEX-NAME-HERE
@token = PASTE-YOUR-TOKEN-HERE

アクセスを確認する要求を貼り付けて送信します。これは hotels-quickstart インデックスに対してクエリを実行するものです。

POST https://{{baseUrl}}/indexes/{{index-name}}/docs/search?api-version=2023-11-01 HTTP/1.1
  Content-type: application/json
  Authorization: Bearer {{token}}

    {
         "queryType": "simple",
         "search": "motel",
         "filter": "",
         "select": "HotelName,Description,Category,Tags",
         "count": true
     }

1 つのインデックスへのアクセスを許可する

シナリオの一部では、アプリケーションでアクセスできる範囲を単一のリソース (インデックスなど) に制限することが必要になる場合があります。

ポータルでは現在、このレベルの細分性でロールの割り当てはサポートされていませんが、 PowerShell または Azure CLI を使用して実行できます。

PowerShell では、New-AzRoleAssignment を使って、Azure のユーザーまたはグループの名前と、割り当てのスコープを指定します。

Azure および AzureAD モジュールを読み込み、Azure アカウントに接続します。
```
Import-Module -Name Az
Import-Module -Name AzureAD
Connect-AzAccount
```

個々のインデックスにスコープを設定したロールの割り当てを追加します。

New-AzRoleAssignment -ObjectId <objectId> `
    -RoleDefinitionName "Search Index Data Contributor" `
    -Scope  "/subscriptions/<subscription>/resourceGroups/<resource-group>/providers/Microsoft.Search/searchServices/<search-service>/indexes/<index-name>"

カスタムロールを作成する

組み込みロールに適切なアクセス許可の組み合わせがない場合は、カスタムロールを作成して必要な操作をサポートすることができます

この例では、検索インデックスデータ閲覧者を複製し、名前でインデックスを一覧表示する権限を追加します。通常、検索サービスのインデックスを一覧表示することは管理者の権利とされています。

次の手順は、「Azure portal を使用して Azure カスタムロールを作成または更新する」から派生したものです。検索サービスページでは、既存のロールからの複製がサポートされています。

次の手順では、インデックスを名前で一覧表示する権限を追加して検索クエリの権限を増強したカスタムロールを作成します。通常、インデックスの一覧表示は管理者用の機能とされています。

Azure portal で検索サービスに移動します。
左側のナビゲーションペインで [アクセス制御 (IAM)] を選択します。
アクションバーで、[ロール] を選択します。
[検索インデックスデータ閲覧者] (または別のロール) を右クリックし、[複製] を選択して [カスタムロールを作成する] ウィザードを開きます。
[基本] タブでカスタムロールの名前 ("Search Index Data Explorer" など) を指定し、[次へ] をクリックします。
[アクセス許可] タブで [アクセス許可の追加] を選択します。
[アクセス許可の追加] タブで、Microsoft Search タイルを検索して選択します。
カスタムロールのアクセス許可を設定します。ページの上部で、既定の [アクション] の選択を使用して以下を行います。
- Microsoft.Search/operations で、[Read : List all available operations]\(読み取り: 使用可能なすべての操作を一覧表示する\) を選択します。
- Microsoft.Search/searchServices/indexes で、[Read: Read Index]\(読み取り: インデックスの読み取り\) を選択します。

同じページの [データアクション] に切り替え、Microsoft.Search/searchServices/indexes/documents で [Read : Read Documents]\(読み取り: ドキュメントの読み取り\) を選択します。

JSON の定義は、次の例のようになります。

{
 "properties": {
     "roleName": "search index data explorer",
     "description": "",
     "assignableScopes": [
         "/subscriptions/a5b1ca8b-bab3-4c26-aebe-4cf7ec4791a0/resourceGroups/heidist-free-search-svc/providers/Microsoft.Search/searchServices/demo-search-svc"
     ],
     "permissions": [
         {
             "actions": [
                 "Microsoft.Search/operations/read",
                 "Microsoft.Search/searchServices/indexes/read"
             ],
             "notActions": [],
             "dataActions": [
                 "Microsoft.Search/searchServices/indexes/documents/read"
             ],
             "notDataActions": []
         }
     ]
   }
 }

[確認および作成] を選択してロールを作成します。これで、ユーザーとグループをロールに割り当てることがきるようになりました。

この PowerShell の例は、検索インデックスデータ閲覧者の複製に、すべてのインデックスを名前で一覧表示することができる権限を追加したカスタムロールを作成するための JSON 構文を示しています。

アトミックアクセス許可の一覧を確認して、必要なものを判断します。この例には、次のものが必要です。
```
"Microsoft.Search/operations/read",
"Microsoft.Search/searchServices/read",
"Microsoft.Search/searchServices/indexes/read"
```
カスタムロールを作成する PowerShell セッションを設定します。詳細な手順については、Azure PowerShell の記事を参照してください。
JSON ドキュメントとしてロール定義を用意します。 PowerShell を使ってカスタムロールを作成する構文の例を次に示します。

{
  "Name": "Search Index Data Explorer",
  "Id": "88888888-8888-8888-8888-888888888888",
  "IsCustom": true,
  "Description": "List all indexes on the service and query them.",
  "Actions": [
      "Microsoft.Search/operations/read",
      "Microsoft.Search/searchServices/read"
  ],
  "NotActions": [],
  "DataActions": [
      "Microsoft.Search/searchServices/indexes/read"
  ],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/{subscriptionId1}"
  ]
}

Note

割り当て可能なスコープがインデックスレベルの場合、データアクションは "Microsoft.Search/searchServices/indexes/documents/read" である必要があります。

API キー認証を無効にする

キーアクセス、またはローカル認証は、検索サービス共同作成者、検索インデックスデータ共同作成者、検索インデックスデータ閲覧者の各ロールと、Microsoft Entra 認証を使用している場合は、サービスで無効にできます。 API キーを無効にすると、ヘッダーで API キーを渡すデータ関連のすべての要求を検索サービスが拒否します。

Note

管理者 API キーは無効にできるだけで、削除できません。クエリ API キーは削除できます。

機能を無効にするには、所有者または共同作成者のアクセス許可が必要です。

キーベースの認証を無効にするには、Azure portal または Management REST API を使用します。

ポータル
REST API

Azure portal で検索サービスに移動します。
左側のナビゲーションウィンドウで、[キー] を選択します。
[ロールベースのアクセス制御] を選択します。

変更はすぐに有効になりますが、テストする前に数秒待ってください。所有者、サービス管理者、または共同管理者のメンバーとしてロールを割り当てるアクセス許可があると仮定すると、ポータル機能を使用してロールベースのアクセスをテストできます。

キーベースの認証を無効にするには、"disableLocalAuth" を true に設定します。

現在の構成を確認できるように、サービス設定を取得します。

GET https://management.azure.com/subscriptions/{{subscriptionId}}/providers/Microsoft.Search/searchServices?api-version=2023-11-01

PATCH を使用し、サービス構成を更新します。次の修正により、"authOptions" が null に設定されます。

PATCH https://management.azure.com/subscriptions/{{subscriptionId}}/resourcegroups/{{resource-group}}/providers/Microsoft.Search/searchServices/{{search-service-name}}?api-version=2023-11-01
{
    "properties": {
        "disableLocalAuth": true
    }
}

API キーのみを含み、ベアラートークンを含まない要求は、HTTP 401 で失敗します。

キー認証を再度有効にするには、最後の要求を再実行して、"disableLocalAuth" を false に設定します。検索サービスでは、要求での API キーの受け入れが自動的に再開されます (機能が指定されている場合)。

条件付きアクセス

条件付きアクセスは、組織のポリシーを適用するために Microsoft Entra ID で使われるツールです。条件付きアクセスポリシーを使用すると、必要な場合は適切なアクセス制御を適用して組織のセキュリティを維持することができます。ロールベースのアクセス制御を使用して Azure AI Search サービスにアクセスすると、条件付きアクセスにより、組織ポリシーを適用することができます。

Azure AI Search の条件付きアクセスポリシーを有効にするには、下の手順を実行します。

Azure portalにサインインします。
Microsoft Entra 条件付きアクセスを検索します。
[ポリシー] を選択します。
[新しいポリシー] を選択します。
ポリシーの [クラウドアプリまたは操作] セクションで、ポリシーの設定方法に応じて、クラウドアプリとして Azure AI Search を追加します。
ポリシーの残りのパラメーターを更新します。たとえば、このポリシーを適用するユーザーとグループを指定します。
ポリシーを保存します。

重要

検索サービスにマネージド ID が割り当てられている場合、その検索サービスは、条件付きアクセスポリシーの一部として含めたり、除外したりすることができるクラウドアプリとして表示されます。条件付きアクセスポリシーを特定の検索サービスに適用することはできません。代わりに、一般的な Azure AI Search クラウドアプリを選択してください。

ロールベースの Access Control の問題のトラブルシューティング

認証にロールベースのアクセス制御を使用するアプリケーションを開発する場合、いくつかの一般的な問題が発生する可能性があります。

承認トークンがマネージド ID から取得され、適切なアクセス許可が最近割り当てられた場合、これらのアクセス許可の割り当てが有効になるには、数時間かかる場合があります。
検索サービスの既定の構成は、キーベースの認証のみです。既定のキー設定を [両方] または [ロールベースのアクセス制御] に変更しなかった場合、基になるアクセス許可に関係なく、ロールベースの認証を使用するすべての要求が自動的に拒否されます。

Azure ロールベースのアクセス制御 (Azure RBAC) を使用して Azure AI Search に接続する

Search で使用される組み込みロール

制限事項

データ プレーンにロールベースのアクセスを構成する

ロールの割り当て

ロールの割り当てをテストする

現在のユーザーとしてテスト

1 つのインデックスへのアクセスを許可する

カスタム ロールを作成する

API キー認証を無効にする

条件付きアクセス

ロール ベースの Access Control の問題のトラブルシューティング

その他のリソース

データプレーンにロールベースのアクセスを構成する

カスタムロールを作成する

ロールベースの Access Control の問題のトラブルシューティング