Azure Kubernetes Service で Microsoft Entra ID と共に Kubernetes のロールベースのアクセス制御を使う

[アーティクル]
10/27/2023

Azure Kubernetes Service (AKS) は、ユーザー認証に Microsoft Entra ID を使うように構成することができます。この構成では、Microsoft Entra 認証トークンを使って AKS クラスターにサインインします。認証されると、ユーザーの ID またはグループメンバーシップに基づいて、名前空間やクラスターリソースへのアクセスを管理するために、組み込みの Kubernetes のロールベースのアクセス制御 (Kubernetes RBAC) を使用できます。

この記事で取り上げるテクニック:

AKS クラスターで Kubernetes RBAC を使い、Microsoft Entra グループのメンバーシップに基づいてアクセスを制御します。
Microsoft Entra ID でグループとユーザーの例を作成します。
AKS クラスターで Role と RoleBinding を作成して、リソースの作成と表示のための適切なアクセス許可を付与します。

開始する前に

Microsoft Entra 統合が有効になっている既存の AKS クラスターがあります。この構成の AKS クラスターが必要な場合は、Microsoft Entra ID と AKS の統合に関する記事を参照してください。
Kubernetes RBAC は、AKS クラスターの作成時に既定で有効になります。 Microsoft Entra 統合と Kubernetes RBAC を使ってクラスターをアップグレードするには、既存の AKS クラスターで Microsoft Entra 統合を有効にします。
Azure CLI バージョン 2.0.61 以降がインストールされ、構成されていることを確認します。バージョンを確認するには、az --version を実行します。インストールまたはアップグレードする必要がある場合は、Azure CLI のインストールに関するページを参照してください。
Terraform を使用している場合は、Terraform バージョン 2.99.0 以降をインストールします。

Azure portal または Azure CLI を使って、Microsoft Entra と Kubernetes RBAC の統合が有効かどうかを確認します。

Azure Portal
Azure CLI

Azure portal を使用して確認するには:

ブラウザーから Azure portal にサインインします。
Kubernetes サービスに移動し、左側のウィンドウから [クラスターの構成] を選択します。
[認証と認可] セクションで、[Kubernetes RBAC を使用した Microsoft Entra Authentication] オプションが選択されていることを確認します。

Azure CLI の az aks show コマンドを使用して確認できます。値 "myResourceGroup" を AKS クラスターリソースをホストしているリソースグループ名に置き換え、"myAKSCluster" を AKS クラスターの実際の名前に置き換えます。

az aks show --resource-group myResourceGroup --name myAKSCluster

有効な場合、enableAzureRbac の値が false であるという出力が表示されます。

Microsoft Entra ID でデモグループを作成する

この記事では、Kubernetes RBAC と Microsoft Entra ID がクラスターリソースへのアクセスを制御する方法を示すために、2 つのユーザーロールを作成します。次の 2 つのロールの例が使用されます。

アプリケーション開発者
- appdev グループの一員である aksdev という名前のユーザー。
Site Reliability Engineer
- opssre グループの一員である akssre という名前のユーザー。

運用環境では、Microsoft Entra テナント内の既存のユーザーとグループを使用できます。

最初に、az aks show コマンドを使用して AKS クラスターのリソース ID を取得します。次に、他のコマンドで参照できるように、リソース ID を AKS_ID という名前の変数に割り当てます。
```
AKS_ID=$(az aks show \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --query id -o tsv)
```
az ad group create コマンドを使って、Microsoft Entra ID でアプリケーション開発者の最初のグループ例を作成します。次の例では、appdev という名前のグループを作成します。
```
APPDEV_ID=$(az ad group create --display-name appdev --mail-nickname appdev --query id -o tsv)
```
コマンドを使って、appdevaz role assignment create グループに Azure ロール割り当てを作成します。この割り当てにより、"Azure Kubernetes Service クラスターユーザー" ロールを付与することで、グループの任意のメンバーが kubectl を使って AKS クラスターとやり取りできるようになります。
```
az role assignment create \
  --assignee $APPDEV_ID \
  --role "Azure Kubernetes Service Cluster User Role" \
  --scope $AKS_ID
```

ヒント

Principal 35bfec9328bd4d8d9b54dea6dac57b82 doesn't exist in the directory a5443dcd-cd0e-494d-a387-3039b419f0d5. などのエラーが発生した場合は、Microsoft Entra グループオブジェクト ID がディレクトリ全体に伝達されるまで数秒待ってから、az role assignment create コマンドをもう一度試します。

opssre という名前の SRE 用に 2 つ目のグループ例を作成します。

OPSSRE_ID=$(az ad group create --display-name opssre --mail-nickname opssre --query id -o tsv)

グループのメンバーに "Azure Kubernetes Service クラスターユーザー" ロールを付与するための Azure ロール割り当てを作成します。
```
az role assignment create \
  --assignee $OPSSRE_ID \
  --role "Azure Kubernetes Service Cluster User Role" \
  --scope $AKS_ID
```

Microsoft Entra ID でデモユーザーを作成する

Microsoft Entra ID にアプリケーション開発者と SRE 用のグループ例を 2 つ作成したので、次は 2 つのユーザー例を作成します。この記事の最後で Kubernetes RBAC 統合をテストするには、これらのアカウントを使って AKS クラスターにサインインします。

アプリケーション開発者のユーザープリンシパル名とパスワードを設定する

アプリケーション開発者のユーザープリンシパル名 (UPN) とパスワードを設定します。 UPN には、テナントの検証済みドメイン名を含める必要があります。たとえば、aksdev@contoso.com のようになります。

次のコマンドを実行すると、UPN の入力が求められるので、AAD_DEV_UPN に設定し、後のコマンドで使用できるようにします。

echo "Please enter the UPN for application developers: " && read AAD_DEV_UPN

次のコマンドを実行すると、パスワードの入力を求められるので、AAD_DEV_PW に設定して、後のコマンドで使用できるようにします。

echo "Please enter the secure password for application developers: " && read AAD_DEV_PW

ユーザーアカウントを作成する

az ad user create コマンドを使って Microsoft Entra ID で最初のユーザーアカウントを作成します。次の例では、AAD_DEV_UPN と AAD_DEV_PW の値を使用して、表示名 AKS Dev と UPN とセキュリティで保護されたパスワードを持つユーザーを作成します。

AKSDEV_ID=$(az ad user create \
  --display-name "AKS Dev" \
  --user-principal-name $AAD_DEV_UPN \
  --password $AAD_DEV_PW \
  --query id -o tsv)

コマンドを使って、前のセクションで作成した appdevaz ad group member add グループにユーザーを追加します。

az ad group member add --group appdev --member-id $AKSDEV_ID

SRE の UPN とパスワードを設定します。 UPN には、テナントの検証済みドメイン名を含める必要があります。たとえば、akssre@contoso.com のようになります。次のコマンドを実行すると、UPN の入力を求められるので、AAD_SRE_UPN に設定して、後のコマンドで使用できるようにします。

echo "Please enter the UPN for SREs: " && read AAD_SRE_UPN

次のコマンドを実行すると、パスワードの入力を求められるので、AAD_SRE_PW に設定して、後のコマンドで使用できるようにします。

echo "Please enter the secure password for SREs: " && read AAD_SRE_PW

2 つ目のユーザーアカウントを作成します。次の例では、AAD_SRE_UPN と AAD_SRE_PW の値を使用して、表示名 AKS SRE と UPN とセキュリティで保護されたパスワードを持つユーザーを作成します。

# Create a user for the SRE role
AKSSRE_ID=$(az ad user create \
  --display-name "AKS SRE" \
  --user-principal-name $AAD_SRE_UPN \
  --password $AAD_SRE_PW \
  --query id -o tsv)

# Add the user to the opssre Azure AD group
az ad group member add --group opssre --member-id $AKSSRE_ID

アプリ開発者向けに AKS クラスターリソースを作成する

Microsoft Entra のグループ、ユーザー、Azure ロールの割り当てを作成しました。次は、これらの異なるグループに特定のリソースへのアクセスを許可するように AKS クラスターを構成します。

az aks get-credentials コマンドを使って、クラスター管理者の資格情報を取得します。次のセクションのいずれかで、通常の user クラスターの資格情報を取得して、Microsoft Entra 認証のフローの動作を確認します。

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin

kubectl create namespace コマンドを使用して、AKS クラスター内に名前空間を作成します。次の例では、dev という名前空間の名前を作成します。

kubectl create namespace dev

Note

Kubernetes では、Role によって付与するアクセス許可が定義され、RoleBinding によってそれらが目的のユーザーまたはグループに適用されます。これらの割り当ては、特定の名前空間に適用することも、クラスター全体に適用することもできます。詳細については、Kubernetes RBAC 認可の使用に関するページを参照してください。

Kubernetes RBAC のバインドの付与先となるユーザーが同じ Microsoft Entra テナントに存在する場合は、userPrincipalName (UPN) に基づいてアクセス許可を割り当てます。ユーザーが別の Microsoft Entra テナント内にいる場合、代わりに objectId プロパティに対してクエリを実行して使います。

dev 名前空間の Role を作成し、この名前空間に対する完全なアクセス許可を付与します。運用環境では、さまざまなユーザーまたはグループに対してより細かくアクセス許可を指定できます。 role-dev-namespace.yaml という名前のファイルを作成し、次の YAML マニフェストを貼り付けます。

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dev-user-full-access
  namespace: dev
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]

kubectl apply コマンドを使って Role を作成し、YAML マニフェストのファイル名を指定します。

kubectl apply -f role-dev-namespace.yaml

az ad group show コマンドを使って、appdev グループのリソース ID を取得します。このグループは、次の手順で RoleBinding のサブジェクトとして設定されます。

az ad group show --group appdev --query id -o tsv

appdev グループの RoleBinding を作成し、名前空間のアクセスのために先ほど作成した Role を使います。 rolebinding-dev-namespace.yaml という名前のファイルを作成し、次の YAML マニフェストを貼り付けます。最後の行の groupObjectId を、前のコマンドで出力されたグループオブジェクト ID に置き換えます。

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dev-user-access
  namespace: dev
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: dev-user-full-access
subjects:
- kind: Group
  namespace: dev
  name: groupObjectId

ヒント

1 人のユーザーに対して RoleBinding を作成するには、上記のサンプルで kind: User を指定し、groupObjectId をユーザープリンシパル名 (UPN) に置き換えます。

kubectl apply コマンドを使用して RoleBinding を作成し、YAML マニフェストのファイル名を指定します。

kubectl apply -f rolebinding-dev-namespace.yaml

SRE 向けに AKS クラスターリソースを作成する

次に、前の手順を繰り返して、SRE の名前空間、Role、RoleBinding を作成します。

kubectl create namespace コマンドを使って sre の名前空間を作成します。

kubectl create namespace sre

role-sre-namespace.yaml という名前のファイルを作成し、次の YAML マニフェストを貼り付けます。

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sre-user-full-access
  namespace: sre
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]

kubectl apply コマンドを使って Role を作成し、YAML マニフェストのファイル名を指定します。

kubectl apply -f role-sre-namespace.yaml

az ad group show コマンドを使って、opssre グループのリソース ID を取得します。

az ad group show --group opssre --query id -o tsv

名前空間にアクセスするために以前に作成した Role を使用するため、opssre グループの RoleBinding を作成します。 rolebinding-sre-namespace.yaml という名前のファイルを作成し、次の YAML マニフェストを貼り付けます。最後の行の groupObjectId を、前のコマンドで出力されたグループオブジェクト ID に置き換えます。

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sre-user-access
  namespace: sre
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: sre-user-full-access
subjects:
- kind: Group
  namespace: sre
  name: groupObjectId

kubectl apply コマンドを使って RoleBinding を作成し、YAML マニフェストのファイル名を指定します。

kubectl apply -f rolebinding-sre-namespace.yaml

Microsoft Entra ID を使ってクラスターリソースを操作する

次は、AKS クラスター内でリソースを作成して管理する際に予想されるアクセス許可の動作をテストします。これらの例では、ユーザーに割り当てられた名前空間内のポッドをスケジュールし、表示します。また、割り当てられた名前空間以外のポッドをスケジュールし、表示してみます。

コマンドを使って kubeconfigaz aks get-credentials コンテキストをリセットします。前のセクションで、クラスター管理者資格情報を使用してコンテキストを設定します。管理者ユーザーは、Microsoft Entra サインインプロンプトをバイパスします。 --admin パラメーターがないと、ユーザーコンテキストが適用され、すべての要求を Microsoft Entra ID を使って認証する必要があります。

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing

kubectl rundev 名前空間でコマンドを使って基本的な NGINX ポッドをスケジュールします。

kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev

サインインを求められたら、この記事で最初に作成した自分の appdev@contoso.com アカウントの資格情報を入力します。正常にサインインすると、今後の kubectl コマンドのためにアカウントトークンがキャッシュされます。次の出力例に示すように、NGINX は正常にスケジュール設定されました。

$ kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev

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

pod/nginx-dev created

kubectl get pods コマンドを使って dev 名前空間のポッドを表示します。

kubectl get pods --namespace dev

NGINX ポッドの状態が "実行中" であることを確認します。この出力は次の出力のようになります。

$ kubectl get pods --namespace dev

NAME        READY   STATUS    RESTARTS   AGE
nginx-dev   1/1     Running   0          4m

割り当てられた名前空間の外側でクラスターリソースを作成して表示する

dev 名前空間以外のポッドを表示してみましょう。もう一度 kubectl get pods コマンドを使います。今回は --all-namespaces と表示されます。

kubectl get pods --all-namespaces

次の出力例に示されているように、ユーザーのグループメンバーシップには、このアクションを許可する Kubernetes Role がありません。

Error from server (Forbidden): pods is forbidden: User "aksdev@contoso.com" cannot list resource "pods" in API group "" at the cluster scope

同様に、別の名前空間 (sre 名前空間など) でポッドをスケジュール設定してみましょう。次の出力例に示されているように、ユーザーのグループメンバーシップが、これらのアクセス許可を付与する Kubernetes Role と RoleBinding と一致しません。

$ kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre

Error from server (Forbidden): pods is forbidden: User "aksdev@contoso.com" cannot create resource "pods" in API group "" in the namespace "sre"

AKS クラスターリソースへの SRE のアクセスをテストする

Microsoft Entra グループメンバーシップと Kubernetes RBAC が異なるユーザーとグループ間で正しく機能することを確認するには、opssre ユーザーとしてサインインしたときに、前のコマンドを試してみます。

以前にキャッシュした aksdev ユーザーの認証トークンをクリアする az aks get-credentials コマンドを使って、kubeconfig コンテキストをリセットします。

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing

割り当てられた sre 名前空間でポッドをスケジュール設定して表示してみます。入力を求められたら、この記事の冒頭で作成した自分の opssre@contoso.com 資格情報を使ってサインインします。

kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre
kubectl get pods --namespace sre

次の出力例に示すように、ポッドを正常に作成して表示できます。

$ kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre

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

pod/nginx-sre created

$ kubectl get pods --namespace sre

NAME        READY   STATUS    RESTARTS   AGE
nginx-sre   1/1     Running   0

割り当てられた SRE 名前空間以外のポッドを表示したり、スケジュールしたりしてみましょう。

kubectl get pods --all-namespaces
kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev

次の出力例に示すように、これらの kubectl コマンドは失敗します。ユーザーのグループメンバーシップ、Kubernetes の Role と RoleBinding では、他の名前空間内でリソースを作成または管理するためのアクセス許可が付与されません。

$ kubectl get pods --all-namespaces
Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot list pods at the cluster scope

$ kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot create pods in the namespace "dev"

リソースをクリーンアップする

この記事では、AKS クラスター内にリソースを作成し、Microsoft Entra ID でユーザーとグループを作成しました。すべてのリソースをクリーンするには、次のコマンドを実行します。

# Get the admin kubeconfig context to delete the necessary cluster resources.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin

# Delete the dev and sre namespaces. This also deletes the pods, Roles, and RoleBindings.

kubectl delete namespace dev
kubectl delete namespace sre

# Delete the Azure AD user accounts for aksdev and akssre.

az ad user delete --upn-or-object-id $AKSDEV_ID
az ad user delete --upn-or-object-id $AKSSRE_ID

# Delete the Azure AD groups for appdev and opssre. This also deletes the Azure role assignments.

az ad group delete --group appdev
az ad group delete --group opssre

次の手順

Kubernetes クラスターをセキュリティで保護する方法について詳しくは、「Azure Kubernetes Service (AKS) でのアクセスと ID オプション」をご覧ください。
ID とリソース管理に関するベストプラクティスについては、AKS での認証と承認のベストプラクティスに関するページを参照してください。

Azure Kubernetes Service で Microsoft Entra ID と共に Kubernetes のロールベースのアクセス制御を使う

開始する前に

Microsoft Entra ID でデモ グループを作成する

Microsoft Entra ID でデモ ユーザーを作成する

アプリケーション開発者のユーザー プリンシパル名とパスワードを設定する

ユーザー アカウントを作成する

アプリ開発者向けに AKS クラスター リソースを作成する

SRE 向けに AKS クラスター リソースを作成する

Microsoft Entra ID を使ってクラスター リソースを操作する

割り当てられた名前空間の外側でクラスター リソースを作成して表示する

AKS クラスター リソースへの SRE のアクセスをテストする