Azure Kubernetes Service (AKS) 中驗證和授權的最佳做法Best practices for authentication and authorization in Azure Kubernetes Service (AKS)

當您在 Azure Kubernetes Service (AKS) 中部署及維護叢集時,您必須透過適當實作來管理對資源和服務的存取。As you deploy and maintain clusters in Azure Kubernetes Service (AKS), you need to implement ways to manage access to resources and services. 若沒有這樣的控制,帳戶將可能存取不需要的資源和服務。Without these controls, accounts may have access to resources and services they don't need. 此外,也會難以追蹤用來進行變更的認證集。It can also be hard to track which set of credentials were used to make changes.

這篇最佳做法文章主要將說明叢集操作員如何管理 AKS 叢集的存取與身分識別。This best practices article focuses on how a cluster operator can manage access and identity for AKS clusters. 在本文中,您將了解:In this article, you learn how to:

  • 使用 Azure Active Directory 驗證 AKS 叢集使用者Authenticate AKS cluster users with Azure Active Directory
  • 使用角色型存取控制 (RBAC) 來控制對於資源的存取Control access to resources with role-based access controls (RBAC)
  • 使用受控識別向其他服務驗證其本身Use a managed identity to authenticate themselves with other services

使用 Azure Active DirectoryUse Azure Active Directory

最佳做法指引 - 使用 Azure AD 整合部署 AKS 叢集。Best practice guidance - Deploy AKS clusters with Azure AD integration. 使用 Azure AD 可集中處理身分識別管理元件。Using Azure AD centralizes the identity management component. 在存取 AKS 叢集時,使用者帳戶或群組狀態中的任何變更都將自動更新。Any change in user account or group status is automatically updated in access to the AKS cluster. 使用下一節所將討論的角色或 ClusterRoles 和繫結,可將使用者或群組的限定於所需的最少量權限範圍內。Use Roles or ClusterRoles and Bindings, as discussed in the next section, to scope users or groups to least amount of permissions needed.

Kubernetes 叢集的開發人員和應用程式擁有者需要存取不同的資源。The developers and application owners of your Kubernetes cluster need access to different resources. Kubernetes 不提供身分識別管理解決方案來控制哪些使用者可以與哪些資源互動。Kubernetes doesn't provide an identity management solution to control which users can interact with what resources. 您通常會將叢集與現有的身分識別解決方案整合。Instead, you typically integrate your cluster with an existing identity solution. Azure Active Directory (AD) 提供符合企業需求的身分識別管理解決方案,並且可與 AKS 叢集整合。Azure Active Directory (AD) provides an enterprise-ready identity management solution, and can integrate with AKS clusters.

透過 Azure AD 在 AKS 中整合的叢集,您可以建立角色ClusterRoles,以定義資源的存取權限。With Azure AD-integrated clusters in AKS, you create Roles or ClusterRoles that define access permissions to resources. 接著,您可以從 Azure AD 將角色繫結至使用者或群組。You then bind the roles to users or groups from Azure AD. 這些 Kubernetes 角色型存取控制 (RBAC) 將在下一節中討論。These Kubernetes role-based access controls (RBAC) are discussed in the next section. 下圖顯示 Azure AD 的整合以及如何控制對資源的存取:The integration of Azure AD and how you control access to resources can be seen in the following diagram:

對 Azure Active Directory 與 AKS 的整合進行叢集層級驗證

  1. 開發人員向 Azure AD 進行驗證。Developer authenticates with Azure AD.
  2. Azure AD 權杖發行端點會發行存取權杖。The Azure AD token issuance endpoint issues the access token.
  3. 開發人員使用 Azure AD 權杖執行動作,例如 kubectl create podThe developer performs an action using the Azure AD token, such as kubectl create pod
  4. Kubernetes 向 Azure Active Directory 驗證權杖,並擷取開發人員的群組成員資格。Kubernetes validates the token with Azure Active Directory and fetches the developer's group memberships.
  5. 套用 Kubernetes 角色型存取控制 (RBAC) 和叢集原則。Kubernetes role-based access control (RBAC) and cluster policies are applied.
  6. 開發人員的要求是否成功取決於根據先前的 Azure AD 群組成員資格以及 Kubernetes RBAC 和原則的驗證。Developer's request is successful or not based on previous validation of Azure AD group membership and Kubernetes RBAC and policies.

若要建立 AKS 叢集使用 Azure AD,請參閱整合 Azure Active Directory 與 AKSTo create an AKS cluster that uses Azure AD, see Integrate Azure Active Directory with AKS.

使用角色型存取控制 (RBAC)Use role-based access controls (RBAC)

最佳做法指引 - 使用 Kubernetes RBAC 定義使用者或群組對於叢集中的資源所擁有的權限。Best practice guidance - Use Kubernetes RBAC to define the permissions that users or groups have to resources in the cluster. 建立會指派最少量必要權限的角色和繫結。Create roles and bindings that assign the least amount of permissions required. 與 Azure AD 整合,讓使用者狀態或群組成員資格中的任何變更都會自動更新,並且讓叢集資源的存取權保持在最新狀態。Integrate with Azure AD so any change in user status or group membership is automatically updated and access to cluster resources is current.

在 Kubernetes 中,您可以對叢集中的資源存取進行更精細的控制。In Kubernetes, you can provide granular control of access to resources in the cluster. 權限可定義於叢集層級上,或定義至特定的命名空間。Permissions can be defined at the cluster level, or to specific namespaces. 您可以定義可管理哪些資源,以及具備哪些權限。You can define what resources can be managed, and with what permissions. 這些角色會套用至具有繫結的使用者或群組。These roles are the applied to users or groups with a binding. 如需詳細資訊角色ClusterRoles,並繫結,請參閱存取和身分識別選項 Azure Kubernetes Service (AKS).For more information about Roles, ClusterRoles, and Bindings, see Access and identity options for Azure Kubernetes Service (AKS).

例如,您可以在名為 finance-app 的命名空間中建立會授與完整資源存取權的角色,如下列範例 YAML 資訊清單所示:As an example, you can create a Role that grants full access to resources in the namespace named finance-app, as shown in the following example YAML manifest:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role
  namespace: finance-app
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

RoleBinding 接著會建立繫結的 Azure AD 使用者developer1@contoso.com至 RoleBinding,如下列 YAML 資訊清單中所示:A RoleBinding is then created that binds the Azure AD user developer1@contoso.com to the RoleBinding, as shown in the following YAML manifest:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role-binding
  namespace: finance-app
subjects:
- kind: User
  name: developer1@contoso.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: finance-app-full-access-role
  apiGroup: rbac.authorization.k8s.io

developer1@contoso.com通過驗證還針對 AKS 叢集,在資源的完整權限財務應用程式命名空間。When developer1@contoso.com is authenticated against the AKS cluster, they have full permissions to resources in the finance-app namespace. 如此,您將可透過邏輯方式來區分及控制對資源的存取。In this way, you logically separate and control access to resources. 如上一節的討論,Kubernetes RBAC 應與 Azure AD 整合搭配使用。Kubernetes RBAC should be used in conjunction with Azure AD-integration, as discussed in the previous section.

若要了解如何使用 Azure AD 群組來控制使用 RBAC 的 Kubernetes 資源的存取權,請參閱控制在 AKS 中使用角色型存取控制和 Azure Active Directory 身分識別的叢集資源的存取權To see how to use Azure AD groups to control access to Kubernetes resources using RBAC, see Control access to cluster resources using role-based access controls and Azure Active Directory identities in AKS.

使用 Pod 身分識別Use pod identities

最佳做法指引 - 請勿使用 Pod 或容器映像內的固定認證,因為這些認證有外洩或濫用的風險。Best practice guidance - Don't use fixed credentials within pods or container images, as they are at risk of exposure or abuse. 請改用 Pod 身分識別,以使用中央 Azure AD 身分識別解決方案自動要求存取權。Instead, use pod identities to automatically request access using a central Azure AD identity solution. 適用於 Linux 的 pod 和容器映像只是 pod 身分識別。Pod identities is intended for use with Linux pods and container images only.

當 Pod 需要存取其他 Azure 服務時 (例如 Cosmos DB、Key Vault 或 Blob 儲存體),Pod 將需要存取認證。When pods need access to other Azure services, such as Cosmos DB, Key Vault, or Blob Storage, the pod needs access credentials. 這些存取認證可以使用容器映像來定義或插入作為 Kubernetes 祕密,但必須以手動方式建立並指派。These access credentials could be defined with the container image or injected as a Kubernetes secret, but need to be manually created and assigned. 認證通常會跨 Pod 重複使用,而不會定期輪替。Often, the credentials are reused across pods, and aren't regularly rotated.

適用於 Azure 資源 (目前實作為相關聯的 AKS 開放原始碼專案) 的受管理身分識別可讓您自動要求存取透過 Azure AD 的服務。Managed identities for Azure resources (currently implemented as an associated AKS open source project) let you automatically request access to services through Azure AD. 您不需手動定義 Pod 的認證,因為 Pod 會即時要求存取權杖,並且可用該權杖來存取其獲指派的服務。You don't manually define credentials for pods, instead they request an access token in real time, and can use it to access only their assigned services. 在 AKS 中,叢集操作員會部署兩個元件,讓 Pod 能夠使用受控識別:In AKS, two components are deployed by the cluster operator to allow pods to use managed identities:

  • 節點管理身分識別 (NMI) 伺服器是在 AKS 叢集中的每個節點上以 DaemonSet 形式執行的 Pod。The Node Management Identity (NMI) server is a pod that runs as a DaemonSet on each node in the AKS cluster. NMI 伺服器會接聽 Pod 對 Azure 服務的要求。The NMI server listens for pod requests to Azure services.
  • 受控識別控制器 (MIC) 是一個中央 Pod,有權查詢 Kubernetes API 伺服器,以及檢查對應至 Pod 的 Azure 身分識別對應。The Managed Identity Controller (MIC) is a central pod with permissions to query the Kubernetes API server and checks for an Azure identity mapping that corresponds to a pod.

當 Pod 要求存取 Azure 服務時,網路規則即會將流量重新導向至節點管理身分識別 (NMI) 伺服器。When pods request access to an Azure service, network rules redirect the traffic to the Node Management Identity (NMI) server. NMI 伺服器會根據 Pod 的遠端位址識別要求存取 Azure 服務的 Pod,並查詢受控識別控制器 (MIC)。The NMI server identifies pods that request access to Azure services based on their remote address, and queries the Managed Identity Controller (MIC). MIC 會檢查 AKS 叢集中的 Azure 身分識別對應,然後,NMI 伺服器會根據 Pod 的身分識別對應向 Azure Active Directory (AD) 要求存取權杖。The MIC checks for Azure identity mappings in the AKS cluster, and the NMI server then requests an access token from Azure Active Directory (AD) based on the pod's identity mapping. Azure AD 會將存取權提供給 NMI 伺服器,繼而傳回給 Pod。Azure AD provides access to the NMI server, which is returned to the pod. 此存取權杖隨後可供 Pod 用來要求存取 Azure 中的服務。This access token can be used by the pod to then request access to services in Azure.

在下列範例中,開發人員會建立一個使用受控識別來要求存取 Azure SQL Server 執行個體的 Pod:In the following example, a developer creates a pod that uses a managed identity to request access to an Azure SQL Server instance:

Pod 身分識別可讓 Pod 自動要求存取其他服務

  1. 叢集操作員首先建立在 Pod 要求存取服務時可用來對應身分識別的服務帳戶。Cluster operator first creates a service account that can be used to map identities when pods request access to services.
  2. 部署 NMI 伺服器和 MIC,以將 Pod 的任何存取權杖要求轉送至 Azure AD。The NMI server and MIC are deployed to relay any pod requests for access tokens to Azure AD.
  3. 開發人員使用受控識別部署了透過 NMI 伺服器要求存取權杖的 Pod。A developer deploys a pod with a managed identity that requests an access token through the NMI server.
  4. 權杖傳回至 Pod,並用來存取 Azure SQL Server 執行個體。The token is returned to the pod and used to access an Azure SQL Server instance.

注意

受管理的 pod 身分識別是開放原始碼專案,並不支援的 Azure 技術支援。Managed pod identities is an open source project, and is not supported by Azure technical support.

若要使用 pod 身分識別,請參閱Kubernetes 應用程式的 Azure Active Directory 身分識別To use pod identities, see Azure Active Directory identities for Kubernetes applications.

後續步驟Next steps

這篇最佳做法文章主要討論叢集和資源的驗證和授權。This best practices article focused on authentication and authorization for your cluster and resources. 若要實作這些最佳做法,請參閱下列文章:To implement some of these best practices, see the following articles:

如需 AKS 中叢集作業的相關詳細資訊,請參閱下列最佳作法:For more information about cluster operations in AKS, see the following best practices: