在已啟用 Azure Arc 的 Kubernetes 叢集上使用 Azure RBAC (預覽)

  • 發行項

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

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

重要

已啟用 Azure Arc 的 Kubernetes 預覽功能可在自助服務選擇基礎上取得。 預覽會以「現狀」和「可供使用時」提供，其其不受服務等級協定和有限瑕疵擔保所保護。 客戶支援部門會盡最大努力，支援部分已啟用 Azure Arc 的 Kubernetes 預覽功能。

必要條件

  • 安裝 Azure CLI 或升級至最新版本。

  • 安裝最新版的 connectedk8s Azure CLI 延伸模組：

    az extension add --name connectedk8s

    如果已安裝 connectedk8s 延伸模組，您可以使用下列命令，將其更新至最新版本：

    az extension update --name connectedk8s

  • 連接已啟用 Azure Arc 的現有 Kubernetes 叢集：

注意

您無法為 Red Hat OpenShift 或雲端提供者的受控 Kubernetes 供應項目設定這項功能 (例如，Elastic Kubernetes Service 或 Google Kubernetes Engine)，因為使用者無法存取叢集的 API 伺服器。 對於 Azure Kubernetes Service (AKS) 叢集，此功能是原本就提供的，且不需要 AKS 叢集連線至 Azure Arc。

設定 Microsoft Entra 應用程式

建立伺服器應用程式

  1. 建立新的 Microsoft Entra 應用程式並取得其 appId 值。 此值將在後續步驟中作為 serverApplicationId。

    CLUSTER_NAME="<name-of-arc-connected-cluster>"
TENANT_ID="<tenant>"
SERVER_UNIQUE_SUFFIX="<identifier_suffix>"
SERVER_APP_ID=$(az ad app create --display-name "${CLUSTER_NAME}Server" --identifier-uris "api://${TENANT_ID}/${SERVER_UNIQUE_SUFFIX}" --query appId -o tsv)
echo $SERVER_APP_ID

  2. 若要將「登入及讀取使用者設定檔」API 權限授與伺服器應用程式，請複製此 JSON 並儲存在名為 oauth2-permissions.json 的檔案中：

    {
    "oauth2PermissionScopes": [
        {
            "adminConsentDescription": "Sign in and read user profile",
            "adminConsentDisplayName": "Sign in and read user profile",
            "id": "<paste_the_SERVER_APP_ID>",
            "isEnabled": true,
            "type": "User",
            "userConsentDescription": "Sign in and read user profile",
            "userConsentDisplayName": "Sign in and read user profile",
            "value": "User.Read"
        }
    ]
}

  3. 更新應用程式的群組成員資格宣告。 在與 oauth2-permissions.json 檔案相同的目錄中執行命令。 要將 RBAC 用於已啟用 Azure Arc 的 Kubernetes，signInAudience 必須設定為 AzureADMyOrg：

    az ad app update --id "${SERVER_APP_ID}" --set groupMembershipClaims=All
az ad app update --id ${SERVER_APP_ID} --set  api=@oauth2-permissions.json
az ad app update --id ${SERVER_APP_ID} --set  signInAudience=AzureADMyOrg
SERVER_OBJECT_ID=$(az ad app show --id "${SERVER_APP_ID}" --query "id" -o tsv)
az rest --method PATCH --headers "Content-Type=application/json" --uri https://graph.microsoft.com/v1.0/applications/${SERVER_OBJECT_ID}/ --body '{"api":{"requestedAccessTokenVersion": 1}}'

  4. 建立服務主體並取得其 password 欄位值。 後續當您在叢集上啟用此功能時，需要將此值作為 serverApplicationSecret。 此秘密的有效期預設為一年，其後將必須輪替。 若要設定自訂到期時間，請使用 az ad sp credential reset：

    az ad sp create --id "${SERVER_APP_ID}"
SERVER_APP_SECRET=$(az ad sp credential reset --id "${SERVER_APP_ID}"  --query password -o tsv)

  5. 使用 az ad app permission 為應用程式授與「登入和讀取使用者設定檔」API 權限：

    az ad app permission add --id "${SERVER_APP_ID}" --api 00000003-0000-0000-c000-000000000000 --api-permissions e1fe6dd8-ba31-4d61-89e7-88639da4683d=Scope
az ad app permission grant --id "${SERVER_APP_ID}" --api 00000003-0000-0000-c000-000000000000 --scope User.Read

    注意

    Azure 應用程式系統管理員必須執行此步驟。

    若要在生產環境中使用此功能，建議您為每個叢集建立不同的伺服器應用程式。

建立用戶端應用程式

  1. 建立新的 Microsoft Entra 應用程式並取得其 appId 值。 此值將在後續步驟中作為 clientApplicationId。

    CLIENT_UNIQUE_SUFFIX="<identifier_suffix>" 
CLIENT_APP_ID=$(az ad app create --display-name "${CLUSTER_NAME}Client" --is-fallback-public-client --public-client-redirect-uris "api://${TENANT_ID}/${CLIENT_UNIQUE_SUFFIX}" --query appId -o tsv)
echo $CLIENT_APP_ID

  2. 建立此用戶端應用程式的服務主體：

    az ad sp create --id "${CLIENT_APP_ID}"

  3. 取得伺服器應用程式的 oAuthPermissionId 值：

        az ad app show --id "${SERVER_APP_ID}" --query "api.oauth2PermissionScopes[0].id" -o tsv

  4. 授與用戶端應用程式的必要權限。 要將 RBAC 用於已啟用 Azure Arc 的 Kubernetes，signInAudience 必須設定為 AzureADMyOrg：

        az ad app permission add --id "${CLIENT_APP_ID}" --api "${SERVER_APP_ID}" --api-permissions <oAuthPermissionId>=Scope
    RESOURCE_APP_ID=$(az ad app show --id "${CLIENT_APP_ID}"  --query "requiredResourceAccess[0].resourceAppId" -o tsv)
    az ad app permission grant --id "${CLIENT_APP_ID}" --api "${RESOURCE_APP_ID}" --scope User.Read
    az ad app update --id ${CLIENT_APP_ID} --set  signInAudience=AzureADMyOrg
    CLIENT_OBJECT_ID=$(az ad app show --id "${CLIENT_APP_ID}" --query "id" -o tsv)
    az rest --method PATCH --headers "Content-Type=application/json" --uri https://graph.microsoft.com/v1.0/applications/${CLIENT_OBJECT_ID}/ --body '{"api":{"requestedAccessTokenVersion": 1}}'

建立伺服器應用程式的角色指派

伺服器應用程式需要 Microsoft.Authorization/*/read 權限，以確認提出要求的使用者在要求中包含的 Kubernetes 物件上是否已獲授權。

  1. 使用下列內容建立名為 accessCheck.json 的檔案：

    {
"Name": "Read authorization",
"IsCustom": true,
"Description": "Read authorization",
"Actions": ["Microsoft.Authorization/*/read"],
"NotActions": [],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
  "/subscriptions/<subscription-id>"
  ]
}

    請將 <subscription-id> 取代為實際的訂用帳戶識別碼。

  2. 執行下列命令以建立新的自訂角色：

    ROLE_ID=$(az role definition create --role-definition ./accessCheck.json --query id -o tsv)

  3. 使用您所建立的角色，在伺服器應用程式上建立角色指派 assignee：

    az role assignment create --role "${ROLE_ID}" --assignee "${SERVER_APP_ID}" --scope /subscriptions/<subscription-id>

在叢集上啟用 Azure RBAC

執行下列命令，在已啟用 Azure Arc 的 Kubernetes 叢集上啟用 Azure 角色型存取控制 (RBAC)：

az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac --app-id "${SERVER_APP_ID}" --app-secret "${SERVER_APP_SECRET}"

注意

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

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

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

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

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

    1. 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

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

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

    3. 在 volumes 底下新增下列規格：

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

    4. 在 volumeMounts 底下新增下列規格：

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

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

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

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

    2. 在 volumes 底下新增下列規格：

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

    3. 在 volumeMounts 底下新增下列規格：

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

  2. 新增下列 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

  3. 儲存並關閉編輯器以更新 apiserver Pod。

使用叢集 API 建立的叢集

  1. 將包含驗證和授權 Webhook 組態檔的防護密碼，從工作負載叢集複製到您的機器上：

    kubectl get secret azure-arc-guard-manifests -n kube-system -o yaml > azure-arc-guard-manifests.yaml

  2. 將 azure-arc-guard-manifests.yaml 檔案中的 namespace 欄位變更為管理叢集內的命名空間 (您要在其中套用自訂資源以建立工作負載叢集)。

  3. 套用此資訊清單：

    kubectl apply -f azure-arc-guard-manifests.yaml

  4. 執行 kubectl edit kcp <clustername>-control-plane 以編輯 KubeadmControlPlane 物件：

    1. 在 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"

    2. 在 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

    3. 在 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

    4. 儲存並關閉以更新 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>"
    ]
}

  1. 從您儲存 custom-role.json 的資料夾執行下列命令，以建立角色定義：

    az role definition create --role-definition @custom-role.json

  2. 使用此自訂角色定義建立角色指派：

    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 需要稍微不同的步驟。

  1. 執行下列命令以設定使用者的認證：

    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>

  2. 開啟您先前建立的 kubeconfig 檔案。 在 contexts 底下，確認與叢集相關聯的內容指向您在上一個步驟中建立的使用者認證。 若要將目前內容設定為這些使用者憑證，請執行下列命令：

    kubectl config set-context --current=true --user=<testuser>@<mytenant.onmicrosoft.com>

  3. 在 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) 外掛程式。

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

  2. 轉換 kubelogin 使用適當的登入模式。 例如，針對使用 Microsoft Entra 使用者的裝置代碼登入，命令如下所示：

    export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig

將要求傳送至叢集

  1. 執行任何 kubectl 命令。 例如：

    • kubectl get nodes
    • kubectl get pods

  2. 在系統提示您進行瀏覽器型驗證後，請複製裝置登入 URL (https://microsoft.com/devicelogin) 並在網頁瀏覽器中開啟。

  3. 輸入您的主控台上列印的程式碼。 將終端機上的程式碼複製並貼到裝置驗證輸入的提示中。

  4. 輸入使用者名稱 (testuser@mytenant.onmicrosoft.com) 和相關聯的密碼。

  5. 如果您看到類似這樣的錯誤訊息，表示您未獲授權而無法存取要求的資源：

    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 功能。

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

  1. 在 Azure 入口網站的頂端，搜尋並選取 [Microsoft Entra ID]。

  2. 在左側 Microsoft Entra ID 功能表上，選取 [企業應用程式]。

  3. 在左側企業應用程式的功能表上，選取 [條件式存取]。

  4. 在左側 [條件式存取] 的功能表上，選取 [原則]>[新增原則]。

    Screenshot showing how to add a conditional access policy in the Azure portal.

  5. 輸入原則的名稱，例如 arc-k8s-policy。

  6. 選取 使用者及群組。 在 [包含] 下，選擇 [選取使用者和群組]。 然後，選擇要套用原則的使用者和群組。 在此範例中，請選擇對您的叢集擁有管理員存取權的相同 Microsoft Entra 群組。

    Screenshot that shows selecting users or groups to apply the Conditional Access policy.

  7. 選取 [雲端應用程式或動作]。 在 [包含] 下，選擇 [選取應用程式]。 然後，搜尋並選取您先前建立的伺服器應用程式。

    Screenshot showing how to select a server application in the Azure portal.

  8. 在 [存取控制] 下，選取 [授與]。 選取 [授與存取權]>[裝置需要標記為合規]。

    Screenshot showing how to allow only compliant devices in the Azure portal.

  9. 在 [啟用原則] 底下，選取 [開啟]>[建立]。

    Screenshot showing how to enable a conditional access policy in the Azure portal.

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

kubectl get nodes

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

  1. 在 Azure 入口網站中，移至 [Microsoft Entra ID]。

  2. 選取 [企業應用程式]。 然後，在 [活動] 底下，選取 [登入]。

  3. 頂端的項目會顯示「失敗」的「狀態」和「成功」的「條件式存取」。 選取項目，然後在 [詳細資料] 中選取 [條件式存取]。 請注意，您的條件式存取原則已列出。

    Screenshot showing a failed sign-in entry in the Azure portal.

使用 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 存取要求，請完成下列步驟：

  1. 在 Azure 入口網站的頂端，搜尋並選取 [Microsoft Entra ID]。

  2. 記下租用戶識別碼。 在這些指示的其餘部分，我們會將該識別碼視為 <tenant-id>。

    Screenshot showing Microsoft Entra ID details in the Azure portal.

  3. 在左側 Microsoft Entra ID 的功能表上，選取 [管理] 底下的 [群組]>[新增群組]。

  4. 確定針對 [群組類型] 選取了 [安全性]。 輸入群組名稱，例如 myJITGroup。 在 [Microsoft Entra 角色可以指派給此群組 (預覽)] 下，選取 [是]。 最後，選取 [建立]。

    Screenshot showing details for the new group in the Azure portal.

  5. 您會回到 [群組] 頁面。 選取新建立的群組，並記下物件識別碼。 在這些指示的其餘部分，我們會將此識別碼視為 <object-id>。

    Screenshot showing the object ID for the new group in the Azure portal.

  6. 返回 Azure 入口網站，在左側的 [活動] 功能表上，選取 [特殊權限存取 (預覽)]。 然後，選取 [啟用特殊權限存取]。

    Screenshot showing selections for enabling privileged access in the Azure portal.

  7. 選取 [新增指派] 開始授與存取權。

    Screenshot showing how to add active assignments in the Azure portal.

  8. 選取「成員」的角色，然後選取您要為其授與叢集存取權的使用者和群組。 群組管理員可隨時修改這些指派。 在準備好要繼續操作時，選取 [下一步]。

    Screenshot showing how to add assignments in the Azure portal.

  9. 選擇 [作用中] 的指派類型，再選擇所需的持續時間，並提供理由。 當您準備繼續時，請選取 [指派]。 如需指派類型的詳細資訊，請參閱在 Privileged Identity Management 中指派特殊權限存取群組 (預覽) 的資格。

    Screenshot showing assignment properties in the Azure portal.

進行指派之後，請存取叢集以確認 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

重新整理伺服器應用程式的秘密

如果伺服器應用程式服務主體的秘密已過期，則您必須加以輪替。

SERVER_APP_SECRET=$(az ad sp credential reset --name "${SERVER_APP_ID}" --credential-description "ArcSecret" --query password -o tsv)

更新叢集上的秘密。 請包含您在此命令最初執行時設定的任何選擇性參數。

az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac --app-id "${SERVER_APP_ID}" --app-secret "${SERVER_APP_SECRET}"

下一步