Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
In dit artikel wordt beschreven hoe Azure Kubernetes Service (AKS) bepaalt wat een geverifieerde aanroeper mag doen met de Kubernetes-API. Het omvat de twee autorisatiemodellen die AKS ondersteunt en fijnmazige aangepaste resourcecontrole met Azure ABAC-voorwaarden.
Zie concepten voor clusterverificatie voor meer informatie over hoe AKS bellers verifieert.
Zie Opties voor toegang en identiteit voor AKS voor een overzicht van alle vier AKS-identiteitsscenario's.
De Kubernetes-API autoriseren
Nadat een beller is geverifieerd, evalueert AKS of de beller gemachtigd is om de aangevraagde actie uit te voeren. AKS ondersteunt twee autorisatiemodellen voor de Kubernetes-API:
- Op rollen gebaseerd toegangsbeheer van Kubernetes (RBAC). Het systeemeigen Kubernetes-autorisatiemodel. Machtigingen worden gedefinieerd als
RoleenClusterRoleobjecten en verleend aan subjecten viaRoleBindingenClusterRoleBindingobjecten die in elk cluster zijn opgeslagen. - Microsoft Entra ID-autorisatie. Een AKS-autorisatiewebhook die autorisatiebeslissingen delegeert aan Microsoft Entra ID. Machtigingen worden verleend als Azure-roltoewijzingen voor Entra ID-identiteiten en kunnen eventueel worden verfijnd met Azure ABAC-voorwaarden.
U kunt beide modellen in hetzelfde cluster gebruiken. U wordt aangeraden Microsoft Entra ID-autorisatie als de standaardinstelling te gebruiken en Kubernetes RBAC te reserveren voor verfijnde intraclustermachtigingen. In de rest van deze sectie wordt uitgelegd waarom en wanneer deze moeten worden gebruikt.
Kubernetes RBAC
Kubernetes RBAC is het upstream Kubernetes-autorisatiemodel. U maakt Role of ClusterRole objecten die werkwoorden (zoals get, list, create) toewijzen aan resources (zoals pods, deployments), en bindt ze aan onderwerpen (gebruikers, groepen of serviceaccounts) door middel van RoleBinding of ClusterRoleBinding objecten. De ingebouwde RBAC-autorisatier van de Kubernetes-API-server evalueert deze bindingen op elke aanvraag.
Gebruik Kubernetes RBAC als u wilt:
- Fijnmazig intra-cluster toegangsbeheer per naamruimte, samengesteld als Kubernetes-manifesten naast de workloads die ze beveiligen.
- Door GitOps beheerde autorisatie die zich in dezelfde bron van waarheid bevindt als uw toepassingsconfiguratie.
- Machtigingen voor serviceaccounts in het cluster die door workloads worden gebruikt om de Kubernetes-API aan te roepen.
Kubernetes RBAC-machtigingen zijn gericht op één cluster. Als u hetzelfde beleid wilt toepassen op veel clusters, moet u de manifesten toepassen op elk cluster (meestal via GitOps). Gebruik Microsoft Entra-gebruikers en -groepen als onderwerp in Kubernetes RoleBinding en ClusterRoleBinding objecten, zodat menselijke identiteiten nog steeds afkomstig zijn uit uw centrale directory.
Zie de upstream Kubernetes RBAC-documentatie voor achtergrondinformatie over het Kubernetes RBAC-model. Zie Kubernetes RBAC gebruiken met Microsoft Entra-integratie voor installatie in AKS.
Microsoft Entra ID-autorisatie voor de Kubernetes-API
Met entra-id-autorisatie implementeert AKS een autorisatiewebhook die beslissingen over kubernetes-API-autorisatie delegeert aan Microsoft Entra-id. Wanneer een aanvraag de API-server bereikt, roept de webhook de Entra ID-API checkaccess aan om de Azure-roltoewijzingen van de aanroeper (en eventuele gekoppelde ABAC-voorwaarden) te evalueren en wordt een beslissing voor toestaan of weigeren geretourneerd.
Autorisatie voor entra-id biedt u de volgende voordelen ten opzichte van het beheren van Kubernetes RBAC-manifesten op elk cluster:
- Eén identiteitsvlak. Dezelfde Microsoft Entra-gebruikers, -groepen en -service-principals die de toegang tot uw Azure-resources beheren, beheren ook de toegang tot uw Kubernetes-API. Er is geen afzonderlijke gebruikersmap om in te richten of te draaien.
- Eenmaal toewijzen, veel clusters beheren. Azure-roltoewijzingen kunnen worden gemaakt op abonnements-, beheergroep- of resourcegroepbereik. Eén roltoewijzing binnen een bereik van een resourcegroep verleent toegang tot elk huidig en toekomstig AKS-cluster in die resourcegroep. Met Kubernetes RBAC moet u manifesten afzonderlijk toepassen op elk cluster.
- Voorwaardelijke toegang en Privileged Identity Management (PIM). Clustertoegang neemt automatisch het bestaande entra-id-beleid voor voorwaardelijke toegang van uw organisatie over (zoals meervoudige verificatie of beperkingen op basis van locaties) en kan just-in-time worden verhoogd via PIM.
- Gecentraliseerde controle. Elke wijziging van roltoewijzing wordt vastgelegd in het Azure-activiteitenlogboek naast andere Wijzigingen in Azure-resources, zodat u één audittrail hebt voor clustertoegangsbeheer.
- Fijnmazige aangepaste resourcebeperkingen. Met ABAC-voorwaarden kunt u de toegang tot specifieke aangepaste resourcegroepen en -soorten beperken zonder Kubernetes RBAC-manifesten per cluster te schrijven.
AKS biedt de volgende ingebouwde rollen voor Entra ID-autorisatie:
| Role | Description |
|---|---|
| Azure Kubernetes Service RBAC Reader | Alleen-lezentoegang tot de meeste objecten in een naamruimte. Staat niet toe het weergeven van rollen, rolbindingen of Secrets. |
| Azure Kubernetes Dienst RBAC Writer | Lees-/schrijftoegang tot de meeste objecten in een naamruimte. Het weergeven of wijzigen van rollen of rolbindingen is niet toegestaan. |
| Azure Kubernetes Service RBAC-beheerder | Lees-/schrijftoegang tot de meeste resources in een naamruimte, plus de mogelijkheid om rollen en rolbindingen in de naamruimte te maken. |
| Azure Kubernetes Service RBAC-clusterbeheerder | Volledige controle over elke resource in het cluster, in alle naamruimten. |
Voor aangepaste machtigingspatronen kunt u aangepaste roldefinities maken die zijn gericht op specifieke Kubernetes-API-groepen met behulp van de gegevensacties van de Microsoft.ContainerService resourceprovider. Zie Microsoft Entra ID-autorisatie gebruiken voor de Kubernetes-API voor stapsgewijze instellingen en voorbeelden van aangepaste rollen.
Comparison
| Vermogen | Kubernetes RBAC | Autorisatie van entra-id |
|---|---|---|
| Identiteitsbron | Kubernetes-gebruikers, groepen, serviceaccounts | Microsoft Entra ID-identiteiten |
| Bereik van één toekenning | Eén cluster | Resource, resourcegroep, abonnement of beheergroep |
| Beheer met meerdere clusters | Manifesten toepassen op elk cluster (meestal GitOps) | Eén roltoewijzing op een hoger bereik bepaalt veel clusters |
| Voorwaardelijke toegang/PIM | Niet ondersteund | Overgenomen van Entra-id |
| Controlelogboek | Auditlogboek van cluster | Azure-activiteitenlogboek |
| Toegang filteren op CRD-groep of soort | Per CRD-objecten Role maken |
ABAC-voorwaardekenmerken gebruiken voor de roltoewijzing |
Aangepaste resourcetoegang beperken met ABAC-voorwaarden
Wanneer u brede leestoegang verleent via Microsoft Entra ID-autorisatie, maar wilt beperken welke aangepaste resources (CRD's) de toegewezen gebruiker kan lezen, voegt u een Azure ABAC-voorwaarde toe aan de roltoewijzing.
Zonder ABAC-voorwaarden vereist het verlenen van leesrechten op aangepaste resources een jokerteken zoals Microsoft.ContainerService/managedClusters/*/read, dat elke CRD voor elk cluster binnen de scope omvat. Met ABAC kunt u een voorwaarde koppelen waarmee de toegang tot specifieke CRD-groepen en -soorten wordt beperkt, bijvoorbeeld toestaan templates.gatekeeper.sh tijdens blokkeren kyverno.io , zonder Kubernetes RBAC-manifesten per cluster te schrijven.
Voor Kubernetes-API-autorisatie kunt u de toegang tot aangepaste resources filteren op basis van hun API-groep en soort met behulp van de volgende kenmerken:
Microsoft.ContainerService/managedClusters/customResources:groupMicrosoft.ContainerService/managedClusters/customResources:kind
Zie Wat zijn voorwaarden voor Azure-roltoewijzing? voor achtergrondinformatie over Azure ABAC. Zie Aangepaste resourcetoegang beperken met ABAC-voorwaarden voor stapsgewijze installatie.