Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Tento článek popisuje, jak Azure Kubernetes Service (AKS) rozhoduje, co může ověřený volající provádět s rozhraním API Kubernetes. Zahrnuje dva modely autorizace, které AKS podporuje a jemně odstupňované vlastní řízení prostředků s podmínkami Azure ABAC.
Informace o tom, jak AKS ověřuje volající na prvním místě, najdete v tématu Koncepty ověřování clusteru.
Orientaci ve všech čtyřech scénářích identit AKS najdete v tématu Možnosti přístupu a identity pro AKS.
Autorizace rozhraní API Kubernetes
Po ověření volajícího služba AKS vyhodnotí, jestli má volající oprávnění k provedení požadované akce. AKS podporuje dva autorizační modely pro rozhraní Kubernetes API:
- Řízení přístupu na základě role Kubernetes (RBAC). Nativní autorizační model Kubernetes. Oprávnění jsou definována jako
RoleaClusterRoleobjekty a udělena subjektům prostřednictvímRoleBindingaClusterRoleBindinguložených v každém clusteru. - Autorizace Microsoft Entra ID Webhook autorizace AKS, který deleguje rozhodnutí o autorizaci na Microsoft Entra ID. Oprávnění se udělují jako přiřazení rolí Azure k identitám ID Entra a dají se volitelně upřesnit pomocí podmínek Azure ABAC.
Oba modely můžete použít ve stejném clusteru. Doporučujeme používat autorizaci Microsoft Entra ID jako výchozí a rezervovat Kubernetes RBAC pro jemně odstupňovaná oprávnění uvnitř clusteru. Zbytek této části vysvětluje, proč a kdy je použít.
Kubernetes RBAC
Kubernetes RBAC je nadřazený model autorizace Kubernetes. Vytvoříte Role nebo ClusterRole objekty, které na zdrojích (například pods, deployments) udělují příkazy (například get, list, create), a svážete je s podměty (uživatelé, skupiny nebo účty služeb) pomocí RoleBinding nebo ClusterRoleBinding objektů. Předdefinovaný autorizátor RBAC serveru rozhraní Kubernetes API vyhodnocuje tyto vazby na každém požadavku.
RBAC Kubernetes použijte, když chcete:
- Jemně odstupňované řízení přístupu v rámci clusteru pro jednotlivé obory názvů vytvořené jako manifesty Kubernetes spolu s úlohami, které chrání.
- Autorizace spravovaná GitOps, která se nachází ve stejném zdroji pravdy jako konfigurace vaší aplikace.
- Oprávnění pro účty služeb v clusteru, které úlohy používají k volání rozhraní Kubernetes API.
Oprávnění RBAC Kubernetes jsou vymezená na jeden cluster. Pokud chcete použít stejné zásady pro mnoho clusterů, musíte manifesty použít u každého clusteru (obvykle prostřednictvím GitOps). Používejte uživatele a skupiny Microsoft Entra jako subjekty v objektech Kubernetes RoleBinding a ClusterRoleBinding, aby uživatelské identity stále pocházely z vašeho centrálního adresáře.
Základní informace o modelu Kubernetes RBAC najdete v nadřazené dokumentaci Kubernetes RBAC. Informace o nastavení v AKS najdete v tématu Použití RBAC Kubernetes s integrací Microsoft Entra.
Autorizace Microsoft Entra ID pro rozhraní API Kubernetes
S autorizací Entra ID nasadí AKS autorizační webhook, který deleguje rozhodnutí o autorizaci rozhraní API Kubernetes na Microsoft Entra ID. Když požadavek dorazí na server API, webhook zavolá rozhraní API Entra ID checkaccess ke zhodnocení přiřazení rolí Azure volajícího (a všech připojených podmínek ABAC) a vrátí povolení nebo zamítnutí.
Autorizace Entra ID poskytuje následující výhody při správě manifestů RBAC Kubernetes v každém clusteru:
- Jedna rovina identity. Stejní uživatelé, skupiny a služební účty Microsoft Entra, kteří řídí přístup k vašim prostředkům Azure, také řídí přístup k vašemu rozhraní Kubernetes API. Neexistuje žádný samostatný uživatelský adresář, který by bylo potřeba zřídit nebo otočit.
- Přiřaďte jednou, spravujte mnoho clusterů. Přiřazení rolí Azure lze provést na úrovni předplatného, skupiny pro správu nebo skupiny prostředků. Jedno přiřazení role v oboru skupiny prostředků uděluje přístup ke každému aktuálnímu a budoucímu clusteru AKS v této skupině prostředků. S Kubernetes RBAC musíte použít manifesty pro každý cluster jednotlivě.
- Podmíněný přístup a Privileged Identity Management (PIM). Přístup ke clusteru automaticky dědí stávající zásady podmíněného přístupu Entra ID vaší organizace (například vícefaktorové ověřování nebo omezení založená na umístění) a dají se zvýšit podle potřeby prostřednictvím PIM.
- Centralizovaný audit. Každá změna přiřazení role se zaznamenává v protokolu aktivit Azure spolu s dalšími změnami prostředků Azure, takže máte jeden záznam auditu pro zásady správného řízení přístupu ke clusteru.
- Jemně rozlišená uživatelská omezení prostředků Pomocí podmínek ABAC můžete omezit přístup ke konkrétním skupinám a typům vlastních prostředků (CRD), aniž byste museli psát manifesty RBAC pro jednotlivé clustery.
AKS poskytuje následující předdefinované role pro autorizaci Entra ID:
| Úloha | Description |
|---|---|
| Čtenář RBAC služby Azure Kubernetes Service | Přístup jen pro čtení k většině objektů v jmenném prostoru Nepovoluje zobrazování rolí, rolových vazeb nebo Secrets. |
| Azure Kubernetes Service RBAC - Autor | Přístup pro čtení a zápis k většině objektů v jmenném prostoru Nepovoluje zobrazení nebo úpravu rolí nebo vazeb rolí. |
| Správce RBAC služby Azure Kubernetes Service | Přístup pro čtení a zápis k většině zdrojů uvnitř oboru názvů a možnost vytvářet role a vazby rolí uvnitř tohoto oboru názvů. |
| Správce clusteru RBAC služby Azure Kubernetes Service | Úplná kontrola nad každým prostředkem v clusteru napříč všemi obory názvů |
U vlastních vzorů oprávnění můžete vytvářet vlastní definice rolí, které cílí na konkrétní skupiny rozhraní API Kubernetes pomocí Microsoft.ContainerService akcí dat poskytovatele prostředků. Podrobné pokyny k nastavení a vlastním příkladům rolí najdete v tématu Použití autorizace ID Microsoft Entra pro rozhraní API Kubernetes.
Comparison
| Schopnost | Kubernetes RBAC | Autorizace Entra ID |
|---|---|---|
| Zdroj identity | Uživatelé, skupiny, účty služeb Kubernetes | Identity ID Microsoft Entra |
| Rozsah jednoho grantu | Jeden cluster | Prostředek, skupina prostředků, předplatné nebo skupina pro správu |
| Správa více clusterů | Použití manifestů pro každý cluster (obvykle GitOps) | Jedno přiřazení role ve vyšším oboru řídí mnoho clusterů. |
| Podmíněný přístup / PIM | Nepodporováno | Zděděno z ID Entra |
| Revizní záznam | Protokol auditu clusteru | Protokol aktivit Azure |
| Filtrování přístupu podle skupiny CRD nebo typu | Vytváření objektů podle CRD Role |
Použijte atributy podmínky ABAC při přiřazení role |
Omezení vlastního přístupu k prostředkům pomocí podmínek ABAC
Když udělíte široký přístup pro čtení prostřednictvím autorizace Microsoft Entra ID, ale chcete omezit, které vlastní prostředky (CRD) může přiřazený uživatel číst, připojte k přiřazení role podmínku Azure ABAC.
Bez podmínek ABAC udělení oprávnění ke čtení pro uživatelské prostředky vyžaduje zástupný znak, například Microsoft.ContainerService/managedClusters/*/read, který zahrnuje všechny CRD ve všech clusterech v daném rozsahu. Pomocí ABAC můžete připojit podmínku, která omezuje přístup ke konkrétním skupinám a typům CRD – například povolit templates.gatekeeper.sh při blokování kyverno.io – bez zápisu manifestů RBAC pro jednotlivé clustery.
Pro autorizaci rozhraní API Kubernetes můžete filtrovat přístup k vlastním prostředkům podle skupiny rozhraní API a druhu pomocí následujících atributů:
Microsoft.ContainerService/managedClusters/customResources:groupMicrosoft.ContainerService/managedClusters/customResources:kind
Základní informace o Azure ABAC najdete v tématu Co jsou podmínky přiřazení rolí Azure? Podrobné nastavení najdete v tématu Omezení vlastního přístupu k prostředkům pomocí podmínek ABAC.