在已啟用 Azure Arc 的 Kubernetes 叢集上使用 Azure RBAC

發行項
09/24/2024

Kubernetes ClusterRoleBinding 和 RoleBinding 物件類型有助於原生定義 Kubernetes 中的授權。使用這項功能，您可以使用 Microsoft Entra ID 和 Azure 中的角色指派來控制叢集上的授權檢查。 Azure 角色指派可讓您精準控制哪位使用者可以讀取、寫入和刪除 Kubernetes 物件 (例如部署、Pod 和服務)。

若需此功能的概念性概觀，請參閱已啟用 Azure Arc 的 Kubernetes 上的 Azure RBAC。

必要條件

安裝 Azure CLI 或升級至最新版本。
安裝最新版的 connectedk8s Azure CLI 延伸模組：
```
az extension add --name connectedk8s
```
如果已安裝 connectedk8s 延伸模組，您可以使用下列命令，將其更新至最新版本：
```
az extension update --name connectedk8s
```
連接已啟用 Azure Arc 的現有 Kubernetes 叢集：
- 如果您尚未連線叢集，請使用我們的快速入門。
- 將您的代理程式升級至最新版本。

注意

Azure RBAC 不適用 Red Hat OpenShift 或受控 Kubernetes 供應項目，其中的使用者對 API 伺服器的存取受到限制 (例如：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 Arc on Azure Stack HCI 23H2 所啟用的 Azure Kubernetes Service （AKS）叢集，目前只有在 Kubernetes 叢集建立期間才支援啟用 Azure RBAC。若要建立已啟用 Azure RBAC 的 Azure Arc 所啟用的 AKS 叢集，請遵循使用適用於 Kubernetes 的 Azure RBAC 授權指南。請注意，Azure Stack HCI 版本 22H2 不支援 Azure RBAC。

在叢集上啟用 Azure RBAC

執行下列命令以取得叢集 MSI 身分識別：

az connectedk8s show -g <resource-group> -n <connected-cluster-name>

從輸出取得識別碼 (identity.principalId)，然後執行下列命令，將連線叢集受控識別 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
```
注意

執行上述命令之前，請確定機器上的 kubeconfig 檔案指向您將啟用 Azure RBAC 功能的叢集。

將 --skip-azure-rbac-list 用於上述命令，可取得使用 Kubernetes 原生 ClusterRoleBinding 和 RoleBinding 物件 (而非 Azure RBAC) 來進行授權檢查的使用者名稱、電子郵件和 OpenID 連線的逗號分隔清單。

未以 `apiserver` 規格執行協調器的一般叢集

透過 SSH 連線至叢集的每個主要節點，並執行下列步驟：

如果您的 kube-apiserver 是靜態 Pod：

kube-system 命名空間中的 azure-arc-guard-manifests 秘密包含兩個檔案：guard-authn-webhook.yaml 和 guard-authz-webhook.yaml。將這些檔案複製到節點的 /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

以編輯模式開啟 apiserver 資訊清單：

sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml

在 volumes 底下新增下列規格：

- hostPath
    path: /etc/guard
    type: Directory
name: azure-rbac

在 volumeMounts 底下新增下列規格：

- mountPath: /etc/guard
    name: azure-rbac
    readOnly: true

如果您的 kube-apiserver 不是靜態 Pod：

以編輯模式開啟 apiserver 資訊清單：

sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml

在 volumes 底下新增下列規格：

- name: azure-rbac
    secret:
    secretName: azure-arc-guard-manifests

在 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 Pod。

使用叢集 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 叢集的存取權。

內建角色

角色	描述
Azure Arc Kubernetes 檢視器	允許唯讀存取來查看命名空間中的大部分物件。此角色不允許檢視秘密，因為秘密的 `read` 權限會允許存取命名空間中的 `ServiceAccount` 憑證。這些認證接著將允許透過該 `ServiceAccount` 值進行 API 存取 (一種形式的權限提升)。
Azure Arc Kubernetes 寫入器	允許命名空間中大部分物件的讀取/寫入存取權。不允許檢視或修改角色或角色繫結。然而，此角色允許以命名空間中的任何 `ServiceAccount` 值存取秘密並執行 Pod，因此可用來取得命名空間中任何 `ServiceAccount` 值的 API 存取層級。
Azure Arc Kubernetes 管理員	允許管理員存取。此存取權應透過 `RoleBinding` 在命名空間內授與。如果在 `RoleBinding` 中使用，則會允許命名空間中大部分資源的讀取/寫入存取權，包括可在命名空間中建立角色和角色繫結。此角色不允許對資源配額或命名空間本身進行寫入存取。
Azure Arc Kubernetes 叢集管理員	允許對任何資源執行任何動作的超級使用者存取。在 `ClusterRoleBinding` 中使用時，會提供對叢集中和所有命名空間中每個資源的完整控制權。在 `RoleBinding` 中使用時，會提供對角色繫結命名空間中的每個資源 (包括命名空間本身) 的完整控制權。

您可以使用 Azure 入口網站，在叢集資源的 [存取控制 (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>

注意

您可以使用 Azure 入口網站或 Azure CLI 來建立範圍設為叢集的角色指派。不過，僅能使用 Azure CLI 來建立範圍設定為命名空間的角色指派。

自訂角色

您可以選擇建立自己的角色定義，以用於角色指派。

以下是僅允許使用者讀取部署的角色定義範例，請加以參考。如需詳細資訊，請參閱可用來建構角色定義之資料動作的完整清單。

將下列 JSON 物件複製到名為 custom-role.json 的檔案中。將 <subscription-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 檔案：

使用已啟用 Azure Arc 的 Kubernetes 叢集中的叢集連線功能 (az connectedk8s proxy)。
叢集管理員與其他每個使用者共用 kubeconfig 檔案。

使用叢集連線

執行下列命令以啟動 Proxy 程序：

az connectedk8s proxy -n <clusterName> -g <resourceGroupName>

Proxy 程序執行後，您可以在主控台開啟另一個索引標籤，開始將要求傳送至叢集。

使用共用 kubeconfig 檔案

根據您的 Kubernetes 版本，使用共用 kubeconfig 需要稍微不同的步驟。

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
```
注意

Exec 外掛程式是 Kubernetes 驗證策略，可讓 kubectl 執行外部命令以接收要傳送至 apiserver 的使用者憑證。自 Kubernetes 1.26 版起，預設的 Azure 授權外掛程式不再包含在 client-go 和 kubectl中。若在較新的版本中要使用 exec 外掛程式來接收使用者憑證，您必須使用 Azure Kubelogin，這是實作 Azure 驗證的 client-go 憑證 (exec) 外掛程式。

安裝 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

Kubelogin 可要求擁有權證明 (PoP) 權杖，以用來向已啟用 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) 並在網頁瀏覽器中開啟。
輸入您的主控台上列印的程式碼。將終端機上的程式碼複製並貼到裝置驗證輸入的提示中。
輸入使用者名稱 (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 叢集整合時，您也可以使用條件式存取來控制對叢集的存取。

注意

Microsoft Entra 條件式存取是 Microsoft Entra ID P2 功能。

若要建立與叢集搭配使用的範例條件式存取原則：

在 Azure 入口網站的頂端，搜尋並選取 [Microsoft Entra ID]。
在左側 Microsoft Entra ID 功能表上，選取 [企業應用程式]。
在左側企業應用程式的功能表上，選取 [條件式存取]。
在左側 [條件式存取] 的功能表上，選取 [原則]>[新增原則]。
輸入原則的名稱，例如 arc-k8s-policy。
選取 使用者及群組。在 [包含] 下，選擇 [選取使用者和群組]。然後，選擇要套用原則的使用者和群組。在此範例中，請選擇對您的叢集擁有管理員存取權的相同 Microsoft Entra 群組。
選取 [雲端應用程式或動作]。在 [包含] 下，選擇 [選取應用程式]。然後，搜尋並選取您先前建立的伺服器應用程式。
在 [存取控制] 下，選取 [授與]。選取 [授與存取權]>[裝置需要標記為合規]。
在 [啟用原則] 底下，選取 [開啟]>[建立]。

再次存取叢集。例如，執行 kubectl get nodes 命令以檢視叢集中的節點：

kubectl get nodes

再次遵循指示進行登入。有錯誤訊息指出您已成功登入，但管理員要求 Microsoft Entra ID 必須管理要求存取的裝置，您才能存取資源。執行下列步驟:

在 Azure 入口網站中，移至 [Microsoft Entra ID]。
選取 [企業應用程式]。然後，在 [活動] 底下，選取 [登入]。
頂端的項目會顯示「失敗」的「狀態」和「成功」的「條件式存取」。選取項目，然後在 [詳細資料] 中選取 [條件式存取]。請注意，您的條件式存取原則已列出。

使用 Microsoft Entra ID 設定 Just-In-Time 叢集存取

叢集存取控制的另一個選項是針對 Just-In-Time 要求使用 Privileged Identity Management (PIM)。

注意

Microsoft Entra PIM 是 Microsoft Entra ID P2 功能。如需 Microsoft Entra ID SKU 的詳細資訊，請參閱定價指南。

若要為叢集設定 Just-In-Time 存取要求，請完成下列步驟：

在 Azure 入口網站的頂端，搜尋並選取 [Microsoft Entra ID]。
記下租用戶識別碼。在這些指示的其餘部分，我們會將該識別碼視為 <tenant-id>。
在左側 Microsoft Entra ID 的功能表上，選取 [管理] 底下的 [群組]>[新增群組]。
確定針對 [群組類型] 選取了 [安全性]。輸入群組名稱，例如 myJITGroup。在 [Microsoft Entra 角色可以指派給此群組 (預覽)] 下，選取 [是]。最後，選取 [建立]。
您會回到 [群組] 頁面。選取新建立的群組，並記下物件識別碼。在這些指示的其餘部分，我們會將此識別碼視為 <object-id>。
返回 Azure 入口網站，在左側的 [活動] 功能表上，選取 [特殊權限存取 (預覽)]。然後，選取 [啟用特殊權限存取]。
選取 [新增指派] 開始授與存取權。
選取「成員」的角色，然後選取您要為其授與叢集存取權的使用者和群組。群組管理員可隨時修改這些指派。在準備好要繼續操作時，選取 [下一步]。
選擇 [作用中] 的指派類型，再選擇所需的持續時間，並提供理由。當您準備繼續時，請選取 [指派]。如需指派類型的詳細資訊，請參閱在 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` 規格執行協調器的一般叢集

使用叢集 API 建立的叢集

建立角色指派，以便使用者存取叢集

內建角色

自訂角色

透過使用者認證設定 kubectl

使用叢集連線

使用共用 kubeconfig 檔案

將要求傳送至叢集

搭配 Microsoft Entra ID 使用條件式存取

使用 Microsoft Entra ID 設定 Just-In-Time 叢集存取

下一步

意見反應

其他資源

共用方式為

在已啟用 Azure Arc 的 Kubernetes 叢集上使用 Azure RBAC

必要條件

在叢集上啟用 Azure RBAC

未以 apiserver 規格執行協調器的一般叢集

使用叢集 API 建立的叢集

建立角色指派，以便使用者存取叢集

內建角色

自訂角色

透過使用者認證設定 kubectl

使用叢集連線

使用共用 kubeconfig 檔案

將要求傳送至叢集

搭配 Microsoft Entra ID 使用條件式存取

使用 Microsoft Entra ID 設定 Just-In-Time 叢集存取

下一步

意見反應

其他資源

未以 `apiserver` 規格執行協調器的一般叢集