Azure Arc 所啟用 AKS 的存取和身分識別選項

  • 發行項

適用於：Azure Stack HCI 23H2 上的 AKS

您可以透過各種方式驗證、授權、保護及控制 Kubernetes 叢集的存取：

Kubernetes RBAC 和 Azure RBAC 可協助您保護叢集存取，並只提供開發人員和操作員所需的最低許可權。

此文章所介紹的核心概念，可協助您在 AKS 中驗證和指派權限。

Kubernetes RBAC

Kubernetes RBAC 提供使用者動作的細微篩選。 使用此控制機制：

  • 您為使用者或使用者群組指派建立和修改資源或查看執行中應用程式工作負載的記錄所需的權限。
  • 這些權限可以只限於單一命名空間，也可以授與給整個 AKS 叢集。
  • 您可以建立「角色」來定義權限，然後藉由「角色繫結」將這些角色指派給使用者。

如需詳細資訊，請參閱使用 Kubernetes RBAC 授權。

Role 和 ClusterRole

角色

使用 Kubernetes RBAC 將許可權指派給使用者之前，您會將使用者權力 定義為角色。 使用角色授與 Kubernetes 命名空間內的許可權。

Kubernetes 角色可以授與 權限；這些角色無法拒絕權限。 若要授與整個叢集的許可權，或授與指定命名空間以外的叢集資源，您可以使用 ClusterRoles。

ClusterRoles

ClusterRole 會將權限授與並套用於整個叢集的資源，而不是特定的命名空間。

RoleBinding 和 ClusterRoleBinding

定義角色以授與資源許可權之後，您會使用 RoleBinding 來指派這些 Kubernetes RBAC 許可權。 如果您的 AKS 叢集 與 Microsoft Entra ID 整合，RoleBindings 會將權限授與 Microsoft Entra 使用者來執行叢集內的動作。 請參閱 使用 Microsoft Entra ID 和 Kubernetes RBAC 來控制存取

RoleBindings

使用 RoleBindings 將角色指派給指定命名空間的使用者。 藉由 RoleBindings，您可以透過邏輯方式區隔單一 AKS 叢集，只讓使用者存取獲派命名空間中的應用程式資源。

若要跨整個叢集系結角色，或系結至指定命名空間以外的叢集資源，請使用 ClusterRoleBindings。

ClusterRoleBinding

透過 ClusterRoleBinding，您可以將角色繫結至使用者，並套用於整個叢集的資源，而不是特定的命名空間。 此方法可讓您將 AKS 叢集中所有資源的存取權授與管理員，或支援工程師存取這些資源。

Kubernetes 服務帳戶

Kubernetes 的其中一個主要使用者類型是「服務帳戶」。 Kubernetes API 會保存和管理服務帳戶。 服務帳戶認證會儲存為 Kubernetes 秘密，讓授權的 Pod 用來與 API 伺服器通訊。 大部分的 API 要求會為服務帳戶或一般使用者帳戶提供驗證權杖。

一般使用者帳戶會允許系統管理人員或開發人員適用的傳統存取，而不只是允許服務和程序的存取。 雖然 Kubernetes 不提供身分識別管理解決方案來儲存一般使用者帳戶和密碼，但您可以將外部身分識別解決方案整合到 Kubernetes。 針對 AKS 叢集，此整合式身分識別解決方案為 Microsoft Entra ID。

如需 Kubernetes 中身分識別選項的詳細資訊，請參閱 Kubernetes 驗證。

Azure 角色型存取控制

Azure 角色型 存取控制 （RBAC） 是以 Azure Resource Manager 為基礎的授權系統，可提供更細緻的 Azure 資源存取管理。

RBAC 系統 描述
Kubernetes RBAC 設計用來處理 AKS 叢集中的 Kubernetes 資源。
Azure RBAC 設計用來處理 Azure 訂閱內的資源。

透過 Azure RBAC，您可以建立角色定義來概述要套用的權限。 然後，您可以透過特定範圍的角色指派來指派使用者或將此角色定義分組。 範圍可以是個別資源、資源群組，或跨訂閱。

如需詳細資訊，請參閱什麼是 Azure 角色型存取控制 (Azure RBAC)？

有兩個必要層級的存取權可完全運作 AKS Arc 叢集：

  • 存取 Azure 訂用帳戶的 AKS 資源。
    • 使用 Azure Arc API 所啟用的 AKS 來控制調整或升級叢集。
    • 提取您的 系統管理員憑證型 kubeconfig。
    • 提取已啟用 Entra 識別碼的 kubeconfig。
  • 存取 Kubernetes API。 此存取權由下列任一項控制：
    • Kubernetes RBAC 或
    • 整合 Azure RBAC 與 AKS 以進行kubernetes 授權。

Azure RBAC 可授權 AKS 資源的存取權限

透過 Azure RBAC，您可以跨一個或多個訂閱將 AKS 資源的細微存取權限提供給使用者 (或身分識別)。 此控制平面動作有三個角色可供使用：Azure Kubernetes Service Arc 叢集管理員角色、Azure Kubernetes Service Arc 叢集使用者角色，以及 Azure Kubernetes Service Arc 參與者角色。 每個角色都有不同的許可權範圍，如適用於容器的 Azure 內建角色中所述。 例如，您可以使用 Azure Kubernetes Service Arc 參與者 角色來建立、調整和升級叢集。 同時，具有 Azure Kubernetes Service Arc 叢集管理員 角色的另一位使用者只有提取 管理員 kubeconfig 的許可權。

適用於 Kubernetes 的 Azure RBAC 授權

透過 Azure RBAC 整合，AKS 會使用 Kubernetes 授權 Webhook 伺服器，因此您可以使用 Azure 角色定義和角色指派來管理Microsoft Entra 整合式 Kubernetes 叢集資源許可權和指派。

授權流程圖。

如下圖所示，使用 Azure RBAC 整合時，對 Kubernetes API 的所有要求都會遵循相同的驗證流程，如Microsoft Entra 整合中所述。

如果提出要求的身分識別存在於 entra 標識符Microsoft，則具有 Kubernetes RBAC 的 Azure 小組會授權要求。 如果身分識別存在於 Microsoft Entra ID 之外（例如 Kubernetes 服務帳戶），授權會延遲至一般的 Kubernetes RBAC。

在此案例中，您會使用 Azure RBAC 機制和 API 來指派使用者內建角色或建立自訂角色，就像使用 Kubernetes 角色一樣。

透過這項功能，您不僅會針對跨訂閱的使用者授與 AKS 資源的權限，也會為每個控制 Kubernetes API 存取的叢集內設定角色和權限。 此數據平面動作有四個內建角色可供使用，每個角色都有自己的許可權範圍， 如內建角色 一節所述。

重要

您必須先啟用 Azure RBAC 進行 Kubernetes 授權，才能進行角色指派。 如需詳細資訊和逐步指引，請參閱 使用 Azure RBAC 進行 Kubernetes 授權。

內建角色

Arc 所啟用的 AKS 提供下列五個內建角色。 它們與 Kubernetes 內建角色 類似，但有一些差異，例如支援 CRD。 請參閱每個 Azure 內建角色所允許的動作完整清單。

角色 描述
已啟用 Azure Arc 的 Kubernetes 叢集使用者 可讓您擷取叢集 Connect 型 kubeconfig 檔案，以從任何地方管理叢集。
Azure Arc Kubernetes 檢視器 允許唯讀存取來查看命名空間中的大部分物件。
不允許檢視秘密，因為 秘密的讀取 許可權可存取 命名空間中的 ServiceAccount 認證。 這些認證接著允許透過該 ServiceAccount 值進行 API 存取（許可權提升的形式）。
Azure Arc Kubernetes 寫入器 允許命名空間中大部分物件的讀取/寫入存取權。
不允許檢視或修改角色或角色系結。 不過，此角色允許存取秘密和執行 Pod 做為命名空間中的任何 ServiceAccount 值，因此可用來取得命名空間中任何這類 ServiceAccount 值的 API 存取層級。
Azure Arc Kubernetes 管理員 允許管理員存取。 其旨在透過 RoleBinding 授與命名空間內。 如果您在 RoleBinding 中使用，它允許讀取/寫入命名空間中的大部分資源，包括能夠在命名空間內建立角色和角色系結。 此角色不允許對資源配額或命名空間本身進行寫入存取。
Azure Arc Kubernetes 叢集管理員 允許「超級使用者」存取在任何資源上執行任何動作。 當您在 ClusterRoleBinding 中使用時，它會完全控制叢集中和所有命名空間中的每個資源。 當您在 RoleBinding 中使用時，它會完整控制角色系結命名空間中的每個資源，包括命名空間本身。

Microsoft Entra 整合

使用 Microsoft Entra 整合來增強 AKS 叢集安全性。 以企業身分識別管理體驗為基礎，Microsoft Entra ID 是結合核心目錄服務、應用程式存取管理和身分識別保護的多租使用者、雲端式目錄和身分識別管理服務。 透過 Microsoft Entra ID，您可以將內部部署身分識別整合到 AKS 叢集，以提供單一來源的帳戶管理和安全性。

顯示 Entra 整合的流程圖。

透過 Microsoft Entra 整合的 AKS 叢集，您可以授與使用者或群組命名空間內或整個叢集內 Kubernetes 資源的存取權。

  • 若要取得 kubectl 組態內容，請執行 az aksarc get-credentials 命令。
  • 當使用者使用 kubectl 與 AKS 叢集互動時，系統會提示使用者使用其Microsoft Entra 認證登入。

此方法提供單一來源，用於使用者帳戶管理和密碼認證。 使用者只能存取 Kubernetes 叢集管理員所定義的資源。

Microsoft Entra 驗證會提供給具有 OpenID Connect 的 AKS 叢集。 OpenID Connect 是以 OAuth 2.0 通訊協定為建置基礎的身分識別層。 如需 OpenID Connect 的詳細資訊，請參閱 OpenID Connect 檔。 從 Kubernetes 叢集內部， 會使用 Webhook 令牌驗證 來驗證驗證令牌。 Webhook 權杖驗證已設定並當作 AKS 叢集的一部分管理。

摘要

下表包含用戶在啟用 Entra 整合 Microsoft時如何向 Kubernetes 進行驗證的摘要。 在所有情況下，命令序列為：

  1. 執行 az login 向 Azure 驗證。
  2. 執行 az aksarc get-credentials 以將 Kubernetes 叢集的認證下載到 .kube/config。
  3. 執行 kubectl 命令。
    • 第一個命令可以觸發瀏覽器型驗證，以向 Kubernetes 叢集進行驗證，如下表所述。
描述 需要角色授與 叢集管理員Microsoft Entra 群組 使用時機
使用客戶端憑證進行管理員登入 Azure Kubernetes Service Arc 叢集管理員角色。 此角色允許 az aksarc get-credentials 與旗標搭配 --admin 使用，此旗標會將非Microsoft Entra 叢集管理員憑證下載至使用者的 .kube/config。這是 Azure Kubernetes 管理員角色的唯一用途。 n/a 如果您遭到永久封鎖，因為無法存取擁有叢集存取權的有效 Microsoft Entra 群組。
Microsoft具有手動 （叢集） RoleBindings 的 Entra 識別符 Azure Kubernetes Service Arc 叢集使用者角色。 [ 使用者 ] 角色允許 az aksarc get-credentials 在沒有旗標的情況下 --admin 使用。 這是 Azure Kubernetes Service 叢集使用者角色的唯一用途。 Microsoft已啟用 Entra ID 的叢集上，結果是將空白項目下載到 .kube/config，這會在第一次由 kubectl 使用時觸發瀏覽器型驗證。 由於使用者不在任何叢集管理員群組中，因此其許可權完全由叢集管理員所設定的任何 RoleBindings 或 ClusterRoleBindings 控制。 [叢集] RoleBindings 會提名Microsoft Entra 使用者或Microsoft Entra 群組 作為其主體。 如果未設定這類系結，使用者就無法執行任何 kubectl 命令。 如果您想要更精細的存取控制，而且您不使用 Azure RBAC for Kubernetes 授權。 請注意，設定系結的用戶必須使用下表所列的其他方法之一登入。
Microsoft由叢集管理員成員Microsoft Entra 群組成員的 Entra 標識符（在 Azure CLI 中使用 --aad-admin-group-object-ids 旗標設定） 同前。 使用者是此處所列其中一個群組的成員。 AKS 會自動產生 ClusterRoleBinding，將全部列出的群組繫結至 cluster-admin Kubernetes 角色。 因此，這些群組中的使用者能夠以 kubectl 身分執行全部的 cluster-admin 命令。 如果您想要授與使用者完整的系統管理員許可權，且不使用 Azure RBAC 進行 Kubernetes 授權。
使用 Azure RBAC for Kubernetes 授權Microsoft Entra 識別碼 兩個角色：
Azure Kubernetes Service Arc 叢集使用者角色 （如先前所述）。
先前所述的其中一個 Azure Arc Kubernetes 角色，或您自己的自定義替代方案。		 啟用適用於 Kubernetes 授權的 Azure RBAC 時，[設定] 索引標籤上的 [系統管理員角色] 字段無關緊要。 您可以使用 Azure RBAC 進行 Kubernetes 授權。 這種方法可讓您更精細地控制，而不需要設定 RoleBindings 或 ClusterRoleBindings。

下一步