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

  • Článek
  • 8 min ke čtení

Při nasazování a údržbě clusterů v 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žitých k provádění změn může být obtížné.

V tomto článku probereme doporučené postupy, které může operátor clusteru dodržovat při správě přístupu a identit pro clustery AKS. Dozvíte se, jak:

  • Ověřování uživatelů clusteru AKS pomocí Azure Active Directory (Azure AD).
  • Řízení přístupu k prostředkům pomocí řízení přístupu na základě role v Kubernetes (Kubernetes RBAC).
  • Pomocí Azure RBAC můžete odstupňovaně řídit přístup k prostředku AKS, škálovatelnému rozhraní API Kubernetes a kubeconfig.
  • Spravovanou identitu použijte k ověřování podů s jinými službami.

Použití Azure Active Directory (Azure AD)

Osvědčené postupy

Nasazení clusterů AKS s Azure AD integrací Použití Azure AD centralizuje vrstvu správy identit. Jakákoli změna stavu uživatelského účtu nebo skupiny se automaticky aktualizuje v přístupu ke clusteru AKS. Pomocí rolí, rolí clusteru nebo vazeb můžete nastavit rozsah uživatelů nebo skupin na minimální úroveň oprávnění.

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é interagovat. Místo toho můžete cluster integrovat s existujícím řešením identit, jako je Azure AD, řešení pro správu identit připravené pro podniky.

S Azure AD integrovanými clustery v AKS vytvoříte role nebo role clusteru definující přístupová oprávnění k prostředkům. Role pak vytvoříte vazbu k uživatelům nebo skupinám z Azure AD. Další informace o řízení přístupu na základě role Kubernetes najdete v další části. Azure AD integraci a způsob řízení přístupu k prostředkům můžete vidět v následujícím diagramu:

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

  1. Vývojář se ověřuje pomocí Azure AD.
  2. Koncový bod vystavování tokenu Azure AD vydá přístupový token.
  3. Vývojář provede akci pomocí tokenu Azure AD, například kubectl create pod.
  4. Kubernetes ověří token pomocí Azure AD a načte členství ve skupinách vývojářů.
  5. Používají se zásady RBAC a clusteru Kubernetes.
  6. Žádost vývojáře je úspěšná na základě předchozího ověření členství ve skupině Azure AD a řízení přístupu na základě role a zásad Kubernetes.

Informace o vytvoření clusteru AKS, který používá Azure AD, najdete v tématu Integrace Azure Active Directory s AKS.

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

Osvědčené postupy

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í nejmenší požadovaný počet požadovaných oprávnění. Integrací s Azure AD můžete automaticky aktualizovat stav uživatele nebo změnu členství ve skupinách a udržovat aktuální přístup k prostředkům clusteru.

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 s jakými oprávněními. Tyto role pak použijete pro uživatele nebo skupiny s vazbou. Další informace o rolích, rolích clusteru a vazbách najdete v tématu Možnosti přístupu a identit pro Azure Kubernetes Service (AKS).

Například vytvoříte roli s úplným přístupem k prostředkům v oboru názvů 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 role a vytvoříte vazbu uživatele Azure ADdeveloper1@contoso.com, 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

Když developer1@contoso.com se ověří v clusteru AKS, mají úplná oprávnění k prostředkům v oboru názvů aplikace finance-app . Tímto způsobem logicky oddělujete a řídíte přístup k prostředkům. Použijte Kubernetes RBAC s Azure AD integrací.

Informace o tom, jak pomocí Azure AD skupin řídit přístup 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 Azure Active Directory v AKS.

Použití Azure RBAC

Osvědčené postupy

Pomocí Azure RBAC můžete definovat minimální požadovaná uživatelská a skupinová oprávnění k prostředkům AKS v jednom nebo několika 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 k , najdete v kubeconfigtématu Omezení přístupu ke konfiguračnímu souboru clusteru.

  • Přístup k rozhraní API Kubernetes.

    Tato úroveň přístupu je řízena:

    • Kubernetes RBAC (tradičně) nebo
    • Integrací Azure RBAC s AKS pro autorizaci Kubernetes.

    Informace o podrobném udělení oprávnění rozhraní Kubernetes API pomocí Azure RBAC najdete v tématu Použití Azure RBAC pro autorizaci Kubernetes.

Použití identit spravovaných pody

Osvědčené postupy

V podech nebo imagích kontejnerů nepoužívejte pevné přihlašovací údaje, protože u nich hrozí ohrožení nebo zneužití. Místo toho použijte identity podů k automatickému vyžádání přístupu pomocí Azure AD.

Poznámka

Identity podů jsou určené pouze pro použití s linuxovými pody a imagemi kontejnerů. Podpora identit spravovaných pody pro kontejnery Windows bude brzy k dispozici.

Pro 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 můžete vložit jako tajný klíč Kubernetes. V každém případě byste je museli vytvořit a přiřadit ručně. Tyto přihlašovací údaje se obvykle opakovaně používají napříč pody a pravidelně se neoměňují.

S identitami spravovanými pody (Preview) pro prostředky Azure automaticky požádáte o přístup ke službám prostřednictvím Azure AD. Identity spravované pody jsou aktuálně ve verzi Preview pro AKS. Pokud chcete začít, projděte si dokumentaci k používání identit spravovaných pody služby Azure Active Directory v Azure Kubernetes Service (Preview).

Poznámka

Pokud jste v clusteru AKS povolili Azure AD identitu spravovanou pody nebo uvažujete o jejím implementaci, doporučujeme, abyste si nejdřív prostudovali článek přehledu identit úloh, abyste porozuměli našim doporučením a možnostem nastavení clusteru tak, aby používal identitu Azure AD úlohy (Preview). Tato metoda ověřování nahrazuje identitu spravovanou podem (Preview), která se integruje s nativními možnostmi Kubernetes a umožňuje federaci se všemi externími zprostředkovateli identity.

K 24. 10. 2022 je open source Azure AD spravovaná identita podem (Preview) v Azure Kubernetes Service zastaralá.

Identita spravovaná podem v Azure Active Directory (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ž mic zjistí relevantní změnu, podle potřeby přidá nebo odstraní azureAssignedIdentity . Konkrétně když je naplánovaný pod, mic přiřadí spravovanou identitu v Azure základní škálovací sadě virtuálních počítačů používané fondem uzlů během fáze vytváření. Když se odstraní všechny pody, které identitu používají, odebere se identita ze škálovací sady virtuálních počítačů fondu uzlů, pokud stejnou spravovanou identitu nepoužívají jiné pody. Mic provede podobné akce při vytvoření nebo odstranění AzureIdentity Nebo AzureIdentityBinding.

    • Spravovaná identita uzlu (NMI): pod, který běží jako daemonSet na každém uzlu v clusteru AKS. NMI zachytává požadavky na tokeny zabezpečení na službu 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 které požaduje token, a načte token z tenanta Azure Active Directory jménem aplikace.

  • Spravovaný režim: V tomto režimu je k dispozici pouze NMI. Identitu musí ručně přiřadit a spravovat uživatel. Další informace najdete v tématu Identita podu 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 parametrem--namespace, 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čů každého fondu uzlů v clusteru AKS.

Poznámka

Pokud se místo toho rozhodnete nainstalovat identitu spravovanou podem Azure Active Directory pomocí doplňku clusteru AKS, instalační program použije 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čů fondu uzlů může trvat až 40 až 60 let. 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 do škálovací sady virtuálních počítačů používané clusterem AKS a Managed Identity Operator oprávnění ke spravovaným identitám přiřazeným uživatelem. Při spuštění v managed modenástroji není k dispozici žádný mikrofon, a proto se přiřazení rolí 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 používají ho k přístupu pouze k přiřazeným prostředkům. V AKS existují dvě komponenty, které zpracovávají operace, které umožňují podům 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 serveru rozhraní Kubernetes API a zkontroluje mapování identity Azure, které odpovídá podu.

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

  1. Server NMI:

    • Identifikuje pody, které požadují přístup k prostředkům Azure na základě jejich vzdálené adresy.
    • Dotazuje poskytovatele prostředků Azure.

  2. Poskytovatel prostředků Azure kontroluje mapování identit Azure v clusteru AKS.

  3. Server NMI požaduje přístupový token z Azure AD na základě mapování identit podu.

  4. Azure AD 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 vývojář vytvoří pod, který pomocí spravované identity požádá o přístup k Azure SQL Database:

Identity podů umožňují podu automaticky požádat o přístup k dalším prostředkům.

  1. Operátor clusteru vytvoří účet služby pro mapování identit, když pody požadují přístup k prostředkům.
  2. Server NMI se nasadí, aby předával všechny požadavky podů společně s poskytovatelem prostředků Azure na přístupové tokeny k Azure AD.
  3. Vývojář nasadí pod se spravovanou identitou, která vyžaduje přístupový token prostřednictvím serveru NMI.
  4. Token se vrátí do podu a použije se pro přístup k databázi Azure SQL.

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

Další kroky

Tento článek o osvědčených postupech se zaměřil na ověřování a autorizaci pro váš cluster a prostředky. Pokud chcete implementovat některé z těchto osvědčených postupů, přečtě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: