Azure Arc 対応 Kubernetes クラスターで Azure RBAC を使用する (プレビュー)

  • [アーティクル]

Kubernetes の ClusterRoleBinding および RoleBinding オブジェクト型は、Kubernetes でネイティブに承認を定義するのに役立ちます。 この機能を使用すると、Microsoft Entra ID と Azure のロールの割り当てを使用して、クラスターでの承認チェックを制御できます。 Azure ロールの割り当てにより、デプロイ、ポッド、サービスなどの Kubernetes オブジェクトを読み取り、書き込み、削除できるユーザーを細かく制御できます。

この機能の概念の概要については、「Azure Arc 対応 Kubernetes での Azure RBAC」を参照してください。

重要

Azure Arc 対応 Kubernetes のプレビュー機能は、セルフサービス、オプトイン ベースで利用できます。 プレビューは、"現状有姿のまま" および "利用可能な限度" で提供され、サービス レベル アグリーメントおよび限定保証から除外されるものとします。 Azure Arc 対応 Kubernetes のプレビューは、ベストエフォート ベースでカスタマー サポートによって部分的にカバーされます。

前提条件

Note

この機能は、Red Hat OpenShift、またはユーザーがクラスターの API サーバーにアクセスできない、Elastic Kubernetes Service や Google Kubernetes Engine などのクラウド プロバイダーのマネージド Kubernetes オファリングには設定できません。 Azure Kubernetes Service (AKS) クラスターの場合、この機能はネイティブで利用可能であり、AKS クラスターを Azure Arc に接続する必要はありません。

Microsoft Entra アプリケーションを設定する

サーバー アプリケーションを作成する

  1. 新しい Microsoft Entra アプリケーションを作成し、その appId 値を取得します。 この値は、後の手順で serverApplicationId として使用されます。

    CLUSTER_NAME="<name-of-arc-connected-cluster>"
TENANT_ID="<tenant>"
SERVER_UNIQUE_SUFFIX="<identifier_suffix>"
SERVER_APP_ID=$(az ad app create --display-name "${CLUSTER_NAME}Server" --identifier-uris "api://${TENANT_ID}/${SERVER_UNIQUE_SUFFIX}" --query appId -o tsv)
echo $SERVER_APP_ID

  2. サーバー アプリケーションに "サインインとユーザー プロファイルの読み取り" API アクセス許可を付与するには、この JSON をコピーし、oauth2-permissions.json という名前のファイルに保存します。

    {
    "oauth2PermissionScopes": [
        {
            "adminConsentDescription": "Sign in and read user profile",
            "adminConsentDisplayName": "Sign in and read user profile",
            "id": "<paste_the_SERVER_APP_ID>",
            "isEnabled": true,
            "type": "User",
            "userConsentDescription": "Sign in and read user profile",
            "userConsentDisplayName": "Sign in and read user profile",
            "value": "User.Read"
        }
    ]
}

  3. アプリケーションのグループ メンバーシップ クレームを更新します。 oauth2-permissions.json ファイルと同じディレクトリでコマンドを実行します。 Azure Arc 対応 Kubernetes の RBAC では、signInAudience を AzureADMyOrg に設定する必要があります。

    az ad app update --id "${SERVER_APP_ID}" --set groupMembershipClaims=All
az ad app update --id ${SERVER_APP_ID} --set  api=@oauth2-permissions.json
az ad app update --id ${SERVER_APP_ID} --set  signInAudience=AzureADMyOrg
SERVER_OBJECT_ID=$(az ad app show --id "${SERVER_APP_ID}" --query "id" -o tsv)
az rest --method PATCH --headers "Content-Type=application/json" --uri https://graph.microsoft.com/v1.0/applications/${SERVER_OBJECT_ID}/ --body '{"api":{"requestedAccessTokenVersion": 1}}'

  4. サービス プリンシパルを作成し、その password フィールド値を取得します。 この値は、後ほどクラスターでこの機能を有効にするときに serverApplicationSecret として必要になります。 このシークレットは既定では 1 年間有効であり、その後にローテーションさせる必要があります。 カスタムの有効期限を設定するには、az ad sp credential reset を使います。

    az ad sp create --id "${SERVER_APP_ID}"
