Azure Arc 対応 Kubernetes クラスターで Azure RBAC を使用する

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

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

前提条件

• Azure CLI をインストールするか、最新バージョンにアップグレードします。

• 最新バージョンの connectedk8s Azure CLI 拡張機能をインストールします。

  az extension add --name connectedk8s
  

  connectedk8s 拡張機能が既にインストールされている場合は、次のコマンドを使用して最新バージョンに更新できます。

  az extension update --name connectedk8s
  

• 既存の Azure Arc 対応 Kubernetes クラスターを接続します。

  • クラスターをまだ接続していない場合は、クイックスタートを使用してください。
  • 最新バージョンにエージェントをアップグレードします。

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

1. 次のコマンドを実行して、クラスターの MSI ID を取得します。

   az connectedk8s show -g <resource-group> -n <connected-cluster-name>
   

2. 出力から ID (identity.principalId) を取得し、次のコマンドを実行して、接続クラスター マネージド ID CheckAccess 閲覧者ロールをクラスターの MSI に割り当てます。

   az role assignment create --role "Connected Cluster Managed Identity CheckAccess Reader" --assignee "<Cluster MSI ID>" --scope <cluster ARM ID>
   

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

   az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac
   

   注

   enable-features コマンドを実行する前に、マシン上のkubeconfig ファイルが、Azure RBAC を有効にするクラスターを指していることを確認します。

   Azure RBAC の代わりに Kubernetes ネイティブ --skip-azure-rbac-listオブジェクトとClusterRoleBinding オブジェクトを使用して承認チェックを受けるユーザー名、電子メール、OpenID 接続のコンマ区切りの一覧には、このコマンドでRoleBindingを使用します。

次に、 apiserver 仕様でリコンサイルが実行されていない汎用クラスターを使用しているか、クラスター API を使用して作成されたクラスターを使用しているかに応じて、適切なセクションの手順に従います。

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

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

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

   1. azure-arc-guard-manifests 名前空間の kube-system シークレットには、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 に次の指定を追加します。

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

   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
   

   次の 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. namespace ファイルの フィールドを、ワークロード クラスターを作成するためのカスタム リソースを適用する管理クラスター内の名前空間に変更します。

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

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

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

   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 クラスターへのアクセス権を付与できます。

組み込みのロール

次の組み込みロールは、Kubernetes クラスターで一般的なタスクを実行するためのアクセスを提供します。 これらのロールは、Microsoft Entra ID ユーザー、グループ、またはサービス プリンシパルに付与できます。

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

Azure portal で Azure Arc 対応 Kubernetes クラスターを対象にしたロールの割り当てを作成するには、クラスターに移動し、サービス メニューから アクセス制御 (IAM) を選択します。

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>

カスタム ロール

ロールの割り当てで使用する独自のロールの定義を作成することもできます。 詳細については、ロールの定義の作成に使用できるデータ アクションの完全な一覧を参照してください。

次の例は、ユーザーがデプロイを読み取ることができますが、他のアクセス権は提供しないカスタム ロール定義を示しています。 カスタム ロールでは、いずれかのデータ アクションを使用し、ロールの割り当てが作成されたスコープ (クラスターまたは名前空間) 内のすべてのデプロイを表示できます。

{
    "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>"
    ]
}

このロール定義を使用するには、次の JSON オブジェクトを custom-role.jsonという名前のファイルにコピーします。 <subscription-id> プレースホルダーは、実際のサブスクリプション 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 ファイルを使用する

1. 次のコマンドを実行して、ユーザーの資格情報を設定します。 serverApplicationId に 6256c85f-0aad-4d50-b960-e6e9b21efe35 を、clientApplicationId に 3f4439ff-e698-4d6d-84fe-09c9d574f06b を指定します。

   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 設定を追加します。

   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
   

4. Exec プラグイン は、kubectl が apiserver に送信するユーザー資格情報を受信する外部コマンドを実行できる Kubernetes 認証戦略です。 Kubernetes バージョン 1.26 以降では、exec プラグインを使用してユーザー資格情報を受信するには、Azure 認証を実装する資格情報 (exec) プラグインである client-go を使用する必要があります。 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 
     

5. 所有証明 (PoP) トークンを要求することで、kubelogin を使用して Azure Arc 対応クラスターで認証できます。 kubelogin を使って kubeconfig を変換し、適切なログイン モードを使用するようにします。 たとえば、Microsoft Entra ユーザーによるデバイス コード ログイン の場合、コマンドは次のようになります。

   export KUBECONFIG=/path/to/kubeconfig
   
   kubelogin convert-kubeconfig --pop-enabled --pop-claims 'u=<ARM ID of cluster>"
   

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

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

   • kubectl get nodes
   • kubectl get pods

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

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

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

5. ユーザーが Azure のリソースにアクセスできないことを示すエラー メッセージが表示された場合は、要求されたリソースにアクセスすることが許可されていないことを意味します。 この場合、Azure テナントの管理者は、このユーザーにリソースへのアクセス権を付与する新しいロールの割り当てを作成する必要があります。

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

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

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

1. Azure portal の上部で、Microsoft Entra ID を検索して選択します。
2. サービス メニューの [ 管理] で、[ エンタープライズ アプリケーション] を選択します。
3. サービス メニューの [ セキュリティ] で、[ 条件付きアクセス] を選択します。
4. サービス メニューで、[ポリシー] を選択 します。 次に、[ 新しいポリシーの作成] を選択します。
5. ポリシーの名前 ( arc-k8s-policyなど) を入力します。
6. [割り当て] で、[ユーザーまたはワークロードの ID] の下の現在の値を選択します。 次に、[ このポリシーの適用対象] で、[ ユーザーとグループ ] が選択されていることを確認します。
7. [含める] で、[ユーザーとグループの選択] を選択します。 次に、ポリシーを適用するユーザーとグループを選択します。 この例では、クラスターへの管理者アクセス権を持つ同じ Microsoft Entra グループを選びます。
8. [ クラウド アプリまたはアクション] で現在の値を選択します。 次に、[ このポリシーの適用対象を選択] で、[ クラウド アプリ ] が選択されていることを確認します。
9. 含めるで[リソースの選択] を選択します。 次に、前に作成したサーバー アプリケーションを検索して選択します。
10. アクセス制御 の下で、許可の現在の値を選択します。 次に、[ アクセス権の付与] を選択します。
11. デバイスが準拠としてマークされる必要がある のチェック ボックスをオンにし、選択 をクリックします。
12. [ポリシーの有効化] で、 [オン] を選択します。
13. 条件付きアクセス ポリシーを適用するには、[ 作成] を選択します。

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

kubectl get nodes

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

1. Azure portal で、[Microsoft Entra ID] に移動します。
2. サービス メニューの [ 管理] で、[ エンタープライズ アプリケーション] を選択します。
3. サービス メニューの [ アクティビティ] で、[ サインイン ログ] を選択します。
4. 上部にあるエントリを選択し、条件付きアクセスの状態と成功に失敗したことを示します。 次に、[ 詳細] で [ 条件付きアクセス ] を選択します。作成した条件付きアクセス ポリシーが表示され、デバイスが準拠している必要があります。

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

クラスター アクセス制御のもう 1 つのオプションは Privileged Identity Management (PIM) です。これにより、Just-In-Time 要求に対してユーザーに対してより高いレベルのアクセスが可能になります。

ユーザーのグループに対して Just-In-Time アクセス要求を構成するには、次の手順を実行します。

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

2. サービス メニューの [ 管理] で[グループ] を選択 します。 次に、[ 新しいグループ] を選択します。

3. [グループの種類] で、[セキュリティ] が選択されていることを確認します。 myJITGroupなどのグループ名を入力します。 追加の選択を行い、[ 作成] を選択します。

   

4. [グループ] ページに戻ります。 新しく作成したグループを検索して選択します。

5. サービス メニューの [ アクティビティ] で、[ Privileged Identity Management] を選択します。 次に、[ このグループの PIM を有効にする] を選択します。

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

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

   

8. 割り当ての種類として [アクティブ] を選択し、目的の期間を選択して、理由を入力します。 続行する準備ができたら、[割り当て] を選択します。

   

これらの手順とオプションの詳細については、「 Privileged Identity Management でグループの適格性を割り当てる」を参照してください。

割り当てが完了したら、クラスターにアクセスして、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

次のステップ

• Arc 対応 Kubernetes での Azure RBAC のアーキテクチャについて理解する。
• クラスター接続を使用して、Arc 対応 Kubernetes クラスターに安全に 接続します。
• Azure Arc 対応 Kubernetes のセキュリティブックのガイダンスに従って、クラスターを他の方法で保護します。