Osvědčené postupy pro ověřování a autorizaci ve službě Azure Kubernetes (AKS)Best practices for authentication and authorization in Azure Kubernetes Service (AKS)

Při nasazení a údržbě clusterů ve službě Azure Kubernetes Service (AKS) implementujete způsoby správy přístupu k prostředkům a službám.As you deploy and maintain clusters in Azure Kubernetes Service (AKS), you implement ways to manage access to resources and services. Bez těchto ovládacích prvků:Without these controls:

  • Účty můžou mít přístup k zbytečným prostředkům a službám.Accounts could have access to unnecessary resources and services.
  • Sledování, kterou sadu přihlašovacích údajů bylo použito k provedení změn, může být obtížné.Tracking which set of credentials were used to make changes could be difficult.

Tento článek o osvědčených postupech se zaměřuje na to, jak operátor clusteru může spravovat přístup a identitu pro clustery AKS.This best practices article focuses on how a cluster operator can manage access and identity for AKS clusters. V tomto článku získáte informace o těchto tématech:In this article, you learn how to:

  • Ověřte uživatele clusteru AKS pomocí Azure Active Directory.Authenticate AKS cluster users with Azure Active Directory.
  • Řízení přístupu k prostředkům pomocí Kubernetes řízení přístupu založeného na rolích (Kubernetes RBAC).Control access to resources with Kubernetes role-based access control (Kubernetes RBAC).
  • Využijte Azure RBAC k podrobnému řízení přístupu k AKS prostředku, Kubernetes rozhraní API ve velkém měřítku a kubeconfig .Use Azure RBAC to granularly control access to the AKS resource, the Kubernetes API at scale, and the kubeconfig.
  • Pomocí spravované identity můžete sami ověřit své lusky s ostatními službami.Use a managed identity to authenticate pods themselves with other services.

Použití Azure Active Directory (Azure AD)Use Azure Active Directory (Azure AD)

Osvědčené postupyBest practice guidance

Nasaďte clustery AKS s integrací služby Azure AD.Deploy AKS clusters with Azure AD integration. Pomocí Azure AD se soustřeďuje na součást správy identit.Using Azure AD centralizes the identity management component. Všechny změny v uživatelském účtu nebo skupině se automaticky aktualizují v rámci přístupu ke clusteru AKS.Any change in user account or group status is automatically updated in access to the AKS cluster. Rozsah uživatelů nebo skupin na minimální počet oprávnění pomocí rolí, ClusterRoles nebo vazebScope users or groups to the minimum permissions amount using Roles, ClusterRoles, or Bindings.

Vývojáři clusteru Kubernetes a vlastníci aplikací potřebují přístup k různým prostředkům.Your Kubernetes cluster developers and application owners need access to different resources. Kubernetes nemá řešení pro správu identit, které vám umožní řídit prostředky, se kterými můžou uživatelé pracovat.Kubernetes lacks an identity management solution for you to control the resources with which users can interact. Místo toho se cluster obvykle integruje s existujícím řešením identity.Instead, you typically integrate your cluster with an existing identity solution. Zadejte Azure AD: řešení pro správu identit připravené na podnik, které se integruje s AKS clustery.Enter Azure AD: an enterprise-ready identity management solution that integrates with AKS clusters.

Clustery s integrovanými službami Azure AD v AKS umožňují vytvářet role nebo ClusterRoles definující přístupová oprávnění k prostředkům.With Azure AD-integrated clusters in AKS, you create Roles or ClusterRoles defining access permissions to resources. Pak budete role navazovat na uživatele nebo skupiny z Azure AD.You then bind the roles to users or groups from Azure AD. Další informace o těchto Kubernetes RBAC najdete v Další části.Learn more about these Kubernetes RBAC in the next section. Integrace Azure AD a jak řídit přístup k prostředkům, najdete v následujícím diagramu:Azure AD integration and how you control access to resources can be seen in the following diagram:

Ověřování na úrovni clusteru pro integraci Azure Active Directory s AKS

  1. Vývojář se ověřuje pomocí Azure AD.Developer authenticates with Azure AD.
  2. Koncový bod pro vystavení tokenu Azure AD vydá přístupový token.The Azure AD token issuance endpoint issues the access token.
  3. Vývojář provede akci pomocí tokenu Azure AD, jako je například kubectl create pod .The developer performs an action using the Azure AD token, such as kubectl create pod.
  4. Kubernetes ověří token ve službě Azure AD a načte členství ve skupině vývojářů.Kubernetes validates the token with Azure AD and fetches the developer's group memberships.
  5. Kubernetes RBAC a zásady clusteru se aplikují.Kubernetes RBAC and cluster policies are applied.
  6. Žádost vývojáře je úspěšná na základě předchozího ověření členství ve skupině Azure AD a Kubernetes RBAC a zásady.Developer's request is successful based on previous validation of Azure AD group membership and Kubernetes RBAC and policies.

Pokud chcete vytvořit cluster AKS, který používá Azure AD, přečtěte si téma věnované integraci Azure Active Directory s AKS.To create an AKS cluster that uses Azure AD, see Integrate Azure Active Directory with AKS.

Použití řízení přístupu založeného na rolích Kubernetes (Kubernetes RBAC)Use Kubernetes role-based access control (Kubernetes RBAC)

Osvědčené postupyBest practice guidance

Definujte oprávnění uživatele nebo skupiny pro prostředky clusteru s Kubernetes RBAC.Define user or group permissions to cluster resources with Kubernetes RBAC. Vytvořte role a vazby, které přiřadí minimální počet požadovaných oprávnění.Create roles and bindings that assign the least amount of permissions required. Integrací se službou Azure AD můžete automaticky aktualizovat všechny stavy uživatelů nebo změny členství ve skupinách a zachovat přístup k prostředkům clusteru v aktuálním stavu.Integrate with Azure AD to automatically update any user status or group membership change and keep access to cluster resources current.

V Kubernetes poskytujete podrobné řízení přístupu k prostředkům clusteru.In Kubernetes, you provide granular access control to cluster resources. Můžete definovat oprávnění na úrovni clusteru nebo konkrétní obory názvů.You define permissions at the cluster level, or to specific namespaces. Určíte, které prostředky se dají spravovat a s jakými oprávněními.You determine what resources can be managed and with what permissions. Tyto role pak můžete použít pro uživatele nebo skupiny s vazbou.You then apply these roles to users or groups with a binding. Další informace o rolích, ClusterRoles a vazbách najdete v tématu Možnosti přístupu a identit pro Azure Kubernetes Service (AKS).For more information about Roles, ClusterRoles, and Bindings, see Access and identity options for Azure Kubernetes Service (AKS).

Jako příklad můžete vytvořit roli s úplným přístupem k prostředkům v oboru názvů s názvem finance-App, jak je znázorněno v následujícím příkladu manifestu YAML:As an example, you create a role with 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: ["*"]

Pak vytvoříte RoleBinding a svážete uživatele Azure AD developer1 @ contoso.com s RoleBinding, jak je znázorněno v následujícím manifestu YAML:You then create a RoleBinding and bind 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

Pokud se developer1 @ contoso.com ověřuje v rámci clusteru AKS, mají úplná oprávnění k prostředkům v oboru názvů finance-aplikace .When developer1@contoso.com is authenticated against the AKS cluster, they have full permissions to resources in the finance-app namespace. Tímto způsobem můžete logicky oddělit a řídit přístup k prostředkům.In this way, you logically separate and control access to resources. Kubernetes RBAC používejte ve spojení s Azure AD – integrací.Use Kubernetes RBAC in conjunction with Azure AD-integration.

Pokud chcete zjistit, jak používat skupiny Azure AD k řízení přístupu k prostředkům Kubernetes pomocí Kubernetes RBAC, přečtěte si téma řízení přístupu k prostředkům clusteru pomocí řízení přístupu na základě rolí a Azure Active Directory identit v AKS.To see how to use Azure AD groups to control access to Kubernetes resources using Kubernetes RBAC, see Control access to cluster resources using role-based access control and Azure Active Directory identities in AKS.

Použití Azure RBACUse Azure RBAC

Osvědčené postupyBest practice guidance

Pomocí Azure RBAC definujte minimální požadovaná oprávnění uživatelů a skupin pro AKS prostředků v jednom nebo několika předplatných.Use Azure RBAC to define the minimum required user and group permissions to AKS resources in one or more subscriptions.

Existují dvě úrovně přístupu, které jsou potřeba k plnému provozu clusteru AKS:There are two levels of access needed to fully operate an AKS cluster:

  1. Přístup k prostředku AKS ve vašem předplatném Azure.Access the AKS resource on your Azure subscription.

    Tato úroveň přístupu vám umožní:This access level allows you to:

    • Řízení škálování nebo upgrade clusteru pomocí rozhraní API AKSControl scaling or upgrading your cluster using the AKS APIs
    • Vyžádání kubeconfig .Pull your kubeconfig.

    Chcete-li zjistit, jak řídit přístup k AKS prostředku a kubeconfig , najdete informace v části omezení přístupu ke konfiguračnímu souboru clusteru.To see how to control access to the AKS resource and the kubeconfig, see Limit access to cluster configuration file.

  2. Přístup k rozhraní Kubernetes API.Access to the Kubernetes API.

    Tato úroveň přístupu se řídí těmito možnostmi:This access level is controlled either by:

    • KUBERNETES RBAC (tradičně) neboKubernetes RBAC (traditionally) or
    • Integrací Azure RBAC s AKS pro autorizaci Kubernetes.By integrating Azure RBAC with AKS for kubernetes authorization.

    Pokud chcete zjistit, jak členit oprávnění k rozhraní Kubernetes API pomocí Azure RBAC, přečtěte si téma použití Azure RBAC pro autorizaci Kubernetes.To see how to granularly give permissions to the Kubernetes API using Azure RBAC, see Use Azure RBAC for Kubernetes authorization.

Použití identit pod správouUse Pod-managed Identities

Osvědčené postupyBest practice guidance

Nepoužívejte pevná pověření v rámci lusků nebo imagí kontejnerů, protože jsou ohrožena ozářením nebo zneužitím.Don't use fixed credentials within pods or container images, as they are at risk of exposure or abuse. Místo toho použijte identity pod , pokud chcete automaticky požádat o přístup pomocí centrálního řešení identit Azure AD.Instead, use pod identities to automatically request access using a central Azure AD identity solution.

Poznámka

Identity pod jsou určené pro použití jenom pro systémy Linux a image kontejnerů.Pod identities are intended for use with Linux pods and container images only. Už brzy bude dostupná podpora identit pod správou pro kontejnery Windows.Pod-managed identities support for Windows containers is coming soon.

Pro přístup k jiným službám Azure, jako je Cosmos DB, Key Vault nebo Blob Storage, musí mít přístup k přihlašovacím údajům.To access other Azure services, like Cosmos DB, Key Vault, or Blob Storage, the pod needs access credentials. Můžete definovat přístupová pověření pomocí Image kontejneru nebo je vložit jako tajný kód Kubernetes.You could define access credentials with the container image or inject them as a Kubernetes secret. V obou případech byste je museli vytvořit a přiřadit ručně.Either way, you would need to manually create and assign them. Obvykle se tyto přihlašovací údaje použijí v různých luskech a nejsou pravidelně otočeny.Usually, these credentials are reused across pods and aren't regularly rotated.

S využitím identit pod správou pro prostředky Azure automaticky vyžádáte přístup ke službám přes Azure AD.With pod-managed identities for Azure resources, you automatically request access to services through Azure AD. Identity pod správou teď jsou nyní ve verzi Preview pro AKS.Pod-managed identities is now currently in preview for AKS. Další informace najdete v tématu [použití Azure Active Directory pod správou identit ve službě Azure Kubernetes (Preview) [( https://docs.microsoft.com/azure/aks/use-azure-ad-pod-identity) dokumentace pro začátek.Please refer to the [Use Azure Active Directory pod-managed identities in Azure Kubernetes Service (Preview)[( https://docs.microsoft.com/azure/aks/use-azure-ad-pod-identity) documentation to get started.

Místo ručního definování přihlašovacích údajů pro lusky se v reálném čase požádají o přístupový token, a to pomocí něj získat přístup jenom k jim přiřazeným službám.Instead of manually defining credentials for pods, pod-managed identities request an access token in real time, using it to access only their assigned services. V AKS jsou k dispozici dvě komponenty, které zpracovávají operace a umožňují použití spravovaných identit v luskech:In AKS, there are two components that handle the operations to allow pods to use managed identities:

  • Server NMI (Node Management identity) je pod tím, který se spouští jako DaemonSet na každém uzlu v clusteru AKS.The Node Management Identity (NMI) server is a pod that runs as a DaemonSet on each node in the AKS cluster. Server NMI čeká na služby Azure na požadavky pod.The NMI server listens for pod requests to Azure services.
  • Poskytovatel prostředků Azure se dotáže serveru rozhraní Kubernetes API a ověří mapování identit Azure, které odpovídá poli pod.The Azure Resource Provider queries the Kubernetes API server and checks for an Azure identity mapping that corresponds to a pod.

Když lusky požadují přístup ke službě Azure, Síťová pravidla přesměrují provoz na server NMI.When pods request access to an Azure service, network rules redirect the traffic to the NMI server.

  1. Server NMI:The NMI server:
    • Identifikuje lusky požadující přístup ke službám Azure na základě jejich vzdálené adresy.Identifies pods requesting access to Azure services based on their remote address.
    • Zadá dotaz na poskytovatele prostředků Azure.Queries the Azure Resource Provider.
  2. Poskytovatel prostředků Azure kontroluje mapování identit Azure v clusteru AKS.The Azure Resource Provider checks for Azure identity mappings in the AKS cluster.
  3. Server NMI požádá o přístupový token ze služby Azure AD na základě mapování totožnosti pod.The NMI server requests an access token from Azure AD based on the pod's identity mapping.
  4. Azure AD poskytuje přístup k serveru NMI, který je vrácen do pod.Azure AD provides access to the NMI server, which is returned to the pod.
    • Přístup k tomuto přístupovému tokenu může použít ta pod tím, že bude vyžadovat přístup ke službám v Azure.This access token can be used by the pod to then request access to services in Azure.

V následujícím příkladu Vývojář vytvoří pod, který používá spravovanou identitu k vyžádání přístupu k Azure SQL Database:In the following example, a developer creates a pod that uses a managed identity to request access to Azure SQL Database:

Identity pod umožňují automatické vyžádání přístupu k jiným službám.

  1. Operátor clusteru vytvoří účet služby pro mapování identit, když lusky požadují přístup ke službám.Cluster operator creates a service account to map identities when pods request access to services.
  2. Server NMI je nasazený pro předávání všech požadavků pod a poskytovatele prostředků Azure pro přístupové tokeny do Azure AD.The NMI server is deployed to relay any pod requests, along with the Azure Resource Provider, for access tokens to Azure AD.
  3. Vývojář nasadí pod spravovanou identitou, která žádá o přístupový token prostřednictvím serveru NMI.A developer deploys a pod with a managed identity that requests an access token through the NMI server.
  4. Token se vrátí do pole pod a používá se pro přístup k Azure SQL DatabaseThe token is returned to the pod and used to access Azure SQL Database

Poznámka

Identity pod správou jsou aktuálně ve stavu Preview.Pod-managed identities is currently in preview status.

Pokud chcete používat spravované identity pod správou, přečtěte si téma použití Azure Active Directory pod správou identit ve službě Azure Kubernetes (Preview).To use Pod-managed identities, see Use Azure Active Directory pod-managed identities in Azure Kubernetes Service (Preview).

Další krokyNext steps

Tento článek s osvědčenými postupy se zaměřuje na ověřování a autorizaci pro váš cluster a prostředky.This best practices article focused on authentication and authorization for your cluster and resources. Chcete-li implementovat některé z těchto doporučených postupů, přečtěte si následující články:To implement some of these best practices, see the following articles:

Další informace o operacích clusteru v AKS najdete v následujících osvědčených postupech:For more information about cluster operations in AKS, see the following best practices: