使用 Microsoft Entra ID 和 Kubernetes RBAC for Windows Server 來控制存取

適用於：Azure Stack HCI 22H2 上的 AKS、Windows Server 上的 AKS

Azure Kubernetes Service (AKS) 可以設定為使用 Microsoft Entra ID 進行使用者驗證。 在此設定中，您會使用 Microsoft Entra 驗證令牌登入 Kubernetes 叢集。 驗證之後，您可以使用內建的 Kubernetes 角色型存取控制 (Kubernetes RBAC)，來管理以使用者的身分識別，或群組成員資格為基礎的命名空間和叢集資源存取權。

本文說明如何根據 AKS Arc 中Microsoft Entra 群組成員資格，在 Kubernetes 叢集中使用 Kubernetes RBAC 來控制存取。您可以在 Microsoft Entra ID 中建立示範群組和使用者。 然後，您會在叢集中建立角色和角色系結，以授與建立和檢視資源的適當許可權。

必要條件

使用 Microsoft Entra 識別符設定 Kubernetes RBAC 之前，您需要下列必要條件：

• AKS Arc 中建立的 Kubernetes 叢集。如果您需要設定叢集，請參閱使用 Windows Admin Center 或 PowerShell 部署 AKS 的指示。
• Azure Arc 連線。 您必須具有與 Kubernetes 叢集的 Azure Arc 連線。 如需啟用 Azure Arc 的相關信息，請參閱 將 Azure 本機叢集上的 Azure Kubernetes Service 連線至已啟用 Azure Arc 的 Kubernetes。
• 您需要存取下列命令列工具：
  • Azure CLI 和 connectedk8s 擴充功能。 Azure CLI 是一組用來建立和管理 Azure 資源的命令。 若要檢查您是否擁有 Azure CLI，請開啟命令行工具，然後輸入： az -v。 此外，請安裝 connectedk8s 擴充功能 ，以開啟 Kubernetes 叢集的通道。 如需安裝指示，請參閱 如何安裝 Azure CLI。
  • Kubectl。 此 Kubernetes 命令行工具可讓您執行以 Kubernetes 叢集為目標的命令。 若要檢查您是否已安裝 kubectl，請開啟命令提示字元並輸入： kubectl version --client。 請確定您的 kubectl 用戶端版本至少是 v1.24.0 版。 如需安裝指示，請參閱 kubectl。
  • PowerShell 和 AksHci PowerShell 模組。 PowerShell 是跨平臺的工作自動化解決方案，其中包含命令行殼層、腳本語言和組態管理架構。 如果您已安裝 AKS Arc，則可以存取 AksHci PowerShell 模組。
  • 若要使用 命令從任何地方使用 az connectedk8s proxy Proxy 模式存取 Kubernetes 叢集，您需要 Microsoft.Kubernetes/connectedClusters/listClusterUserCredential/action，其包含在已啟用 Azure Arc 的 Kubernetes 叢集使用者角色許可權中。 同時，您必須確認執行上線程式的代理程式和計算機符合已啟用 Azure Arc 的 Kubernetes 網路需求中的 網路需求。

選擇性的第一個步驟

如果您還沒有包含成員的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 login重新連線至 Azure。

$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 角色系結

設定 AKS 叢集，以允許您的Microsoft Entra 群組存取叢集。 如果您想要新增群組和使用者，請參閱 在 Microsoft Entra 識別碼中建立示範群組。

1. 使用 Get-AksHciCredential 命令取得叢集管理員認證：

   Get-AksHciCredential -name <name-of-your-cluster>
   

2. 使用 kubectl create namespace 命令在 Kubernetes 叢集中建立命名空間。 下列範例會建立名為 dev 的命名空間：

   kubectl create namespace dev
   

   在 Kubernetes 中， 角色 會定義要授與的許可權，而 RoleBindings 會將許可權套用至所需的使用者或群組。 這些指派可以套用至指定的命名空間或整個叢集。 如需詳細資訊，請參閱使用 Kubernetes RBAC 授權。

   建立開發命名空間的角色。 此角色會將完整許可權授與命名空間。 在生產環境中，您可能想要為不同的使用者或群組指定更細微的許可權。

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 群組的資源識別符。 下一個步驟中，此群組會設定為 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 角色進行命名空間存取。 在最後一行，將 取代 groupObjectId 為命令所產生的 az ad group show 群組物件識別碼：

   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
   

   提示

   如果您想要為單一使用者建立 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 也提供內建的使用者面向角色。 這些內建角色包括：

• 超級使用者角色 （cluster-admin）
• 想要使用 ClusterRoleBindings 授與全叢集的角色
• 想要使用 RoleBindings 在特定命名空間內授與的角色（系統管理員、編輯、檢視）

如需內建 Kubernetes RBAC 角色的詳細資訊，請參閱 Kubernetes RBAC 使用者面向角色。

使用者面向角色

默認 ClusterRole	默認 ClusterRoleBinding	描述
cluster-admin	system：masters 群組	允許超級使用者存取，在任何資源上執行任何動作。 在 ClusterRoleBinding 中使用時，此角色可完全控制叢集中和所有命名空間中的每個資源。 在 RoleBinding 中使用時，它會完整控制角色系結命名空間中的每個資源，包括命名空間本身。
管理	無	允許系統管理員存取權，其用途是使用角色系結在命名空間內授與。 如果在角色系結中使用，允許讀取/寫入命名空間中的大部分資源，包括能夠在命名空間內建立角色和角色系結的功能。 此角色不允許對資源配額或命名空間本身進行寫入存取。 此角色也不允許對使用 Kubernetes v1.22+ 所建立叢集中端點的寫入存取權。 如需詳細資訊，請參閱 端點的寫入存取權。
編輯…	無	允許命名空間中大部分物件的讀取/寫入存取權。 不允許檢視或修改角色或角色繫結。 不過，此角色允許存取秘密和執行 Pod 做為命名空間中的任何 ServiceAccount，因此可用來取得命名空間中任何 ServiceAccount 的 API 存取層級。 此角色也不允許對使用 Kubernetes v1.22+ 所建立叢集中端點的寫入存取權。 如需詳細資訊，請參閱 端點的寫入存取權。
檢視	無	允許唯讀存取來查看命名空間中的大部分物件。 其不允許檢視角色或角色繫結。 此角色不允許檢視秘密，因為讀取秘密的內容可存取命名空間中的 ServiceAccount 認證，這會允許 API 存取作為命名空間中的任何 ServiceAccount（許可權提升形式）。

使用內建 Kubernetes RBAC 角色搭配 Microsoft Entra 識別碼

若要搭配使用內建 Kubernetes RBAC 角色搭配 Microsoft Entra ID，請遵循下列步驟：

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 識別符來處理叢集資源

現在，當您在 Kubernetes 叢集中建立和管理資源時，請測試預期的許可權。 在這些範例中，您會在使用者指派的命名空間中排程和檢視 Pod。 然後，您嘗試排程和檢視指派命名空間以外的 Pod。

1. 使用 $AKSDEV_ID 您指定做為命令輸入的 az ad group member add 用戶帳戶登入 Azure。 az connectedk8s proxy執行 命令以開啟叢集的通道：

   az connectedk8s proxy -n <cluster-name> -g <resource-group>
   

2. 建立 Proxy 通道之後，請開啟另一個工作階段，並使用kubectl run開發命名空間中的 命令排程 NGINX Pod：

   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 Pod：

   kubectl get pods --namespace dev
   

   當 NGINX 成功執行時，您應該會看到下列輸出：

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

在指派的命名空間之外建立和檢視叢集資源

若要嘗試檢視開發命名空間外部的 Pod，請使用 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

下一步

• 深入瞭解 Windows Server 上 AKS Arc 的安全性