Osvědčené postupy pro ověřování a autorizaci ve službě Azure Kubernetes Service (AKS)

Článek
02/16/2024

Při nasazování a správě clusterů ve službě Azure Kubernetes Service (AKS) implementujete způsoby správy přístupu k prostředkům a službám. Bez těchto ovládacích prvků:

Účty můžou mít přístup k nepotřebným prostředkům a službám.
Sledování přihlašovacích údajů používaných k provádění změn může být obtížné.

V tomto článku si probereme doporučené postupy, které může operátor clusteru použít ke správě přístupu a identity pro clustery AKS. Získáte následující informace:

Ověřte uživatele clusteru AKS pomocí ID Microsoft Entra.
Řízení přístupu k prostředkům pomocí řízení přístupu na základě role Kubernetes (Kubernetes RBAC)
Azure RBAC slouží k podrobnému řízení přístupu k prostředku AKS, rozhraní API Kubernetes ve velkém měřítku a kubeconfigrozhraní .
Použijte identitu úlohy pro přístup k prostředkům Azure z podů.

Upozorňující

Open source identita spravovaná podem Microsoft Entra (Preview) ve službě Azure Kubernetes Service je od 24. 10. 2022 zastaralá.

Pokud máte ve svém clusteru AKS povolenou identitu spravovanou podem Microsoft Entra nebo ji zvažujete, doporučujeme vám projít si článek s přehledem identit úloh a seznámit se s našimi doporučeními a možnostmi nastavení clusteru tak, aby používal ID úloh Microsoft Entra (Preview). Tato metoda ověřování nahrazuje identitu spravovanou podem (Preview), která se integruje s nativními funkcemi Kubernetes pro federaci se všemi externími zprostředkovateli identity.

Použití ID Microsoft Entra

Pokyny k osvědčeným postupům

Nasaďte clustery AKS s integrací Microsoft Entra. Použití Microsoft Entra ID centralizuje vrstvu správy identit. Jakákoli změna uživatelského účtu nebo stavu skupiny se automaticky aktualizuje v přístupu ke clusteru AKS. Nastavte rozsah uživatelů nebo skupin na minimální množství oprávnění pomocí rolí, rolí clusteru nebo vazeb.

Vývojáři clusteru Kubernetes a vlastníci aplikací potřebují přístup k různým prostředkům. Kubernetes nemá řešení pro správu identit, které vám umožní řídit prostředky, se kterými můžou uživatelé pracovat. Místo toho můžete cluster integrovat s existujícím řešením identity, jako je Microsoft Entra ID, řešení pro správu identit připravené pro podniky.

S integrovanými clustery Microsoft Entra v AKS vytvoříte role nebo role clusteru definující přístupová oprávnění k prostředkům. Potom svážete role s uživateli nebo skupinami z ID Microsoft Entra. Další informace o těchto RBAC Kubernetes najdete v další části. Integrace Microsoft Entra a způsob řízení přístupu k prostředkům najdete v následujícím diagramu:

Cluster-level authentication for Microsoft Entra integration with AKS

Vývojář se ověřuje pomocí ID Microsoft Entra.
Koncový bod vystavení tokenu Microsoft Entra vydává přístupový token.
Vývojář provede akci pomocí tokenu Microsoft Entra, například kubectl create pod.
Kubernetes ověří token pomocí ID Microsoft Entra a načte členství ve skupinách vývojářů.
Použijí se zásady RBAC a clusteru Kubernetes.
Požadavek vývojáře je úspěšný na základě předchozího ověření členství ve skupinách Microsoft Entra a zásad RBAC a Kubernetes.

Pokud chcete vytvořit cluster AKS, který používá ID Microsoft Entra, přečtěte si téma Integrace ID Microsoft Entra s AKS.

Použití řízení přístupu na základě role Kubernetes (Kubernetes RBAC)

Pokyny k osvědčeným postupům

Definujte oprávnění uživatele nebo skupiny k prostředkům clusteru pomocí RBAC Kubernetes. Vytvořte role a vazby, které přiřazují nejméně požadovaná oprávnění. Integrujte se službou Microsoft Entra ID, abyste automaticky aktualizovali všechny změny stavu uživatele nebo členství ve skupině a zachovali přístup k prostředkům clusteru v aktuálním stavu.

V Kubernetes poskytujete podrobné řízení přístupu k prostředkům clusteru. Oprávnění definujete na úrovni clusteru nebo pro konkrétní obory názvů. Určíte, jaké prostředky je možné spravovat a jaká oprávnění. Tyto role pak použijete u uživatelů nebo skupin s vazbou. Další informace o rolích, rolích clusteru a vazbách najdete v tématu Možnosti přístupu a identity pro službu Azure Kubernetes Service (AKS).

Například vytvoříte 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:

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

Potom vytvoříte vazbu RoleBinding a svážete s ním uživatele developer1@contoso.com Microsoft Entra, jak je znázorněno v následujícím manifestu YAML:

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

Při developer1@contoso.com ověřování v clusteru AKS mají úplná oprávnění k prostředkům v oboru názvů finance-app . Tímto způsobem logicky oddělujete a řídíte přístup k prostředkům. Použití RBAC Kubernetes s integrací ID Microsoft Entra

Informace o použití skupin Microsoft Entra k řízení přístupu k prostředkům Kubernetes pomocí RBAC Kubernetes najdete v tématu Řízení přístupu k prostředkům clusteru pomocí řízení přístupu na základě role a identit Microsoft Entra v AKS.

Použití Azure RBAC

Pokyny k osvědčeným postupům

Pomocí Azure RBAC definujte minimální požadovaná uživatelská a skupinová oprávnění k prostředkům AKS v jednom nebo více předplatných.

K plnému provozu clusteru AKS jsou potřeba dvě úrovně přístupu:

Získejte přístup k prostředku AKS ve vašem předplatném Azure.

Tato úroveň přístupu umožňuje:
- Řízení škálování nebo upgradu clusteru pomocí rozhraní API AKS
- Vytáhněte svůj kubeconfig.
Informace o řízení přístupu k prostředku AKS a kubeconfigzískáte v tématu Omezení přístupu ke konfiguračnímu souboru clusteru.
Přístup k rozhraní Kubernetes API

Tuto úroveň přístupu řídí:
- Kubernetes RBAC (tradičně) nebo
- Integrací Azure RBAC s AKS pro autorizaci Kubernetes
Informace o podrobném udělení oprávnění k rozhraní Kubernetes API pomocí Azure RBAC najdete v tématu Použití Azure RBAC pro autorizaci Kubernetes.

Použití identit spravovaných podem

Upozorňující

Open source identita spravovaná podem Microsoft Entra (Preview) ve službě Azure Kubernetes Service je od 24. 10. 2022 zastaralá.

Nepoužívejte pevné přihlašovací údaje v podech nebo imagích kontejnerů, protože jsou ohroženy vystavením nebo zneužitím. Místo toho použijte identity podů k automatickému vyžádání přístupu pomocí ID Microsoft Entra.

Pokud chcete získat přístup k dalším prostředkům Azure, jako je Azure Cosmos DB, Key Vault nebo Blob Storage, potřebuje pod přihlašovací údaje pro ověření. Přihlašovací údaje pro ověřování můžete definovat pomocí image kontejneru nebo je vložit jako tajný klíč Kubernetes. V obou směrech byste je museli vytvořit a přiřadit ručně. Obvykle se tyto přihlašovací údaje opakovaně používají napříč pody a nejsou pravidelně obměňovány.

S identitami spravovanými pody (Preview) pro prostředky Azure automaticky požádáte o přístup ke službám prostřednictvím ID Microsoft Entra. Identity spravované pody jsou aktuálně ve verzi Preview pro AKS. Informace o tom, jak začít, najdete v dokumentaci k používání identit spravovaných podem Microsoft Entra ve službě Azure Kubernetes Service (Preview).

Identita spravovaná podem Microsoft Entra (Preview) podporuje dva režimy provozu:

Standardní režim: V tomto režimu se do clusteru AKS nasadí následující 2 komponenty:
- Managed Identity Controller(MIC): Kontroler Kubernetes, který sleduje změny podů, AzureIdentity a AzureIdentityBinding prostřednictvím serveru rozhraní API Kubernetes. Když zjistí relevantní změnu, mic podle potřeby přidá nebo odstraní AzureAssignedIdentity . Konkrétně, když je pod naplánován, mic přiřadí spravovanou identitu v Azure k podkladové škálovací sadě virtuálních počítačů používané fondem uzlů během fáze vytváření. Když se odstraní všechny pody používající identitu, odebere identitu ze škálovací sady virtuálních počítačů fondu uzlů, pokud stejnou spravovanou identitu nepoužívají jiné pody. Mic provádí podobné akce, když se vytvoří nebo odstraní AzureIdentity nebo AzureIdentityBinding.
- Spravovaná identita uzlu (NMI): je pod, který běží jako daemonSet na každém uzlu v clusteru AKS. NMI zachytí požadavky na token zabezpečení do služby Azure Instance Metadata Service na každém uzlu. Přesměruje požadavky na sebe a ověří, jestli má pod přístup k identitě, pro kterou žádá token, a načte token z tenanta Microsoft Entra jménem aplikace.
Spravovaný režim: V tomto režimu je jenom NMI. Identitu musí uživatel přiřadit a spravovat ručně. Další informace najdete v tématu Identita podů ve spravovaném režimu. Když v tomto režimu použijete příkaz az aks pod-identity add k přidání identity podu do clusteru Azure Kubernetes Service (AKS), vytvoří azureIdentity a AzureIdentityBinding v oboru názvů určeném --namespace parametrem, zatímco poskytovatel prostředků AKS přiřadí spravovanou identitu určenou parametrem --identity-resource-id škálovací sadě virtuálních počítačů ve škálovací sadě jednotlivých fondů uzlů v clusteru AKS.

Poznámka:

Pokud se místo toho rozhodnete nainstalovat identitu spravovanou podem Microsoft Entra pomocí doplňku clusteru AKS, použije instalační program managed režim.

Režim managed poskytuje následující výhody oproti standard:

Přiřazení identity ve škálovací sadě virtuálních počítačů ve fondu uzlů může trvat 40 až 60s. U cronjobs nebo aplikací, které vyžadují přístup k identitě a nemůžou tolerovat zpoždění přiřazení, je nejlepší použít managed režim, protože identita je předem přiřazená ke škálovací sadě virtuálních počítačů fondu uzlů. Buď ručně, nebo pomocí příkazu az aks pod-identity add .
V standard režimu vyžaduje MIC oprávnění k zápisu ve škálovací sadě virtuálních počítačů používaných clusterem AKS a Managed Identity Operator oprávněním ke spravovaným identitám přiřazeným uživatelem. Když je spuštěný , managed modeprotože neexistuje žádný MIKROFON, přiřazení rolí se nevyžadují.

Místo ručního definování přihlašovacích údajů pro pody si identity spravované pody vyžádají přístupový token v reálném čase, a to pro přístup pouze k přiřazeným prostředkům. V AKS existují dvě komponenty, které zpracovávají operace, aby pody mohly používat spravované identity:

Server NMI (Node Management Identity) je pod, který běží jako daemonSet na každém uzlu v clusteru AKS. Server NMI naslouchá požadavkům podů na služby Azure.
Poskytovatel prostředků Azure se dotazuje na server rozhraní API Kubernetes a vyhledá mapování identit Azure, které odpovídá podu.

Když pody požadují token zabezpečení z ID Microsoft Entra pro přístup k prostředku Azure, pravidla sítě přesměrují provoz na server NMI.

Server NMI:
- Identifikuje pody požadující přístup k prostředkům Azure na základě jejich vzdálené adresy.
- Dotazuje poskytovatele prostředků Azure.
Poskytovatel prostředků Azure kontroluje mapování identit Azure v clusteru AKS.
Server NMI požaduje přístupový token z ID Microsoft Entra na základě mapování identit podu.
Id Microsoft Entra poskytuje přístup k serveru NMI, který se vrátí do podu.
- Tento přístupový token může pod použít k vyžádání přístupu k prostředkům v Azure.

V následujícím příkladu vytvoří vývojář pod, který použije spravovanou identitu k vyžádání přístupu ke službě Azure SQL Database:

Pod identities allow a pod to automatically request access to other resources.

Operátor clusteru vytvoří účet služby pro mapování identit, když pody požadují přístup k prostředkům.
Server NMI se nasadí tak, aby předával všechny požadavky podů společně s poskytovatelem prostředků Azure pro přístupové tokeny do Microsoft Entra ID.
Vývojář nasadí pod se spravovanou identitou, která prostřednictvím serveru NMI požádá o přístupový token.
Token se vrátí do podu a použije se pro přístup ke službě Azure SQL Database.

Pokud chcete používat identity spravované pody, přečtěte si téma Použití identit spravovaných podem Microsoftu ve službě Azure Kubernetes Service (Preview).

Další kroky

Tento článek s osvědčenými postupy se zaměřuje na ověřování a autorizaci clusteru a prostředků. Pokud chcete implementovat některé z těchto osvědčených postupů, projděte si následující články:

Další informace o operacích clusteru v AKS najdete v následujících osvědčených postupech: