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

[アーティクル]
10/16/2024

Kubernetes の ClusterRoleBinding および RoleBinding オブジェクト型は、Kubernetes でネイティブに承認を定義するのに役立ちます。この機能を使用すると、Microsoft Entra ID と Azure のロールの割り当てを使用して、クラスターでの承認チェックを制御できます。 Azure ロールの割り当てにより、デプロイ、ポッド、サービスなどの 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 クラスターを接続します。
- クラスターをまだ接続していない場合は、クイックスタートを使用してください。
- 最新バージョンにエージェントをアップグレードします。

Note

Azure RBAC は、Red Hat OpenShift または API サーバーへのユーザーアクセスが制限されているマネージド Kubernetes オファリングでは使用できません (例: Amazon Elastic Kubernetes Service (EKS)、Google Kubernetes Engine (GKE))。

Azure RBAC では現在、ARM64 アーキテクチャで動作する Kubernetes クラスターはサポートされていません。 Kubernetes RBAC を使用して、ARM64 ベースの Kubernetes クラスターのアクセス制御を管理してください。

Azure Kubernetes Service (AKS) クラスターの場合、この機能はネイティブで利用可能であり、AKS クラスターを Azure Arc に接続する必要はありません。

Azure Stack HCI 23H2 上の Azure Arc で有効になっている Azure Kubernetes Service (AKS) クラスターの場合、Azure RBAC の有効化は現在、Kubernetes クラスターの作成時にのみサポートされています。 Azure RBAC を有効にして Azure Arc によって有効になっている AKS クラスターを作成するには、「Kubernetes 認可に Azure RBAC を使用する」ガイドに従います。 Azure RBAC は、Azure Stack HCI バージョン 22H2 ではサポートされていないことに注意してください。

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

次のコマンドを実行して、クラスターの MSI ID を取得します。
```
az connectedk8s show -g <resource-group> -n <connected-cluster-name>
```
出力から 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>
```
次のコマンドを実行して、Azure Arc 対応 Kubernetes クラスターで Azure ロールベースのアクセス制御 (RBAC) を有効にします。
```
az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac
```
Note

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

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

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

クラスターの各マスターノードに 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 に次の指定を追加します。
```
- 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
```

次の 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

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

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

認証と承認の Webhook 構成ファイルを含むガードシークレットを、ワークロードクラスターからマシンにコピーします。
```
kubectl get secret azure-arc-guard-manifests -n kube-system -o yaml > azure-arc-guard-manifests.yaml
```
azure-arc-guard-manifests.yaml ファイルの namespace フィールドを、ワークロードクラスターを作成するためのカスタムリソースを適用する管理クラスター内の名前空間に変更します。

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

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

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

次のスニペットを 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"

次のスニペットを 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

次のスニペットを 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

保存して閉じ、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>"
    ]
}

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

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

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 のバージョンによって少し異なる手順が必要です。

Kubernetes バージョン >= 1.26
Kubernetes < v1.26

次のコマンドを実行して、ユーザーの資格情報を設定します。 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>

前に作成した kubeconfig ファイルを開きます。 contexts で、クラスターに関連付けられているコンテキストが、前の手順で作成したユーザー資格情報を参照していることを確認します。現在のコンテキストをこれらのユーザー資格情報に設定するには、次のコマンドを実行します。
```
kubectl config set-context --current=true --user=<testuser>@<mytenant.onmicrosoft.com>
```
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を使用する必要があります。
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 
```
所有証明 (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>"
```

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>

前に作成した kubeconfig ファイルを開きます。 contexts で、クラスターに関連付けられているコンテキストが、前の手順で作成したユーザー資格情報を参照していることを確認します。現在のコンテキストをこれらのユーザー資格情報に設定するには、次のコマンドを実行します。
```
kubectl config set-context --current=true --user=<testuser>@<mytenant.onmicrosoft.com>
```

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

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

任意の kubectl コマンドを実行します。次に例を示します。
- kubectl get nodes
- kubectl get pods
ブラウザーベースの認証を求められたら、デバイスログイン URL (https://microsoft.com/devicelogin) をコピーし、Web ブラウザーでそれを開きます。
コンソールに出力されたコードを入力します。ターミナルのコードをコピーして、デバイス認証入力のプロンプトに貼り付けます。
ユーザー名 (testuser@mytenant.onmicrosoft.com) と、関連付けられているパスワードを入力します。
このようなエラーメッセージが表示された場合は、要求したリソースへのアクセスが承認されていないことを意味します。
```
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 の機能です。

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

Azure portal の上部で、Microsoft Entra ID を検索して選択します。
左側の Microsoft Entra ID のメニューで、[エンタープライズアプリケーション] を選択します。
左側のエンタープライズアプリケーションのメニューで、[条件付きアクセス] を選択します。
左側の条件付きアクセスのメニューで、[ポリシー]>[新しいポリシー] の順に選択します。
ポリシーの名前 (例: arc-k8s-policy) を入力します。
ユーザーおよびグループの選択 [含める] で、[ユーザーとグループの選択] を選択します。次に、ポリシーを適用するユーザーとグループを選択します。この例では、クラスターへの管理者アクセス権を持つ同じ Microsoft Entra グループを選びます。
[クラウドアプリまたは操作] を選択します。 [含める] で、 [アプリを選択] を選択します。次に、前に作成したサーバーアプリケーションを検索して選択します。
[アクセス制御] で [許可] を選択します。 [アクセス権の付与]>[デバイスは準拠としてマーク済みである必要があります] の順に選択します。
[ポリシーの有効化] で、[オン]>[作成] の順に選択します。

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

kubectl get nodes

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

Azure portal で、[Microsoft Entra ID] に移動します。
[エンタープライズアプリケーション] を選択します。次に、[アクティビティ] で [サインイン] を選択します。
上部のエントリは、[状態] が [失敗]、[条件付きアクセス] が [成功] になっています。このエントリを選択し、[詳細] で [条件付きアクセス] を選択します。条件付きアクセスポリシーが表示されます。

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 アクセス要求を構成するには、次の手順を行います。

Azure portal の上部で、Microsoft Entra ID を検索して選択します。
テナント ID を書き留めておきます。この手順の残りの部分では、この ID を <tenant-id> と表記しています。
左側の Microsoft Entra ID のメニューの [管理] で、[グループ]>[新しいグループ] の順に選択します。
[グループの種類] で [セキュリティ] が選択されていることを確認します。グループ名 (例: myJITGroup) を入力します。 [グループにMicrosoft Entra ロールを割り当てることができる (プレビュー)] で [はい] を選択します。最後に、 [作成] を選択します。
[グループ] ページに戻ります。新しく作成したグループを選択し、オブジェクト ID を書き留めておきます。この手順の残りの部分では、この ID を <object-id> と表記しています。
Azure portal に戻り、左側の [アクティビティ] のメニューで、[特権アクセス (プレビュー)] を選択します。次に、[特権アクセスの有効化] を選択します。
[割り当ての追加] を選択して、アクセス権の付与を開始します。
[メンバー] ロールを選択し、クラスターへのアクセス権を付与するユーザーとグループを選択します。グループ管理者は、これらの割り当てをいつでも変更できます。先に進む準備ができたら、[次へ] を選択します。
割り当ての種類として [アクティブ] を選択し、目的の期間を選択して、理由を入力します。続行する準備ができたら、[割り当て] を選択します。割り当ての種類の詳細については、「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 のアーキテクチャについて理解する。

次の方法で共有

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

前提条件

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

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

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

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

組み込みのロール

カスタムロール

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

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

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

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

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

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

次のステップ

フィードバック

その他のリソース

次の方法で共有

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

前提条件

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

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

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

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

組み込みのロール

カスタム ロール

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

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

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

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

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

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

次のステップ

フィードバック

その他のリソース

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

カスタムロール

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