您可以使用 Microsoft Entra ID 和 Azure 角色型存取控制 (Azure RBAC) 來控制已啟用 Azure Arc 的 Kubernetes 叢集上的授權檢查。 Azure 角色指派可讓您細微控制哪位使用者可以讀取、寫入和刪除 Kubernetes 物件 (例如部署、Pod 和服務)。 Kubernetes ClusterRoleBinding 和 RoleBinding 物件類型有助於原生定義 Kubernetes 中的授權。
若需此功能的概念性概觀,請參閱已啟用 Azure Arc 的 Kubernetes 上的 Azure RBAC。
先決條件
安裝 Azure CLI 或升級至最新版本。
安裝最新版的
connectedk8s
Azure CLI 擴充功能:az extension add --name connectedk8s
如果已安裝
connectedk8s
延伸模組,您可以使用下列命令,將其更新至最新版本:az extension update --name connectedk8s
連線已啟用 Azure Arc 的現有 Kubernetes 叢集:
附註
Red Hat OpenShift 或受控 Kubernetes 供應專案不支援 Azure RBAC,其中使用者對 API 伺服器的存取受到限制(例如 Amazon Elastic Kubernetes Service (EKS) 或 Google Kubernetes Engine (GKE))。
Azure RBAC 目前不支援在 Arm64 架構上運作的 Kubernetes 叢集。 針對這些叢集,請使用 Kubernetes RBAC 來管理訪問控制。
對於 Azure Kubernetes Service (AKS) 叢集,此功能是原本就提供的,且不需要 AKS 叢集以連線至 Azure Arc。
針對 Azure Arc 所啟用的 Azure Local 23H2 版本上的 Azure Kubernetes Service (AKS) 叢集,目前只有在建立叢集時啟用 Azure RBAC 才會支援。 若要建立已啟用 Azure RBAC 的 Azure Arc 所啟用的 AKS 叢集,請參閱使用 Azure RBAC 進行 Kubernetes 授權。 Azure Local 版本 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
附註
在執行
enable-features
指令之前,請確認機器上的kubeconfig
文件是否指向您要啟用 Azure RBAC 的叢集。使用
--skip-azure-rbac-list
搭配此命令,以逗號分隔格式輸入需要授權檢查的使用者名稱、電子郵件和 OpenID 連線清單,這將使用 Kubernetes 的原生ClusterRoleBinding
和RoleBinding
物件,而非 Azure RBAC。
接下來,請遵循適當區段中的步驟,這取決於您是否正在使用一個未在apiserver
規範上執行協調器的通用叢集,或是透過叢集 API 所建立的叢集。
未以 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
設定下列
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 叢集的存取權。
內建角色
下列內建角色提供存取權,以在 Kubernetes 叢集上執行一般工作。 這些角色可以授與 Microsoft Entra ID 使用者、群組或服務主體。
角色 | 描述 |
---|---|
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 入口網站或 Azure CLI 來建立限定叢集範圍的內建角色指派。 不過,僅能使用 Azure CLI 來建立範圍為命名空間的角色指派。
若要在 Azure 入口網站中建立範圍為已啟用 Azure Arc 的 Kubernetes 叢集的角色指派,請瀏覽至叢集,然後從服務功能表中選取 [存取控制] (IAM)。
若要使用 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>
自訂角色
您可以選擇建立自己的角色定義,以用於角色指派。 如需詳細資訊,請參閱可用來建構角色定義之資料動作的完整清單。
下列範例顯示自定義角色定義,可讓使用者讀取部署,但不會提供其他存取權。 自訂角色會使用其中一個資料動作,並且讓您檢視建立角色指派所在的範圍 (叢集或命名空間) 中的所有部署。
{
"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>"
]
}
若要使用此角色定義,請將下列 JSON 物件複製到名為 custom-role.json的檔案中。 將 <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 檔案
執行下列命令以設定使用者的憑證。 將
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 版開始,若要使用 exec 外掛程式來接收使用者認證,您必須使用實作 Azure 驗證的認證 (exec) 外掛程式 Azure kubeloginclient-go
。 若要安裝 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
命令。 例如:kubectl get nodes
kubectl get pods
在系統提示您進行瀏覽器型驗證後,請複製裝置登入 URL (
https://microsoft.com/devicelogin
),並在網頁瀏覽器中開啟。輸入您的主控台上列印的程式碼。 將終端機上的程式碼複製並貼到裝置驗證輸入的提示中。
輸入使用者名稱 (
testuser@mytenant.onmicrosoft.com
) 和相關聯的密碼。如果您看到錯誤訊息指出使用者無法存取 Azure 中的資源,這表示您未經授權存取所要求的資源。 在此情況下,Azure 租使用者中的系統管理員必須建立新的角色指派,以授權此使用者擁有資源的存取權。
搭配 Microsoft Entra ID 使用條件式存取
將 Microsoft Entra ID 與已啟用 Azure Arc 的 Kubernetes 叢集整合時,您也可以使用條件式存取來控制對叢集的存取。
附註
Microsoft Entra 條件式存取是 Microsoft Entra ID P2 的一項功能。 如需Microsoft Entra ID SKU 的詳細資訊,請參閱 定價指南。
若要建立與叢集搭配使用的範例條件式存取原則:
- 在 Azure 入口網站的頂端,搜尋並選取 [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 叢集存取
叢集訪問控制的另一個選項是 Privileged Identity Management (PIM),可為使用者啟用更高層級的 Just-In-Time 要求存取權。
附註
Microsoft Entra PIM 是 Microsoft Entra ID P2 的一項功能。 如需Microsoft Entra ID SKU 的詳細資訊,請參閱 定價指南。
若要設定使用者群組的 Just-In-Time 存取要求,請完成下列步驟:
在 Azure 入口網站的頂端,搜尋並選取 [Microsoft Entra ID]。
在服務功能表中的 [ 管理] 底下,選取 [ 群組]。 然後選取 [新增群組]。
針對 [群組類型],確認已選取 [安全性 ]。 輸入群組名稱,例如
myJITGroup
。 進行任何其他選擇,然後選取 [建立]。您會再回到 [群組] 頁面。 搜尋並選取新建立的群組。
在服務功能表中的 [ 活動] 底下,選取 [ Privileged Identity Management]。 然後選取 [啟用此群組的 PIM]。
選取 [新增指派] 開始授與存取權。
在 [選取角色] 下,選擇 [ 成員]。 然後選取您要授與叢集存取權的使用者和群組。 群組管理員可隨時修改這些指派。 在準備好繼續時,請選取 [下一步]。
選擇 [作用中] 的指派類型,再選擇所需的期間,並提供理由。 當您準備好繼續時,請選取 [指派]。
如需這些步驟和選項的詳細資訊,請參閱 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 架構。
- 使用叢集連線,安全地連線到啟用 Arc 的 Kubernetes 叢集。
- 遵循已啟用 Azure Arc 的 Kubernetes 安全性手冊中的指引,協助以其他方式保護您的叢集。