Koncepty ověřování clusteru ve službě Azure Kubernetes Service (AKS)

Tento článek popisuje, jak Azure Kubernetes Service (AKS) ověřuje volající v rozhraní Kubernetes API – to znamená, kdo se může připojit k řídicí rovině. Tento text zahrnuje doporučený postup ověřování založený na Microsoft Entra ID a jak uzamknout nouzový přístup.

Informace o tom, jak AKS vyhodnotí, co může ověřený volající dělat, najdete v tématu Koncepty autorizace clusteru.

Další scénáře identit v AKS najdete tady:

Orientaci ve všech čtyřech scénářích identit AKS najdete v tématu Možnosti přístupu a identity pro AKS.

Ověření na serveru rozhraní API Kubernetes (řídicí rovina)

Samotný Kubernetes neposkytuje adresář identity. Bez externího zprostředkovatele identity byste museli spravovat místní přihlašovací údaje na každý cluster, což neškáluje a vytváří mezery v auditu.

Doporučujeme nasadit clustery AKS s ověřováním Microsoft Entra ID pro řídicí rovinu. S touto integrací cluster ověřuje příchozí požadavky rozhraní Kubernetes API na ID Microsoft Entra a používá identitu Entra volajícího k rozhodování o autorizaci. Microsoft Entra ID centralizuje vrstvu identity – jakákoli změna stavu uživatele nebo skupiny se automaticky projeví v přístupu ke clusteru – a umožňuje podmíněný přístup, vícefaktorové ověřování a Privileged Identity Management.

Diagram znázorňující integraci Microsoft Entra s clustery AKS pro ověřování

Pro nastavení se podívejte na Povolení ověřování Microsoft Entra ID pro řídicí rovinu AKS. Je potřeba upozornit na následující:

  • Tenant Microsoft Entra nakonfigurovaný pro ověřování clusteru musí být stejný jako tenant předplatného, které obsahuje cluster AKS.
  • Pro neinteraktivní přihlášení nebo starší kubectl verze použijte modul kubelogin plug-in.

Externí zprostředkovatelé identit (Preview)

Některé organizace potřebují ověřovat uživatele clusteru pomocí jiného zprostředkovatele identity kompatibilního s OIDC než Microsoft Entra ID , například GitHub, Google Workspace, Okta nebo poskytovatele identity v místním prostředí. AKS to podporuje prostřednictvím strukturovaného ověřování, které konfiguruje ověřovací nástroje JWT serveru Kubernetes tak, aby ověřily tokeny vydané vaším externím poskytovatelem.

Tuto možnost použijte pouze v případě, že máte pevný požadavek na zachování identity clusteru mimo Microsoft Entra ID. Jinak preferujte cestu ID Microsoft Entra pro rozsáhlejší integraci s podmíněným přístupem, vícefaktorovým ověřováním a Privileged Identity Management.

Přehled najdete v tématu Ověřování externího zprostředkovatele identity pro clustery AKS. Informace o nastavení najdete v tématu Konfigurace externích zprostředkovatelů identity se strukturovaným ověřováním AKS.

Zakázání místních účtů

Místní účty používají integrovaný certifikát správce clusteru, který obchází ID Microsoft Entra. Kterýkoli volající, který může tyto přihlašovací údaje zobrazit, získá plný přístup správce clusteru bez využití služby Entra ID, což naruší centralizovaný audit, podmíněný přístup a Privileged Identity Management. V produkčním prostředí zakažte místní účty, aby všechny přístupy procházely přes ID Microsoft Entra.

Pokud chcete toto vynutit ve velkém měřítku napříč mnoha clustery, přiřaďte integrovanou zásadu Azure Policy clustery Azure Kubernetes Service by měly mít zakázané místní metody ověřování na úrovni předplatného nebo skupiny pro správu. Zásady auditují nebo odepře clustery, které se vytvářejí nebo aktualizují s povolenými místními účty. Úplný seznam předdefinovaných zásad souvisejících se službou AKS najdete v tématu Předdefinované definice služby Azure Policy pro AKS.

Podrobnosti najdete v tématu Správa místních účtů v AKS.

Ověřování na uzlech clusteru

Režimy přístupu SSH

Kromě ověřování v rozhraní Kubernetes API možná budete muset provést ověření přímo na uzlu přes SSH, abyste mohli řešit potíže. AKS podporuje tři režimy přístupu SSH, které nastavíte pro každý cluster nebo fond uzlů:

  • Zakázané SSH (Preview): Zablokuje přístup SSH k uzlům úplně. Doporučuje se pro produkční prostředí, kde se přístup na úrovni uzlu řídí pouze prostřednictvím kubectl debug nebo jiných cest nativních pro Kubernetes.
  • Microsoft Entra ID SSH (Preview): Přihlaste se k uzlům pomocí identit Microsoft Entra bez klíčů SSH ke správě. Tento režim je konzistentní se zbytkem ověřování clusteru: dědí podmíněný přístup a vícefaktorové ověřování z ID Entra, podporuje zvýšení oprávnění za běhu prostřednictvím Azure RBAC a Privileged Identity Management a centralizuje audit prostřednictvím protokolů přihlašování k ID Entra.
  • Místní uživatel SSH: Tradiční přístup založený na klíči SSH. Tuto možnost použijte jenom v případě, že SSH založené na ID Entra není k dispozici, a klíče pravidelně obměňujte.

Postup nastavení a konfigurace pro jednotlivé režimy najdete v tématu Správa přístupu SSH na uzlech clusteru AKS.

Další kroky

  • Last updated on