Azure Arc で有効になっている AKS のMicrosoft Entra IDと Kubernetes RBAC を使用してアクセスを制御する

適用対象: AKS on Azure Stack HCI 22H2、AKS on Windows Server

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

この記事では、AKS Arc のグループ メンバーシップに基づいて、Kubernetes クラスターで Kubernetes RBAC を使用してアクセスMicrosoft Entra制御する方法について説明します。Microsoft Entra IDでデモ グループとユーザーを作成します。 次に、クラスターにロールとロール バインドを作成して、リソースを作成および表示するための適切なアクセス許可を付与します。

前提条件

Microsoft Entra ID を使用して Kubernetes RBAC を設定する前に、次のものが必要です。

  • AKS Arc で作成された Kubernetes クラスター

    AKS Arc で作成された Kubernetes クラスターが必要です。クラスターを設定する必要がある場合は、Windows Admin Centerまたは PowerShell を使用して AKS をデプロイする手順を確認できます。

  • Azure Arc の接続

    Kubernetes クラスターへの Azure Arc 接続が必要です。 Azure Arc を有効にする方法については、「Azure Stack HCI クラスター上のAzure Kubernetes Serviceを Azure Arc 対応 Kubernetes に接続する」を参照してください。

  • 次のコマンド ライン ツールにアクセスする必要があります。

    • Azure CLI と connectedk8s 拡張機能

      Azure コマンド ライン インターフェイス (Azure CLI) は、Azure リソースを作成および管理するためのコマンド セットです。 Azure CLI があるかどうかをチェックするには、コマンド ライン ツールを開き、「」と入力しますaz -v。 また、Kubernetes クラスターへのチャネルを開くには、 connectedk8s 拡張機能 をインストールする必要があります。

      インストールの方法については、「Azure CLI をインストールする方法」をご覧ください。

    • kubectl

      Kubernetes のコマンド ライン ツールである kubectl を使うと、Kubernetes クラスターを対象にしてコマンドを実行できます。 kubectl がインストールされているかどうかをチェックするには、コマンド ライン ツールを開き、「」と入力しますkubectl version --client。 kubectl クライアントのバージョンが 少なくともv1.24.0 以上であることを確認します。

      インストール手順については、 kubectl を参照してください。

    • PowerShell と AksHci PowerShell モジュール

      PowerShell は、コマンドライン シェル、スクリプト言語、および構成管理フレームワークで構成されるクロスプラットフォームのタスク自動化ソリューションです。 AKS Arc をインストールしている場合は、AksHci PowerShell モジュールにアクセスできます。

最初のステップ (省略可能)

メンバーを含むMicrosoft Entra グループがまだない場合は、グループを作成してメンバーを追加して、この記事の手順に従うことができます。

Microsoft Entra IDと Kubernetes RBAC の操作を示すために、アプリケーション開発者向けにMicrosoft Entra グループを作成し、Kubernetes RBAC を使用してクラスター リソースへのアクセスMicrosoft Entra ID制御する方法を示すことができます。 運用環境では、Microsoft Entra テナント内の既存のユーザーとグループを使用できます。

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

まず、az ad group create コマンドを使用して、アプリケーション開発者向けにテナントの Microsoft Entra ID にグループを作成します。 次の例では、Azure テナントにサインインして、appdev という名前のグループを作成します。

az login
az ad group create --display-name appdev --mail-nickname appdev

グループにユーザーを追加する

アプリケーション開発者向けに Microsoft Entra ID で作成したグループの例を使用して、グループにユーザーをappdev追加しましょう。 このユーザー アカウントを使用して AKS クラスターにサインインし、Kubernetes RBAC 統合をテストします。

az ad group member add コマンドを使って、前のセクションで作成した appdev グループにユーザーを追加します。 セッションを終了する場合は、 を使用して az loginAzure に再接続します。

$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でデモ グループを作成する」を参照してください。

  1. Get-AksHciCredential コマンドを使用してクラスター管理者の資格情報を取得します。

    Get-AksHciCredential -name <name-of-your-cluster>
    
  2. kubectl create namespace コマンドを使用して、Kubernetes クラスターに 名前空間を作成 します。 次の例では、 という名前 devの名前空間を作成します。

    kubectl create namespace dev
    

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

    dev 名前空間のロールを作成します。 このロールにより名前空間に完全なアクセス許可が付与されます。 運用環境では、さまざまなユーザーまたはグループに対してより詳細なアクセス許可を指定する必要がある場合があります。

  3. 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: ["*"]
    
  4. kubectl apply コマンドを使用してロールを作成し、YAML マニフェストのファイル名を指定します。

    kubectl apply -f role-dev-namespace.yaml
    
  5. 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
    
  6. rolebinding-dev-namespace.yaml という名前のファイルを作成し、次の YAML マニフェストに貼り付けます。 appdev グループが名前空間アクセスにロールを使用できるようにするロール バインドをrole-dev-namespace確立しています。 最後の行で、 を コマンドによって生成されたグループ オブジェクト ID にaz ad group show置き換えますgroupObjectId

    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) に置き換えます。

  7. 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 以降を使用して作成されたクラスター内のエンドポイントへの書き込みアクセスも許可されません。 詳細については、「 エンドポイントの書き込みアクセス」を参照してください。
編集 なし 名前空間内のほとんどのオブジェクトに対する読み取りと書き込みのアクセスが許可されます。 このロールでは、ロールまたはロールのバインドを表示または変更することはできません。 ただし、このロールを使用すると、名前空間内の任意の ServiceAccount としてシークレットにアクセスし、ポッドを実行できるため、名前空間内の任意の ServiceAccount の API アクセス レベルを取得するために使用できます。 このロールでは、Kubernetes v1.22 以降を使用して作成されたクラスター内のエンドポイントへの書き込みアクセスも許可されません。 詳細については、「 エンドポイントの書き込みアクセス」を参照してください。
view なし 名前空間内のほとんどのオブジェクトを表示するための読み取り専用アクセスが許可されます。 ロールまたはロールのバインドを表示することはできません。 シークレットの内容を読み取ると名前空間内の ServiceAccount 資格情報にアクセスできるため、このロールではシークレットの表示は許可されません。これにより、名前空間内の任意の ServiceAccount として API アクセスが可能になります (特権エスカレーションの形式)。

Microsoft Entra IDで組み込みの Kubernetes RBAC ロールを使用する

Microsoft Entra IDで組み込みの Kubernetes RBAC ロールを使用するには、次の手順を実行します。

  1. 組み込みの view Kubernetes RBAC ロールをMicrosoft Entra グループに適用します。

    kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --group=<Azure AD group object ID>
    
  2. 組み込みの 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 クラスターでリソースを作成および管理するときに、必要なアクセス許可をテストします。 これらの例では、ユーザーの割り当てられた名前空間内でポッドをスケジュール設定して表示します。 次に、割り当てられた名前空間の外部にあるポッドをスケジュールして表示しようとします。

  1. コマンドへの入力として渡したユーザー アカウントを使用して $AKSDEV_ID 、Azure に az ad group member add サインインします。 コマンドを az connectedk8s proxy 実行して、クラスターへのチャネルを開きます。

    az connectedk8s proxy -n <cluster-name> -g <resource-group>
    
  2. プロキシ チャネルが確立されたら、別のセッションを開き、dev 名前空間の 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
    
  3. 次に、 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 ロールがありません。 アクセス許可がないので、コマンドはエラーをスローします。

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

次のステップ