Microsoft Entra ID と Kubernetes RBAC を使用してアクセスを制御する
適用対象: AKS on Azure Stack HCI 23H2
ユーザー認証に Microsoft Entra ID を使用するように Azure Kubernetes Service (AKS) を構成できます。 この構成では、Microsoft Entra 認証トークンを使用して Kubernetes クラスターにサインインします。 認証されると、ユーザーの ID またはグループ メンバーシップに基づいて、名前空間やクラスター リソースへのアクセスを管理するために、組み込みの Kubernetes のロールベースのアクセス制御 (Kubernetes RBAC) を使用できます。
この記事では、AKS の Microsoft Entra グループ メンバーシップに基づいて、Kubernetes クラスターで Kubernetes RBAC を使用してアクセスを制御する方法について説明します。 Microsoft Entra ID でデモ グループとユーザーを作成します。 次に、リソースを作成して表示するための適切なアクセス許可を付与するために、クラスターにロールとロール バインドを作成します。
前提条件
Microsoft Entra ID を使用して Kubernetes RBAC を設定する前に、次の前提条件が必要です。
Azure Arc クラスターによって有効になっている AKS。 クラスターを設定する必要がある場合は、Azure portal または Azure CLI を使用する手順を参照してください。
Azure CLI をインストールして構成する必要があります。 インストールまたはアップグレードする必要がある場合は、Azure CLI のインストールに関するページを参照してください。
最新バージョンの Azure CLI 拡張機能を
aksarc
connectedk8s
インストールします。az extension add --name aksarc az extension add --name connectedk8s
拡張機能を既に
aksarc
インストールしている場合は、拡張機能を最新バージョンに更新します。az extension update --name aksarc az extension update --name connectedk8s
Kubectl。 Kubernetes コマンド ライン ツール kubectl を使用すると、Kubernetes クラスターを対象とするコマンドを実行できます。 kubectl をインストールしたかどうかを確認するには、コマンド プロンプトを開き、「.」と入力します
kubectl version --client
。 kubectl クライアントのバージョンが 少なくともv1.24.0
以上であることを確認します。 インストール手順については、kubectl を参照してください。
最初のステップ (省略可能)
メンバーを含む Microsoft Entra グループがまだない場合は、グループを作成し、いくつかのメンバーを追加して、この記事の手順に従うことができます。
Microsoft Entra ID と Kubernetes RBAC の操作を示すために、Kubernetes RBAC と Microsoft Entra ID がクラスター リソースへのアクセスを制御する方法を示すために使用できるアプリケーション開発者向けの Microsoft Entra グループを作成できます。 運用環境では、Microsoft Entra テナント内の既存のユーザーとグループを使用できます。
Microsoft Entra ID でデモ グループを作成する
まず、コマンドを使用して、アプリケーション開発者向けにテナント内に Microsoft Entra ID でグループを az ad group create
作成します。 次の例では、Azure テナントにサインインし、appdev という名前のグループを作成するように求められます。
az login
az ad group create --display-name appdev --mail-nickname appdev
グループにユーザーを追加する
アプリケーション開発者向けに Microsoft Entra ID で作成されたグループの例を使用して、グループにユーザーを appdev
追加します。 このユーザー アカウントを使用して AKS クラスターにサインインし、Kubernetes RBAC 統合をテストします。
コマンドを使用して、前の セクションで作成した appdev グループにユーザーを az ad group member add
追加します。 セッションを終了する場合は、az login
$AKSDEV_ID = az ad user create --display-name <name> --password <strongpassword> --user-principal-name <name>@contoso.onmicrosoft.com
az ad group member add --group appdev --member-id $AKSDEV_ID
Microsoft Entra グループの AKS クラスター リソースにカスタム Kubernetes RBAC ロール バインドを作成する
Microsoft Entra グループがクラスターにアクセスできるように AKS クラスターを構成します。 グループとユーザーを追加する場合は、「Microsoft Entra ID でデモ グループを作成する」を参照してください。
次のコマンドを
az aksarc get-credentials
使用して、クラスター管理者の資格情報を取得します。az aksarc get-credentials --name "sample-aksarccluster" --resource-group "sample-rg" --admin
コマンドを使用して、Kubernetes クラスターに名前空間を
kubectl create namespace
作成します。 次の例では、dev
という名前空間を作成します。kubectl create namespace dev
Kubernetes では、Role によって付与するアクセス許可が定義され、RoleBinding によってアクセス許可が目的のユーザーまたはグループに適用されます。 これらの割り当ては、特定の名前空間またはクラスター全体に適用できます。 詳細については、Kubernetes RBAC 認可の使用に関するページを参照してください。
開発名前空間のロールを作成します。 このロールにより名前空間に完全なアクセス許可が付与されます。 運用環境では、さまざまなユーザーまたはグループに対してより細かいアクセス許可を指定できます。
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
作成し、YAML マニフェストのファイル名を指定します。kubectl apply -f role-dev-namespace.yaml
az ad group show
コマンドを使って、appdev グループのリソース ID を取得します。 このグループは、次の手順で RoleBinding の件名として設定されます。az ad group show --group appdev --query objectId -o tsv
このコマンドは
az ad group show
、次のようにgroupObjectId
使用する値を返します。38E5FA30-XXXX-4895-9A00-050712E3673A
rolebinding-dev-namespace.yaml という名前のファイルを作成し、次の YAML マニフェストをコピー/貼り付けます。 appdev グループが名前空間アクセスにロールを使用できるようにするロール バインドを
role-dev-namespace
確立します。 最後の行のgroupObjectId
を、az ad group show
コマンドから返されたグループ オブジェクト 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 を 作成する場合は、この例のユーザー プリンシパル名 (UPN) を指定
kind: User
して置き換えますgroupObjectId
。コマンドを使用して
kubectl apply
RoleBinding を作成し、YAML マニフェストのファイル名を指定します。kubectl apply -f rolebinding-dev-namespace.yaml
rolebinding.rbac.authorization.k8s.io/dev-user-access created
AKS クラスター リソースに Kubernetes RBAC の組み込みロールを使用する
Kubernetes には、組み込みのユーザー向けロールも用意されています。 次のような組み込みロールがあります。
- スーパー ユーザー ロール (クラスター管理者)
- ClusterRoleBinding を使ってクラスター全体に付与されることを目的としたロール
- RoleBinding を使って特定の名前空間内で付与されることを目的としたロール(管理、編集、表示)
組み込みの Kubernetes RBAC ロールの詳細については、「Kubernetes RBAC のユーザー向けロール」を参照してください。
ユーザー向けロール
既定の ClusterRole | 既定の ClusterRoleBinding | 説明 |
---|---|---|
cluster-admin | system:masters グループ | スーパー ユーザーアクセスを許可し、任意のリソースに対して任意のアクションを実行できます。 ClusterRoleBinding で使用すると、このロールによって、クラスター内のすべてのリソースとすべての名前空間を完全に制御できます。 RoleBinding で使うと、ロール バインドの名前空間内のすべてのリソース (名前空間自体を含む) を完全に制御できます。 |
admin | なし | ロール バインディングを使用して名前空間内で付与することを目的とした管理者アクセスを許可します。 ロール バインドで使用する場合は、名前空間内でロールとロール バインドを作成する機能など、名前空間内のほとんどのリソースへの読み取り/書き込みアクセスを許可します。 このロールでは、リソース クォータまたは名前空間自体への書き込みアクセスは許可されません。 このロールでは、Kubernetes v1.22 以降を使用して作成されたクラスター内のエンドポイントへの書き込みアクセスも許可されません。 詳細については、「エンドポイントの書き込みアクセス」を参照してください。 |
edit | なし | 名前空間内のほとんどのオブジェクトに対する読み取りと書き込みのアクセスが許可されます。 このロールでは、ロールまたはロールのバインドを表示または変更することはできません。 ただし、このロールを使用すると、名前空間内の任意の ServiceAccount としてシークレットにアクセスし、ポッドを実行できるため、名前空間内の任意の ServiceAccount の API アクセス レベルを取得するために使用できます。 このロールでは、Kubernetes v1.22 以降を使用して作成されたクラスター内のエンドポイントへの書き込みアクセスも許可されません。 詳細については、「エンドポイントの書き込みアクセス」を参照してください。 |
ビュー | なし | 名前空間内のほとんどのオブジェクトを表示するための読み取り専用アクセスが許可されます。 ロールまたはロールのバインドを表示することはできません。 シークレットの内容を読み取ると名前空間の ServiceAccount 資格情報にアクセスできるため、このロールではシークレットの表示は許可されません。これにより、名前空間内の任意の ServiceAccount (特権エスカレーションの形式) としての API アクセスが許可されます。 |
Microsoft Entra ID で組み込みの Kubernetes RBAC ロールを使用する
Microsoft Entra ID で組み込みの Kubernetes RBAC ロールを使用するには、次の手順に従います。
組み込みの
view
Kubernetes RBAC ロールを Microsoft Entra グループに適用します。kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --group=<Azure AD group object ID>
組み込みの
view
Kubernetes RBAC ロールを各 Microsoft Entra ユーザーに適用します。kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --user=<Azure AD user object ID>
Microsoft Entra ID を使用してクラスター リソースを操作する
次に、Kubernetes クラスターでリソースを作成および管理するときに、予想されるアクセス許可をテストします。 これらの例では、ユーザーの割り当てられた名前空間内でポッドをスケジュール設定して表示します。 次に、割り当てられた名前空間の外部にあるポッドをスケジュールして表示しようとします。
コマンドへの入力として渡したユーザー アカウントを使用して
$AKSDEV_ID
、Azure にaz ad group member add
サインインします。 コマンドをaz connectedk8s proxy
実行して、クラスターへのチャネルを開きます。az connectedk8s proxy --name "sample-aksarccluster" --resource-group "sample-rg"
プロキシ チャネルが確立されたら、別のセッションを開き、開発名前空間のコマンドを
kubectl run
使用して NGINX ポッドをスケジュールします。kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
NGINX が正常にスケジュールされると、次の出力が表示されます。
pod/nginx-dev created
次に、コマンドを
kubectl get pods
使用して名前空間内のポッドをdev
表示します。kubectl get pods --namespace dev
NGINX が正常に実行されると、次の出力が表示されます。
NAME READY STATUS RESTARTS AGE nginx-dev 1/1 Running 0 4m
割り当てられた名前空間の外部でクラスター リソースを作成して表示する
開発名前空間の外部にあるポッドを表示するには、次のフラグを指定してkubectl get pods
コマンドを--all-namespaces
使用します。
kubectl get pods --all-namespaces
ユーザーのグループ メンバーシップには、このアクションを許可する Kubernetes ロールがありません。 アクセス許可がないと、次のエラーが生成されます。
Error from server (Forbidden): pods is forbidden: User cannot list resource "pods" in API group "" at the cluster scope
次のステップ
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示