Bewerken

Delen via

Kubernetes-workloadidentiteit en -toegang

Microsoft Entra ID
Azure Kubernetes Service (AKS)

In dit artikel wordt beschreven hoe Amazon Elastic Kubernetes Service (Amazon EKS) en Azure Kubernetes Service (AKS) identiteit bieden voor Kubernetes-workloads voor toegang tot cloudplatformservices. Zie voor een gedetailleerde vergelijking van Amazon Web Services (AWS) Identity and Access Management (IAM) en Microsoft Entra ID:

In deze handleiding wordt uitgelegd hoe AKS-clusters, ingebouwde services en invoegtoepassingen beheerde identiteiten gebruiken voor toegang tot Azure-resources, zoals load balancers en beheerde schijven. Het artikel laat ook zien hoe u Microsoft Entra Workload-ID gebruikt, zodat AKS-workloads toegang hebben tot Azure-resources zonder dat hiervoor een verbindingsreeks, toegangssleutel of gebruikersreferenties nodig zijn.

Notitie

Dit artikel maakt deel uit van een reeks artikelen die professionals helpen die bekend zijn met Amazon EKS om inzicht te krijgen in Azure Kubernetes Service (AKS).

Amazon EKS Identity and Access Management

Amazon EKS heeft twee systeemeigen opties om AWS-services aan te roepen vanuit een Kubernetes-pod: IAM-rollen voor serviceaccounts en gekoppelde Amazon EKS-servicerollen.

IAM-rollen voor serviceaccounts koppelen IAM-rollen aan een Kubernetes-serviceaccount. Dit serviceaccount biedt AWS-machtigingen voor de containers in elke pod die gebruikmaakt van het serviceaccount. IAM-rollen voor serviceaccounts bieden de volgende voordelen:

  • Minimale bevoegdheden: u hoeft geen uitgebreide machtigingen te verlenen voor de IAM-rol van het knooppunt voor pods op dat knooppunt om AWS-API's aan te roepen. U kunt IAM-machtigingen instellen voor een serviceaccount en alleen pods die dat serviceaccount gebruiken, hebben toegang tot deze machtigingen. Deze functie elimineert ook de noodzaak van oplossingen van derden, zoals kiam of kube2iam.

  • Referentie-isolatie: een container kan alleen referenties ophalen voor de IAM-rol die is gekoppeld aan het serviceaccount waartoe deze behoort. Een container heeft nooit toegang tot referenties voor een andere container die deel uitmaakt van een andere pod.

  • Controlebaarheid: Amazon CloudTrail biedt toegang en gebeurtenislogboekregistratie om te zorgen voor retrospectief controleren.

Gekoppelde Amazon EKS-servicerollen zijn unieke IAM-rollen die rechtstreeks zijn gekoppeld aan Amazon EKS. Service-gekoppelde rollen zijn vooraf gedefinieerd door Amazon EKS en bevatten alle machtigingen die nodig zijn om namens de rol andere AWS-services aan te roepen. Voor de IAM-rol van het Amazon EKS-knooppunt roept de Daemon van het Amazon EKS-knooppunt kubelet AWS API's aan namens het knooppunt. Knooppunten krijgen machtigingen voor deze API-aanroepen vanuit een IAM-exemplaarprofiel en het bijbehorende beleid.

Beheerde identiteiten van AKS-clusters

Voor een AKS-cluster is een identiteit vereist voor toegang tot Azure-resources, zoals load balancers en beheerde schijven. Deze identiteit kan een beheerde identiteit of een service-principal zijn. Standaard maakt het maken van een AKS-cluster automatisch een door het systeem toegewezen beheerde identiteit. Het Azure-platform beheert de identiteit en u hoeft geen geheimen in te richten of te roteren. Zie Beheerde identiteiten voor Azure-resources voor meer informatie over door Microsoft Entra beheerde identiteiten.

AKS maakt geen service-principal automatisch, dus als u een service-principal wilt gebruiken, moet u deze maken. De service-principal verloopt uiteindelijk en u moet deze vernieuwen om het cluster te laten werken. Het beheren van service-principals voegt complexiteit toe, dus het is eenvoudiger om beheerde identiteiten te gebruiken.

Beheerde identiteiten zijn in wezen wrappers rond service-principals die het beheer vereenvoudigen. Dezelfde machtigingsvereisten gelden zowel voor service-principals als beheerde identiteiten. Beheerde identiteiten maken gebruik van verificatie op basis van certificaten. Elke referentie voor beheerde identiteiten verloopt 90 dagen en wordt na 45 dagen geroteerd.

AKS maakt gebruik van zowel door het systeem toegewezen als door de gebruiker toegewezen beheerde identiteitstypen. Deze identiteiten zijn onveranderbaar. Wanneer u een virtueel AKS-netwerk maakt of gebruikt, gekoppelde Azure-schijf, statisch IP-adres, routetabel of door de gebruiker toegewezen kubelet identiteit met resources buiten de resourcegroep van het knooppunt, voegt de Azure CLI de roltoewijzing automatisch toe.

Als u een andere methode gebruikt om het AKS-cluster te maken, zoals een Bicep-sjabloon, Azure Resource Manager-sjabloon of Terraform-module, moet u de principal-id van de beheerde identiteit van het cluster gebruiken om een roltoewijzing uit te voeren. De AKS-clusteridentiteit moet ten minste de rol Netwerkbijdrager hebben in het subnet binnen uw virtuele netwerk. Als u een aangepaste rol wilt definiëren in plaats van de ingebouwde rol Netwerkbijdrager te gebruiken, hebt u de volgende machtigingen nodig:

  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read

Wanneer de clusteridentiteit toegang moet hebben tot een bestaande resource, bijvoorbeeld wanneer u een AKS-cluster implementeert in een bestaand virtueel netwerk, moet u een door de gebruiker toegewezen beheerde identiteit gebruiken. Als u een door het systeem toegewezen besturingsvlak-id gebruikt, kan de resourceprovider de principal-id niet ophalen voordat het cluster wordt gemaakt. Het is dus onmogelijk om de juiste roltoewijzingen te maken voordat het cluster wordt ingericht.

Samenvatting van beheerde identiteiten

AKS maakt gebruik van de volgende door de gebruiker toegewezen beheerde identiteiten voor ingebouwde services en invoegtoepassingen.

Identiteit Naam Gebruiksscenario Standaardmachtigingen Bring Your Own Identity
Besturingsvlak Naam van AKS-cluster Beheert clusterresources, waaronder inkomende load balancers en door AKS beheerde openbare IP-adressen, automatische schaalaanpassing van clusters en CSI-stuurprogramma's voor Azure Disk en Azure File Rol Inzender voor knooppuntresourcegroep Ondersteund
Kubelet AKS-clusternaam-agentpool Verifieert met Azure Container Registry NA (voor Kubernetes v1.15+) Ondersteund
Invoegtoepassing HTTPApplicationRouting Beheert vereiste netwerkbronnen Lezerrol voor knooppuntresourcegroep, rol Inzender voor DNS-zone Nee
Invoegtoepassing Toepassingsgateway voor inkomend verkeer Beheert vereiste netwerkbronnen Rol Inzender voor knooppuntresourcegroep Nee
Invoegtoepassing omsagent Metrische AKS-gegevens verzenden naar Azure Monitor De rol Van uitgever van metrische gegevens bewaken Nee
Invoegtoepassing Virtueel knooppunt (ACIConnector) Beheert vereiste netwerkbronnen voor Azure Container Instances Rol Inzender voor knooppuntresourcegroep Nee

Zie Een beheerde identiteit gebruiken in Azure Kubernetes Service voor meer informatie.

Microsoft Entra Workload-ID voor Kubernetes

Voor Kubernetes-workloads zijn microsoft Entra-toepassingsreferenties vereist voor toegang tot met Microsoft Entra beveiligde resources, zoals Azure Key Vault en Microsoft Graph. Een veelvoorkomende uitdaging voor ontwikkelaars is het beheren van geheimen en referenties om de communicatie tussen verschillende onderdelen van een oplossing te beveiligen.

Microsoft Entra Workload-ID voor Kubernetes hoeft u geen referenties te beheren voor toegang tot cloudservices zoals Azure Cosmos DB, Azure Key Vault of Azure Blob Storage. Een door AKS gehoste workloadtoepassing kan Microsoft Entra Workload-ID gebruiken voor toegang tot een beheerde Azure-service met behulp van een Microsoft Entra-beveiligingstoken, in plaats van expliciete referenties zoals een verbindingsreeks, gebruikersnaam en wachtwoord of primaire sleutel.

Zoals in het volgende diagram wordt weergegeven, wordt het Kubernetes-cluster een beveiligingstokenverlener die tokens uitgeeft aan Kubernetes-serviceaccounts. U kunt deze tokens configureren om te worden vertrouwd in Microsoft Entra-toepassingen. De tokens kunnen vervolgens worden uitgewisseld voor Microsoft Entra-toegangstokens met behulp van de Azure Identity SDK's of de Microsoft Authentication Library (MSAL).

Diagram met een vereenvoudigde werkstroom voor een door pod beheerde identiteit in Azure.

  1. De kubelet agent projecteert een serviceaccounttoken naar de workload op een configureerbaar bestandspad.
  2. De Kubernetes-workload verzendt het geprojecteerde, ondertekende serviceaccounttoken naar Microsoft Entra-id en vraagt een toegangstoken aan.
  3. Microsoft Entra ID maakt gebruik van een OIDC-detectiedocument om de vertrouwensrelatie op de door de gebruiker gedefinieerde beheerde identiteit of geregistreerde toepassing te controleren en het binnenkomende token te valideren.
  4. Microsoft Entra ID geeft een beveiligingstoegangstoken uit.
  5. De Kubernetes-workload heeft toegang tot Azure-resources met behulp van het Microsoft Entra-toegangstoken.

Microsoft Entra Workload-ID federatie voor Kubernetes wordt momenteel alleen ondersteund voor Microsoft Entra-toepassingen, maar hetzelfde model kan mogelijk worden uitgebreid naar door Azure beheerde identiteiten.

Zie voor meer informatie, automatisering en documentatie voor Microsoft Entra Workload-ID:

Voorbeeldworkload

De voorbeeldworkload voert een front-end en een back-endservice uit op een AKS-cluster. De workloadservices gebruiken Microsoft Entra Workload-ID om toegang te krijgen tot de volgende Azure-services met behulp van Microsoft Entra-beveiligingstokens:

  • Azure Key Vault
  • Azure Cosmos DB
  • Azure Storage-account
  • Azure Service Bus-naamruimte

Vereisten

  1. Stel een AKS-cluster in waarvoor de OIDC-verlener is ingeschakeld.
  2. Installeer de mutating admission-webhook.
  3. Maak een Kubernetes-serviceaccount voor de workloads.
  4. Maak een Microsoft Entra-toepassing, zoals wordt weergegeven in de quickstart.
  5. Wijs rollen met de juiste machtigingen toe aan de benodigde geregistreerde Microsoft Entra-toepassingen.
  6. Stel een federatieve identiteitsreferentie in tussen de Microsoft Entra-toepassing en de verlener van het serviceaccount en het onderwerp.
  7. Implementeer de workloadtoepassing in het AKS-cluster.

Microsoft Entra Workload-ID berichtenstroom

AKS-toepassingen krijgen beveiligingstokens voor hun serviceaccount van de OIDC-verlener van het AKS-cluster. Microsoft Entra Workload-ID de beveiligingstokens uitwisselt met beveiligingstokens die zijn uitgegeven door Microsoft Entra ID en de toepassingen gebruiken de door Microsoft Entra ID uitgegeven beveiligingstokens voor toegang tot Azure-resources.

In het volgende diagram ziet u hoe de front-end- en back-endtoepassingen Microsoft Entra-beveiligingstokens verkrijgen om PaaS-services (Platform as a Service) van Azure te gebruiken.

Diagram van een voorbeeldtoepassing die gebruikmaakt van Microsoft Entra Workload-ID.

Een Visio-bestand van deze architectuur downloaden.

  1. Kubernetes geeft een token uit aan de pod wanneer het is gepland op een knooppunt, op basis van de pod- of implementatiespecificatie.
  2. De pod verzendt het door OIDC uitgegeven token naar Microsoft Entra-id om een Microsoft Entra-token aan te vragen voor de specifieke appId en resource.
  3. Microsoft Entra ID controleert de vertrouwensrelatie op de toepassing en valideert het binnenkomende token.
  4. Microsoft Entra ID geeft een beveiligingstoken uit: {sub: appId, aud: requested-audience}.
  5. De pod maakt gebruik van het Microsoft Entra-token om toegang te krijgen tot de Azure-doelresource.

Als u Microsoft Entra Workload-ID end-to-end wilt gebruiken in een Kubernetes-cluster:

  1. U configureert het AKS-cluster om tokens uit te geven en een OIDC-detectiedocument te publiceren om validatie van deze tokens mogelijk te maken.
  2. U configureert de Microsoft Entra-toepassingen om de Kubernetes-tokens te vertrouwen.
  3. Ontwikkelaars configureren hun implementaties om de Kubernetes-serviceaccounts te gebruiken om Kubernetes-tokens op te halen.
  4. Microsoft Entra Workload-ID de Kubernetes-tokens voor Microsoft Entra-tokens uitwisselt.
  5. AKS-clusterworkloads gebruiken de Microsoft Entra-tokens voor toegang tot beveiligde resources, zoals Microsoft Graph.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

Andere Inzenders:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen