Identita a přístup k úlohám Kubernetes

Tento článek popisuje, jak Amazon Elastic Kubernetes Service (Amazon EKS) a Azure Kubernetes Service (AKS) poskytují identitu pro úlohy Kubernetes pro přístup ke službám cloudové platformy. Podrobné porovnání identity a správy přístupu (IAM) Amazon Web Services (AWS) a MICROSOFT Entra ID najdete tady:

• Správa identit Microsoft Entra a správa přístupu pro AWS
• Mapování konceptů IAM AWS na podobné koncepty v Azure

Tato příručka vysvětluje, jak clustery AKS, integrované služby a doplňky používají spravované identity pro přístup k prostředkům Azure, jako jsou nástroje pro vyrovnávání zatížení a spravované disky. Tento článek také ukazuje, jak používat ID úloh Microsoft Entra, aby úlohy AKS mohly přistupovat k prostředkům Azure bez nutnosti připojovací řetězec, přístupového klíče nebo přihlašovacích údajů uživatele.

Správa identit a přístupu Amazon EKS

Amazon Elastic Kubernetes Service (EKS) poskytuje nativní možnosti správy identit a přístupu v podech Kubernetes. Mezi tyto možnosti patří role IAM pro účty služeb a role propojené se službou Amazon EKS.

Role IAM pro účty služeb

Role IAM pro účty služeb umožňují přidružit role IAM k účtům služby Kubernetes. Toto přidružení poskytuje oprávnění AWS ke kontejnerům v libovolném podu, který využívá účet služby. Výhody používání rolí IAM pro účty služeb jsou následující:

• nejnižších oprávnění: Ke účtu služby můžete přiřadit konkrétní oprávnění IAM a zajistit tak, aby k těmto oprávněním měli přístup jenom pody používající tento účet služby. Tím se eliminuje nutnost udělit rozšířená oprávnění pro roli IAM uzlu pro všechny pody na uzlu, což poskytuje bezpečnější a podrobnější přístup. Kromě toho tato funkce eliminuje potřebu řešení třetích stran, jako je kube2iam. Další informace najdete v tématu role IAM pro účty služeb.

• izolaci přihlašovacích údajů: Každý kontejner v podu může načíst přihlašovací údaje jenom pro roli IAM přidruženou k příslušnému účtu služby. Tato izolace zajišťuje, že kontejner nemá přístup k přihlašovacím údajům patřícím do jiného kontejneru v jiném podu.

• auditovatelnost: Amazon EKS využívá Amazon CloudTrail k poskytování přístupu a protokolování událostí, což usnadňuje zpětné auditování a dodržování předpisů.

Další informace o rolích IAM pro účty služeb najdete v oficiální dokumentaci .

Role propojené se službou Amazon EKS

Role propojené se službou Amazon EKS jsou jedinečné role IAM přímo propojené s Amazon EKS. Tyto předdefinované role zahrnují všechna potřebná oprávnění potřebná k volání služeb AWS jménem přidružené role. Hlavní role propojená se službou pro Amazon EKS je role role IAM uzlu Amazon EKS.

Uzel Amazon EKS kubelet démon využívá roli IAM uzlu Amazon EKS k volání rozhraní API ke službám AWS jménem uzlu. Profil instance IAM a přidružené zásady poskytují oprávnění pro tato volání rozhraní API. Toto nastavení zjednodušuje správu rolí IAM pro uzly v clusteru EKS.

Další informace o rolích propojených se službou Amazon EKS najdete v oficiální dokumentaci .

Další informace

Kromě rolí IAM pro účty služeb a role propojené se službou Amazon EKS existují další základní aspekty správy identit a přístupu v Amazon EKS.

1. autorizačníRBAC Amazonu EKS: Amazon EKS podporuje řízení přístupu na základě role (RBAC), které umožňuje definovat jemně odstupňovaná oprávnění pro prostředky Kubernetes v rámci clusteru.

2. AWS Identity and Access Management (IAM): IAM poskytuje komplexní řešení správy identit pro služby AWS, včetně EKS. Umožňuje vytvářet a spravovat uživatele, skupiny a role pro řízení přístupu k prostředkům EKS.

3. skupiny zabezpečení Amazon EKS: Amazon EKS umožňuje použít pravidla skupin zabezpečení na pody spuštěné v clusteru pro řízení příchozího a odchozího provozu.

Další podrobnosti o správě správy identit a přístupu v Amazon EKS najdete v oficiální dokumentaci k Amazon EKS.

Spravované identity clusteru AKS

Clustery Azure Kubernetes Service (AKS) vyžadují identitě Microsoft Entra pro přístup k prostředkům Azure, jako jsou nástroje pro vyrovnávání zatížení a spravované disky. Spravované identity pro prostředky Azure představují doporučený způsob autorizace přístupu z clusteru AKS k jiným službám Azure.

Co jsou spravované identity?

Běžným problémem pro vývojáře je správa tajných kódů, přihlašovacích údajů, certifikátů a klíčů používaných k zabezpečení komunikace mezi službami. spravovaných identit eliminovat potřebu vývojářů spravovat tyto přihlašovací údaje. Spravované identity umožňují ověřovat cluster AKS bez správy přihlašovacích údajů nebo jejich zahrnutí do kódu. Pomocí spravovaných identit přiřadíte identitě řízení přístupu na základě role v Azure (Azure RBAC) roli a udělíte jí oprávnění ke konkrétním prostředkům v Azure.

Tady jsou dva typy spravovaných identit:

• systémově přiřazené. Některé prostředky Azure, jako jsou virtuální počítače, umožňují povolit spravovanou identitu přímo na prostředku. Když povolíte spravovanou identitu přiřazenou systémem:

  • Instanční objekt speciálního typu se vytvoří v ID Microsoft Entra pro identitu. Instanční objekt je svázán s životním cyklem daného prostředku Azure. Když se prostředek Azure odstraní, Azure automaticky odstraní instanční objekt za vás.
  • Na základě návrhu může tuto identitu použít pouze prostředek Azure k vyžádání tokenů z ID Microsoft Entra.
  • Spravovanou identitu autorizujete tak, aby měla přístup k jedné nebo více službám.
  • Název instančního objektu přiřazeného systémem je vždy stejný jako název prostředku Azure, pro který je vytvořený.

• uživatelem přiřazené. Spravovanou identitu můžete vytvořit také jako samostatný prostředek Azure. Můžete vytvořit spravovanou identitu přiřazenou uživatelem a přiřadit ji k jednomu nebo několika prostředkům Azure. Když povolíte spravovanou identitu přiřazenou uživatelem:

  • Instanční objekt speciálního typu se vytvoří v ID Microsoft Entra pro identitu. Instanční objekt se spravuje odděleně od prostředků, které ho používají.
  • Identity přiřazené uživatelem můžou používat více prostředků.
  • Spravovanou identitu autorizujete tak, aby měla přístup k jedné nebo více službám.

Další informace o rozdílech mezi dvěma typy spravovaných identit najdete v tématu typy spravovaných identit.

Spravované identity ve službě Azure Kubernetes Service (AKS)

Tyto dva typy spravovaných identit jsou podobné tomu, že k autorizaci přístupu k prostředkům Azure z clusteru AKS můžete použít některý typ. Klíčovým rozdílem mezi nimi je, že spravovaná identita přiřazená systémem je přidružená k jednomu prostředku Azure, jako je cluster AKS, zatímco spravovaná identita přiřazená uživatelem je sama o sobě samostatným prostředkem Azure. Další podrobnosti o rozdílech mezi typy spravovaných identit najdete v tématu Typy spravovaných identit v spravovaných identitách pro prostředky Azure.

Existují tři typy spravovaných identit, které můžete použít s clusterem AKS:

1. spravovanou identitu přiřazenou systémem: Tento typ spravované identity je přidružený k jednomu prostředku Azure, jako je cluster AKS. Existuje pouze pro životní cyklus clusteru.

2. spravovaná identita přiřazená uživatelem: Spravovaná identita přiřazená uživatelem je samostatný prostředek Azure, který můžete použít k autorizaci přístupu k jiným službám Azure z clusteru AKS. Trvá odděleně od clusteru a může ho používat několik prostředků Azure.

3. předem vytvořená spravovaná identita kubeletu: Toto je volitelná identita přiřazená uživatelem, kterou může kubelet použít pro přístup k dalším prostředkům v Azure. Pokud pro kubelet není zadaná žádná spravovaná identita přiřazená uživatelem, AKS vytvoří identitu kubeletu přiřazenou uživatelem ve skupině prostředků uzlu.

Jak AKS používá spravované identity?

Když nasadíte cluster AKS, automaticky se pro vás vytvoří spravovaná identita přiřazená systémem . Můžete také vytvořit cluster s spravovanou identitou přiřazenou uživatelem. Cluster používá tuto spravovanou identitu k vyžádání tokenů z ID Microsoft Entra, které se pak používají k autorizaci přístupu k jiným prostředkům běžícím v Azure.

Přiřazením role Azure RBAC spravované identitě můžete udělit oprávnění clusteru pro přístup ke konkrétním prostředkům. Spravovanou identitu můžete například přiřadit roli Azure RBAC, která umožňuje přístup k tajným kódům ve službě Azure Key Vault. Tímto způsobem můžete snadno autorizovat přístup ke clusteru bez správy přihlašovacích údajů.

Použití spravovaných identit v AKS

Pokud používáte spravované identity v AKS, nemusíte zřizovat ani obměňovat tajné kódy. Azure spravuje přihlašovací údaje identity za vás. To vám umožní autorizovat přístup z vašich aplikací bez nutnosti spravovat další tajné kódy.

Pokud už máte cluster AKS, který používá spravovanou identitu, můžete ho aktualizovat na jiný typ spravované identity. Upozorňujeme však, že při přechodu komponent řídicí roviny na novou identitu může dojít ke zpoždění. Tento proces může trvat několik hodin a během této doby budou komponenty řídicí roviny nadále používat starou identitu, dokud jeho token nevyprší.

Souhrn spravovaných identit používaných službou AKS

AKS používá různé typy spravovaných identit k povolení různých integrovaných služeb a doplňků. Tady je souhrn spravovaných identit používaných službou AKS:

Další informace o spravovaných identitách v AKS najdete v tématu Použití spravované identity ve službě Azure Kubernetes Service.

ID úloh Microsoft Entra pro Kubernetes

ID úloh Microsoft Entra integruje s Kubernetes, aby úlohy nasazené v clusteru AKS mohly přistupovat k prostředkům chráněným Microsoft Entra, jako je Azure Key Vault a Microsoft Graph. Využívá možnosti nativní pro Kubernetes k federaci s externími zprostředkovateli identit. Další informace najdete v tématu Použití ID úlohy Microsoft Entra se službou Azure Kubernetes Service.

Pokud chcete použít ID úlohy Microsoft Entra, musíte nakonfigurovat účet služby v rámci Kubernetes. Tento účet služby pak pody používají k bezpečnému ověřování a přístupu k prostředkům Azure. ID úlohy Microsoft Entra funguje dobře s klientskými knihovnami Azure Identity nebo s kolekcí MSAL (Microsoft Authentication Library) spolu s registrací aplikace.

Pokud chcete plně využít ID úlohy Microsoft Entra v clusteru Kubernetes, musíte cluster AKS nakonfigurovat tak, aby vystavil tokeny a publikoval dokument zjišťování OIDC pro ověření tokenu. Další informace najdete v tématu Vytvoření zprostředkovatele OpenID Connect ve službě Azure Kubernetes Service.

Musíte také nakonfigurovat aplikace Microsoft Entra tak, aby důvěřovaly tokenům Kubernetes. Vývojáři pak můžou nakonfigurovat svá nasazení tak, aby používaly účty služby Kubernetes k získání tokenů, které se pak vyměňují za tokeny Microsoft Entra podle ID úlohy Microsoft Entra. Úlohy clusteru AKS můžou tyto tokeny Microsoft Entra používat k bezpečnému přístupu k chráněným prostředkům v Azure.

Jak je znázorněno na následujícím diagramu, cluster Kubernetes se stane vystavitelem tokenu zabezpečení, který vydává tokeny účtům služby Kubernetes. Tyto tokeny můžete nakonfigurovat tak, aby byly důvěryhodné pro aplikace Microsoft Entra. Tokeny je pak možné vyměnit za přístupové tokeny Microsoft Entra pomocí sad SDK pro identity Azure nebo knihovny MSAL (Microsoft Authentication Library).

1. Agent kubelet prodá token účtu služby pro úlohu v konfigurovatelné cestě k souboru.
2. Úloha Kubernetes odešle projektovaný token účtu podepsané služby do ID Microsoft Entra a požádá o přístupový token.
3. Microsoft Entra ID používá dokument zjišťování OIDC ke kontrole důvěryhodnosti u uživatelem definované spravované identity nebo registrované aplikace a ověření příchozího tokenu.
4. Id Microsoft Entra vydává přístupový token zabezpečení.
5. Úloha Kubernetes přistupuje k prostředkům Azure pomocí přístupového tokenu Microsoft Entra.

Další informace, dokumentaci a automatizaci související s ID úlohy Microsoft Entra najdete v následujících zdrojích informací:

• opensourcový projekt Identita úloh Azure
• Federace identit úloh
• ID úloh Microsoft Entra federace s Kubernetes
• ID úloh Microsoft Entra federace s externími zprostředkovateli identit OIDC
• Minimální federace ID úloh Microsoft Entra
• dokumentaci k ID úloh Microsoft Entra
• ID úloh Microsoft Entra rychlý start
• příklad : Použití ID úlohy Microsoft Entra pro Kubernetes se spravovanou identitou přiřazenou uživatelem v aplikaci .NET Standard

Ukázková úloha

Ukázková úloha spuštěná v clusteru AKS se skládá z front-endu a back-endové služby. Tyto služby používají ID úlohy Microsoft Entra pro přístup ke službám Azure, včetně služby Azure Key Vault, Azure Cosmos DB, účtu Azure Storage a oboru názvů služby Azure Service Bus. Pokud chcete nastavit tuto ukázku úlohy, musí být splněny následující požadavky:

1. Nastavte cluster AKS s vystavitelem OpenID Connect a ID úlohy Microsoft Entra povoleno.
2. Vytvořte účet služby Kubernetes v oboru názvů úloh.
3. Vytvořte spravovanou identitu přiřazenou uživatelem Microsoft Entra nebo zaregistrovanou aplikaci.
4. Vytvořte přihlašovací údaje federované identity mezi spravovanou identitou Microsoft Entra nebo zaregistrovanou aplikací a účtem služby úloh.
5. Přiřaďte nezbytné role s odpovídajícími oprávněními spravované identitě nebo registrované aplikaci Microsoft Entra.
6. Nasaďte úlohu a ověřte ověřování pomocí identity úlohy.

tok zpráv ID úloh Microsoft Entra

V tomto příkladu úlohy front-endové a back-endové aplikace získávají tokeny zabezpečení Microsoft Entra pro přístup ke službám Azure Platform as a Service (PaaS). Následující diagram znázorňuje tok zpráv:

Stáhněte si soubor aplikace Visio s touto architekturou.

1. Kubernetes vydá token podu, když je naplánovaný na uzlu na základě specifikace podu nebo nasazení.
2. Pod odešle token vydaný OIDC do Microsoft Entra ID a požádá o token Microsoft Entra pro konkrétní appId prostředek.
3. ID Microsoft Entra zkontroluje vztah důvěryhodnosti v aplikaci a ověří příchozí token.
4. Microsoft Entra ID vydává token zabezpečení: {sub: appId, aud: requested-audience}.
5. Pod používá token Microsoft Entra pro přístup k cílovému prostředku Azure.

Použití ID úloh Microsoft Entra kompletního použití v clusteru Kubernetes:

1. Cluster AKS nakonfigurujete tak, aby vystavil tokeny a publikovali dokument zjišťování OIDC, který umožňuje ověření těchto tokenů.
2. Aplikace Microsoft Entra nakonfigurujete tak, aby důvěřovaly tokenům Kubernetes.
3. Vývojáři nakonfigurují svá nasazení tak, aby používali účty služby Kubernetes k získání tokenů Kubernetes.
4. ID úloh Microsoft Entra vyměňují tokeny Kubernetes pro tokeny Microsoft Entra.
5. Úlohy clusteru AKS používají tokeny Microsoft Entra pro přístup k chráněným prostředkům, jako je Microsoft Graph.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

• Paul Salvatori | Instanční inženýr
• Martin Gjoshevski | Vedoucí servisní technik

Další přispěvatelé:

• Laura Nicolas | Vedoucí softwarový inženýr
• Chad Kittel | Hlavní softwarový inženýr
• Ed Price | Vedoucí programový manažer obsahu
• Theano Petersen | Technický spisovatel

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

• AKS pro odborníky na Amazon EKS
• Monitorování a protokolování Kubernetes
• Zabezpečení síťového přístupu k Kubernetes
• Možnosti úložiště pro cluster Kubernetes
• Správa nákladů pro Kubernetes
• Správa uzlů a fondů uzlů Kubernetes
• Zásady správného řízení clusteru
• Správa identit Microsoft Entra a správa přístupu pro AWS

Související prostředky

• Použití instančního objektu se službou Azure Kubernetes Service (AKS)
• Použití spravované identity ve službě Azure Kubernetes Service
• Implementace služby Azure Kubernetes Service (AKS)
• Správa identity a přístupu v Microsoft Entra ID