SERVER_APP_SECRET=$(az ad sp credential reset --id "${SERVER_APP_ID}"  --query password -o tsv)

  5. az ad app permission を使って、アプリケーションに "サインインとユーザー プロファイルの読み取り" API アクセス許可を付与します。

    az ad app permission add --id "${SERVER_APP_ID}" --api 00000003-0000-0000-c000-000000000000 --api-permissions e1fe6dd8-ba31-4d61-89e7-88639da4683d=Scope
az ad app permission grant --id "${SERVER_APP_ID}" --api 00000003-0000-0000-c000-000000000000 --scope User.Read

    Note

    このステップは、Azure アプリケーション管理者が行う必要があります。

    運用環境でこの機能を使用する場合は、クラスターごとに異なるサーバー アプリケーションを作成することをお勧めします。

クライアント アプリケーションを作成する

  1. 新しい Microsoft Entra アプリケーションを作成し、その appId 値を取得します。 この値は、後の手順で clientApplicationId として使用されます。

    CLIENT_UNIQUE_SUFFIX="<identifier_suffix>" 
CLIENT_APP_ID=$(az ad app create --display-name "${CLUSTER_NAME}Client" --is-fallback-public-client --public-client-redirect-uris "api://${TENANT_ID}/${CLIENT_UNIQUE_SUFFIX}" --query appId -o tsv)
echo $CLIENT_APP_ID

  2. このクライアント アプリケーション用のサービス プリンシパルを作成します。

    az ad sp create --id "${CLIENT_APP_ID}"

  3. サーバー アプリケーションの oAuthPermissionId 値を取得します。

        az ad app show --id "${SERVER_APP_ID}" --query "api.oauth2PermissionScopes[0].id" -o tsv

  4. クライアント アプリケーションに必要なアクセス許可を付与します。 Azure Arc 対応 Kubernetes の RBAC では、signInAudience を AzureADMyOrg に設定する必要があります。

        az ad app permission add --id "${CLIENT_APP_ID}" --api "${SERVER_APP_ID}" --api-permissions <oAuthPermissionId>=Scope
    RESOURCE_APP_ID=$(az ad app show --id "${CLIENT_APP_ID}"  --query "requiredResourceAccess[0].resourceAppId" -o tsv)
    az ad app permission grant --id "${CLIENT_APP_ID}" --api "${RESOURCE_APP_ID}" --scope User.Read
    az ad app update --id ${CLIENT_APP_ID} --set  signInAudience=AzureADMyOrg
    CLIENT_OBJECT_ID=$(az ad app show --id "${CLIENT_APP_ID}" --query "id" -o tsv)
    az rest --method PATCH --headers "Content-Type=application/json" --uri https://graph.microsoft.com/v1.0/applications/${CLIENT_OBJECT_ID}/ --body '{"api":{"requestedAccessTokenVersion": 1}}'

サーバー アプリケーション用のロールの割り当てを作成する

要求を行っているユーザーが要求に含まれる Kubernetes オブジェクトで承認されていることを確認できるよう、サーバー アプリケーションには Microsoft.Authorization/*/read アクセス許可が必要です。

  1. 次の内容で accessCheck.json という名前のファイルを作成します。

    {
"Name": "Read authorization",
"IsCustom": true,
"Description": "Read authorization",
"Actions": ["Microsoft.Authorization/*/read"],
"NotActions": [],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
  "/subscriptions/<subscription-id>"
  ]
}

    <subscription-id> は実際のサブスクリプション ID に置き換えます。

  2. 次のコマンドを実行して、新しいカスタム ロールを作成します。

    ROLE_ID=$(az role definition create --role-definition ./accessCheck.json --query id -o tsv)

  3. 作成したロールを使用して、サーバー アプリケーションに assignee としてロールの割り当てを作成します。

    az role assignment create --role "${ROLE_ID}" --assignee "${SERVER_APP_ID}" --scope /subscriptions/<subscription-id>

クラスターで Azure RBAC を有効にする

次のコマンドを実行して、Azure Arc 対応 Kubernetes クラスターで Azure ロールベースのアクセス制御 (RBAC) を有効にします。

az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac --app-id "${SERVER_APP_ID}" --app-secret "${SERVER_APP_SECRET}"

Note

上記のコマンドを実行する前に、マシン上の kubeconfig ファイルで、Azure RBAC 機能を有効にするクラスターを参照していることを確認します。

Azure RBAC ではなく、Kubernetes ネイティブの ClusterRoleBinding オブジェクトと RoleBinding オブジェクトを使用して承認チェックを受けるユーザー名、メール アドレス、OpenID 接続のコンマ区切りリストを表示するには、上記のコマンドで --skip-azure-rbac-list を使用します。

apiserver 仕様で競合回避モジュールが実行されていない汎用クラスター

  1. クラスターの各マスター ノードに SSH 接続し、次の手順を実行します。

    kube-apiserver が静的ポッドの場合:

    1. kube-system 名前空間の azure-arc-guard-manifests シークレットには、guard-authn-webhook.yaml と guard-authz-webhook.yaml の 2 つのファイルが含まれます。 これらのファイルをノードの /etc/guard ディレクトリにコピーします。

      sudo mkdir -p /etc/guard
kubectl get secrets azure-arc-guard-manifests -n kube-system -o json | jq -r '.data."guard-authn-webhook.yaml"' | base64 -d > /etc/guard/guard-authn-webhook.yaml
kubectl get secrets azure-arc-guard-manifests -n kube-system -o json | jq -r '.data."guard-authz-webhook.yaml"' | base64 -d > /etc/guard/guard-authz-webhook.yaml

    2. apiserver マニフェストを編集モードで開きます。

      sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml

    3. volumes に次の指定を追加します。

      - name: azure-rbac
    hostPath:
    path: /etc/guard
    type: Directory

    4. volumeMounts に次の指定を追加します。

      - mountPath: /etc/guard
    name: azure-rbac
    readOnly: true

    kube-apiserver が静的ポッドではない場合:

    1. apiserver マニフェストを編集モードで開きます。

      sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml

    2. volumes に次の指定を追加します。

      - name: azure-rbac
    secret:
    secretName: azure-arc-guard-manifests

    3. volumeMounts に次の指定を追加します。

      - mountPath: /etc/guard
    name: azure-rbac
    readOnly: true

  2. 次の apiserver 引数を追加します。

    - --authentication-token-webhook-config-file=/etc/guard/guard-authn-webhook.yaml
- --authentication-token-webhook-cache-ttl=5m0s
- --authorization-webhook-cache-authorized-ttl=5m0s
- --authorization-webhook-config-file=/etc/guard/guard-authz-webhook.yaml
- --authorization-webhook-version=v1
- --authorization-mode=Node,RBAC,Webhook

    Kubernetes クラスターがバージョン 1.19.0 以降の場合は、次の apiserver 引数も設定する必要があります。

    - --authentication-token-webhook-version=v1

  3. 保存してエディターを閉じ、apiserver ポッドを更新します。

Cluster API を使用して作成されたクラスター

  1. 認証と承認の Webhook 構成ファイルを含むガード シークレットを、ワークロード クラスターからマシンにコピーします。

    kubectl get secret azure-arc-guard-manifests -n kube-system -o yaml > azure-arc-guard-manifests.yaml

  2. azure-arc-guard-manifests.yaml ファイルの namespace フィールドを、ワークロード クラスターを作成するためのカスタム リソースを適用する管理クラスター内の名前空間に変更します。

  3. このマニフェストを適用します。

    kubectl apply -f azure-arc-guard-manifests.yaml

  4. kubectl edit kcp <clustername>-control-plane を実行して、KubeadmControlPlane オブジェクトを編集します。

    1. 次のスニペットを files に追加します。

      - contentFrom:
    secret:
      key: guard-authn-webhook.yaml
      name: azure-arc-guard-manifests
  owner: root:root
  path: /etc/kubernetes/guard-authn-webhook.yaml
  permissions: "0644"
- contentFrom:
    secret:
      key: guard-authz-webhook.yaml
      name: azure-arc-guard-manifests
  owner: root:root
  path: /etc/kubernetes/guard-authz-webhook.yaml
  permissions: "0644"

    2. 次のスニペットを apiServer>extraVolumes に追加します。

      - hostPath: /etc/kubernetes/guard-authn-webhook.yaml
    mountPath: /etc/guard/guard-authn-webhook.yaml
    name: guard-authn
    readOnly: true
- hostPath: /etc/kubernetes/guard-authz-webhook.yaml
    mountPath: /etc/guard/guard-authz-webhook.yaml
    name: guard-authz
    readOnly: true

    3. 次のスニペットを apiServer>extraArgs に追加します。

      authentication-token-webhook-cache-ttl: 5m0s
authentication-token-webhook-config-file: /etc/guard/guard-authn-webhook.yaml
authentication-token-webhook-version: v1
authorization-mode: Node,RBAC,Webhook
authorization-webhook-cache-authorized-ttl: 5m0s
authorization-webhook-config-file: /etc/guard/guard-authz-webhook.yaml
authorization-webhook-version: v1

    4. 保存して閉じ、KubeadmControlPlane オブジェクトを更新します。 ワークロード クラスターにこれらの変更が表示されるまで待ちます。

ユーザーがクラスターにアクセスするためのロールの割り当てを作成する

Azure Arc 対応 Kubernetes リソースの所有者は、組み込みロールまたはカスタム ロールを使用して、他のユーザーに Kubernetes クラスターへのアクセス権を付与できます。

組み込みのロール

Role 説明
Azure Arc Kubernetes ビューアー 名前空間内のほとんどのオブジェクトを表示するための読み取り専用アクセスが許可されます。 シークレットに対する read アクセス許可によって、名前空間内の ServiceAccount の資格情報にアクセスできるようになるため、このロールではシークレットを表示することはできません。 これらの資格情報により、その ServiceAccount 値を使用して API アクセスが可能になります (特権エスカレーションの一形式)。
Azure Arc Kubernetes ライター 名前空間内のほとんどのオブジェクトに対する読み取りと書き込みのアクセスが許可されます。 このロールでは、ロールまたはロールのバインドを表示または変更することはできません。 ただし、このロールを使用すると、シークレットにアクセスし、名前空間内の任意の ServiceAccount 値としてポッドを実行できるので、名前空間内の任意の ServiceAccount 値の API アクセス レベルを取得するために使用できます。
Azure Arc Kubernetes 管理者 管理者アクセスを許可します。 これは、RoleBinding を使用して名前空間内で付与することを目的としています RoleBinding で使用すると、名前空間内でロールとロール バインドを作成できるなど、名前空間内のほとんどのリソースへの読み取り/書き込みアクセスが許可されます。 このロールでは、リソース クォータまたは名前空間自体への書き込みアクセスは許可されません。
Azure Arc Kubernetes クラスター管理者 任意のリソースに対して任意のアクションを実行できるスーパーユーザー アクセスが許可されます。 ClusterRoleBinding で使用すると、クラスター内およびすべての名前空間内のすべてのリソースを完全に制御できます。 RoleBinding で使用すると、ロール バインドの名前空間内のすべてのリソース (名前空間自体を含む) を完全に制御できます。

Azure portal のクラスター リソースの [アクセス制御 (IAM)] ペインで、Azure Arc 対応 Kubernetes クラスターをスコープとするロールの割り当てを作成できます。 次の Azure CLI コマンドを使用することもできます。

az role assignment create --role "Azure Arc Kubernetes Cluster Admin" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID

これらのコマンドで、AZURE-AD-ENTITY-ID には、ユーザー名 (例: testuser@mytenant.onmicrosoft.com) を指定することも、サービス プリンシパルの appId 値を指定することもできます。

クラスター内の特定の名前空間をスコープとしたロールの割り当てを作成する別の例を次に示します。

az role assignment create --role "Azure Arc Kubernetes Viewer" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID/namespaces/<namespace-name>

Note

クラスターをスコープとするロールの割り当ては、Azure portal または Azure CLI を使って作成できます。 一方、名前空間をスコープとするロールの割り当ての作成には、Azure CLI だけを使用できます。

カスタム ロール

ロールの割り当てで使用する独自のロールの定義を作成することもできます。

ユーザーにデプロイの読み取りだけを許可するロールの定義の例を次に示します。 詳細については、ロールの定義の作成に使用できるデータ アクションの完全な一覧を参照してください。

次の JSON オブジェクトを、custom-role.json というファイルにコピーします。 <subscription-id> プレースホルダーは、実際のサブスクリプション ID に置き換えます。 カスタム ロールでは、いずれかのデータ アクションを使用し、ロールの割り当てが作成されたスコープ (クラスターまたは名前空間) 内のすべてのデプロイを表示できます。

{
    "Name": "Arc Deployment Viewer",
    "Description": "Lets you view all deployments in cluster/namespace.",
    "Actions": [],
    "NotActions": [],
    "DataActions": [
        "Microsoft.Kubernetes/connectedClusters/apps/deployments/read"
    ],
    "NotDataActions": [],
    "assignableScopes": [
        "/subscriptions/<subscription-id>"
    ]
}

  1. custom-role.json を保存したフォルダーから次のコマンドを実行して、ロールの定義を作成します。

    az role definition create --role-definition @custom-role.json

  2. このカスタム ロールの定義を使用して、ロールの割り当てを作成します。

    az role assignment create --role "Arc Deployment Viewer" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID/namespaces/<namespace-name>

ユーザー資格情報を使用して kubectl を構成する

クラスターにアクセスするために必要な kubeconfig ファイルを取得するには、次の 2 つの方法があります。

  • Azure Arc 対応 Kubernetes クラスターのクラスター接続機能 (az connectedk8s proxy) を使用します。
  • クラスター管理者が、他のすべてのユーザーと kubeconfig ファイルを共有します。

クラスター接続を使用する

次のコマンドを実行して、プロキシ プロセスを開始します。

az connectedk8s proxy -n <clusterName> -g <resourceGroupName>

プロキシ プロセスの実行後、コンソールで別のタブを開いて、クラスターへの要求の送信を開始できます。

共有 kubeconfig ファイルを使用する

共有 kubeconfig を使用するには、Kubernetes のバージョンによって少し異なる手順が必要です。

  1. 次のコマンドを実行して、ユーザーの資格情報を設定します。

    kubectl config set-credentials <testuser>@<mytenant.onmicrosoft.com> \
--auth-provider=azure \
--auth-provider-arg=environment=AzurePublicCloud \
--auth-provider-arg=client-id=<clientApplicationId> \
--auth-provider-arg=tenant-id=<tenantId> \
--auth-provider-arg=apiserver-id=<serverApplicationId>

  2. 前に作成した kubeconfig ファイルを開きます。 contexts で、クラスターに関連付けられているコンテキストが、前の手順で作成したユーザー資格情報を参照していることを確認します。 現在のコンテキストをこれらのユーザー資格情報に設定するには、次のコマンドを実行します。

    kubectl config set-context --current=true --user=<testuser>@<mytenant.onmicrosoft.com>

  3. user>config に、config-mode 設定を追加します。

    name: testuser@mytenant.onmicrosoft.com
user:
    auth-provider:
    config:
        apiserver-id: $SERVER_APP_ID
        client-id: $CLIENT_APP_ID
        environment: AzurePublicCloud
        tenant-id: $TENANT_ID
        config-mode: "1"
    name: azure

Note

Exec プラグイン は、kubectl が apiserver に送信するユーザー資格情報を受信する外部コマンドを実行できる Kubernetes 認証戦略です。 Kubernetes バージョン 1.26 以降では、既定の Azure 承認プラグインは client-go および kubectl に含まれません。 新しいバージョンでは、exec プラグインを使用してユーザー資格情報を受け取るには、Azure 認証を実装する client-go 資格情報 (exec) プラグインである Azure Kubeloginを使用する必要があります。

  1. Azure Kubelogin をインストールします。

    • Windows または Mac の場合は、「Azure Kubelogin のインストール手順」に従います。

    • Linux または Ubuntu の場合は、最新バージョンの kubelogin をダウンロードし、次のコマンドを実行します。

      curl -LO https://github.com/Azure/kubelogin/releases/download/"$KUBELOGIN_VERSION"/kubelogin-linux-amd64.zip 

unzip kubelogin-linux-amd64.zip 

sudo mv bin/linux_amd64/kubelogin /usr/local/bin/ 

sudo chmod +x /usr/local/bin/kubelogin

  2. 適切なログイン モードを使用するように kubelogin を変換します。 たとえば、Microsoft Entra ユーザーによるデバイス コード ログイン の場合、コマンドは次のようになります。

    export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig

クラスターに要求を送信する

  1. 任意の kubectl コマンドを実行します。 次に例を示します。

    • kubectl get nodes
    • kubectl get pods

  2. ブラウザーベースの認証を求められたら、デバイス ログイン URL (https://microsoft.com/devicelogin) をコピーし、Web ブラウザーでそれを開きます。

  3. コンソールに出力されたコードを入力します。 ターミナルのコードをコピーして、デバイス認証入力のプロンプトに貼り付けます。

  4. ユーザー名 (testuser@mytenant.onmicrosoft.com) と、関連付けられているパスワードを入力します。

  5. このようなエラー メッセージが表示された場合は、要求したリソースへのアクセスが承認されていないことを意味します。

    Error from server (Forbidden): nodes is forbidden: User "testuser@mytenant.onmicrosoft.com" cannot list resource "nodes" in API group "" at the cluster scope: User doesn't have access to the resource in Azure. Update role assignment to allow access.

    管理者は、このユーザーがリソースにアクセスすることを承認する新しいロールの割り当てを作成する必要があります。

Microsoft Entra ID を使用した条件付きアクセスを使用する

Microsoft Entra ID を Azure Arc 対応 Kubernetes クラスターと統合すると、条件付きアクセスを使用してクラスターへのアクセスを制御することもできます。

Note

Microsoft Entra 条件付きアクセス は、Microsoft Entra ID P2 の機能です。

クラスターで使用する条件付きアクセス ポリシーの例を作成するには:

  1. Azure portal の上部で、Microsoft Entra ID を検索して選択します。

  2. 左側の Microsoft Entra ID のメニューで、[エンタープライズ アプリケーション] を選択します。

  3. 左側のエンタープライズ アプリケーションのメニューで、[条件付きアクセス] を選択します。

  4. 左側の条件付きアクセスのメニューで、[ポリシー]>[新しいポリシー] の順に選択します。

    Screenshot showing how to add a conditional access policy in the Azure portal.

  5. ポリシーの名前 (例: arc-k8s-policy) を入力します。

  6. ユーザーおよびグループの選択 [含める] で、[ユーザーとグループの選択] を選択します。 次に、ポリシーを適用するユーザーとグループを選択します。 この例では、クラスターへの管理者アクセス権を持つ同じ Microsoft Entra グループを選びます。

    Screenshot that shows selecting users or groups to apply the Conditional Access policy.

  7. [クラウド アプリまたは操作] を選択します。 [含める] で、 [アプリを選択] を選択します。 次に、前に作成したサーバー アプリケーションを検索して選択します。

    Screenshot showing how to select a server application in the Azure portal.

  8. [アクセス制御] で [許可] を選択します。 [アクセス権の付与]>[デバイスは準拠としてマーク済みである必要があります] の順に選択します。

    Screenshot showing how to allow only compliant devices in the Azure portal.

  9. [ポリシーの有効化] で、[オン]>[作成] の順に選択します。

    Screenshot showing how to enable a conditional access policy in the Azure portal.

クラスターに再びアクセスします。 たとえば、kubectl get nodes コマンドを実行して、クラスター内のノードを表示します。

kubectl get nodes

手順に従ってもう一度サインインします。 エラー メッセージに、正常にログインしたが、管理者の要求により、アクセスを要求しているデバイスは Microsoft Entra ID で管理されていないとリソースにアクセスできないことが示されます。 次の手順のようにします。

  1. Azure portal で、[Microsoft Entra ID] に移動します。

  2. [エンタープライズ アプリケーション] を選択します。 次に、[アクティビティ] で [サインイン] を選択します。

  3. 上部のエントリは、[状態] が [失敗]、[条件付きアクセス] が [成功] になっています。 このエントリを選択し、[詳細] で [条件付きアクセス] を選択します。 条件付きアクセス ポリシーが表示されます。

    Screenshot showing a failed sign-in entry in the Azure portal.

Microsoft Entra ID を使用して Just-In-Time クラスター アクセスを構成する

クラスター アクセス制御のもう 1 つのオプションは、Just-In-Time 要求に Privileged Identity Management (PIM) を使用することです。

Note

Microsoft Entra PIM は、Microsoft Entra ID P2 の機能です。 Microsoft Entra ID SKU の詳細については、価格ガイドを参照してください。

ご利用のクラスターに対して Just-In-Time アクセス要求を構成するには、次の手順を行います。

  1. Azure portal の上部で、Microsoft Entra ID を検索して選択します。

  2. テナント ID を書き留めておきます。 この手順の残りの部分では、この ID を <tenant-id> と表記しています。

    Screenshot showing Microsoft Entra ID details in the Azure portal.

  3. 左側の Microsoft Entra ID のメニューの [管理] で、[グループ]>[新しいグループ] の順に選択します。

  4. [グループの種類] で [セキュリティ] が選択されていることを確認します。 グループ名 (例: myJITGroup) を入力します。 [グループにMicrosoft Entra ロールを割り当てることができる (プレビュー)] で [はい] を選択します。 最後に、 [作成] を選択します。

    Screenshot showing details for the new group in the Azure portal.

  5. [グループ] ページに戻ります。 新しく作成したグループを選択し、オブジェクト ID を書き留めておきます。 この手順の残りの部分では、この ID を <object-id> と表記しています。

    Screenshot showing the object ID for the new group in the Azure portal.

  6. Azure portal に戻り、左側の [アクティビティ] のメニューで、[特権アクセス (プレビュー)] を選択します。 次に、[特権アクセスの有効化] を選択します。

    Screenshot showing selections for enabling privileged access in the Azure portal.

  7. [割り当ての追加] を選択して、アクセス権の付与を開始します。

    Screenshot showing how to add active assignments in the Azure portal.

  8. [メンバー] ロールを選択し、クラスターへのアクセス権を付与するユーザーとグループを選択します。 グループ管理者は、これらの割り当てをいつでも変更できます。 先に進む準備ができたら、[次へ] を選択します。

    Screenshot showing how to add assignments in the Azure portal.

  9. 割り当ての種類として [アクティブ] を選択し、目的の期間を選択して、理由を入力します。 続行する準備ができたら、[割り当て] を選択します。 割り当ての種類の詳細については、「Privileged Identity Management で特権アクセス グループ (プレビュー) の資格を割り当てる」を参照してください。

    Screenshot showing assignment properties in the Azure portal.

割り当てが完了したら、クラスターにアクセスして、Just-In-Time アクセスが機能していることを確認します。 たとえば、kubectl get nodes コマンドを使用して、クラスター内のノードを表示します。

kubectl get nodes

認証要件を確認し、手順に従って認証します。 認証が成功すると、次のような出力が表示されます。

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code AAAAAAAAA to authenticate.

NAME      STATUS   ROLES    AGE      VERSION
node-1    Ready    agent    6m36s    v1.18.14
node-2    Ready    agent    6m42s    v1.18.14
node-3    Ready    agent    6m33s    v1.18.14

サーバー アプリケーションのシークレットを更新する

サーバー アプリケーションサービス プリンシパルのシークレットの有効期限が切れている場合は、それを回転する必要があります。

SERVER_APP_SECRET=$(az ad sp credential reset --name "${SERVER_APP_ID}" --credential-description "ArcSecret" --query password -o tsv)

クラスター上のシークレットを更新します。 コマンドが最初に実行されたときに構成した任意の省略可能なパラメーターを追加してください。

az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac --app-id "${SERVER_APP_ID}" --app-secret "${SERVER_APP_SECRET}"

次のステップ