Best practices voor verificatie en autorisatie in Azure Kubernetes Service (AKS)

  • Artikel

Wanneer u clusters implementeert en onderhoudt in Azure Kubernetes Service (AKS), implementeert u manieren om de toegang tot resources en services te beheren. Zonder deze besturingselementen:

  • Accounts kunnen toegang hebben tot onnodige resources en services.
  • Het bijhouden van referenties die worden gebruikt om wijzigingen aan te brengen, kan lastig zijn.

In dit artikel bespreken we welke aanbevolen procedures een clusteroperator kan volgen om toegang en identiteit voor AKS-clusters te beheren. U leert het volgende:

  • AKS-clustergebruikers verifiëren met Azure Active Directory (Azure AD).
  • Toegang tot resources beheren met kubernetes op rollen gebaseerd toegangsbeheer (Kubernetes RBAC).
  • Gebruik Azure RBAC om de toegang tot de AKS-resource, de Kubernetes-API op schaal en de kubeconfignauwkeurig te beheren.
  • Gebruik een beheerde identiteit om pods te verifiëren met andere services.

Azure Active Directory (Azure AD) gebruiken

Richtlijnen voor aanbevolen procedures

Implementeer AKS-clusters met Azure AD-integratie. Het gebruik van Azure AD centraliseert de laag voor identiteitsbeheer. Elke wijziging in de gebruikersaccount- of groepsstatus wordt automatisch bijgewerkt bij toegang tot het AKS-cluster. Bereik gebruikers of groepen tot de minimale hoeveelheid machtigingen met behulp van rollen, clusterrollen of bindingen.

Ontwikkelaars en toepassingseigenaren van uw Kubernetes-cluster hebben toegang nodig tot verschillende resources. Kubernetes beschikt niet over een oplossing voor identiteitsbeheer waarmee u de resources kunt beheren waarmee gebruikers kunnen communiceren. In plaats daarvan kunt u uw cluster integreren met een bestaande identiteitsoplossing zoals Azure AD, een bedrijfsklare oplossing voor identiteitsbeheer.

Met Azure AD geïntegreerde clusters in AKS maakt u rollen of clusterrollen die toegangsmachtigingen voor resources definiëren. Vervolgens koppelt u de rollen aan gebruikers of groepen uit Azure AD. Meer informatie over deze Kubernetes RBAC vindt u in de volgende sectie. Azure AD integratie en hoe u de toegang tot resources kunt beheren, ziet u in het volgende diagram:

Verificatie op clusterniveau voor Azure Active Directory-integratie met AKS

  1. Ontwikkelaar verifieert zich met Azure AD.
  2. Het eindpunt voor Azure AD tokenuitgifte geeft het toegangstoken uit.
  3. De ontwikkelaar voert een actie uit met behulp van het Azure AD-token, zoals kubectl create pod.
  4. Kubernetes valideert het token met Azure AD en haalt de groepslidmaatschappen van de ontwikkelaar op.
  5. Kubernetes RBAC- en clusterbeleid worden toegepast.
  6. De aanvraag van de ontwikkelaar is geslaagd op basis van eerdere validatie van Azure AD groepslidmaatschap en Kubernetes RBAC en beleid.

Zie Azure Active Directory integreren met AKS als u een AKS-cluster wilt maken dat gebruikmaakt van Azure AD.

Op rollen gebaseerd toegangsbeheer van Kubernetes gebruiken (Kubernetes RBAC)

Richtlijnen voor aanbevolen procedures

Definieer gebruikers- of groepsmachtigingen voor clusterresources met Kubernetes RBAC. Maak rollen en bindingen waarmee de minste vereiste machtigingen worden toegewezen. Integreer met Azure AD om elke wijziging in de gebruikersstatus of het groepslidmaatschap automatisch bij te werken en de toegang tot clusterresources actueel te houden.

In Kubernetes biedt u gedetailleerd toegangsbeheer voor clusterresources. U definieert machtigingen op clusterniveau of voor specifieke naamruimten. U bepaalt welke resources kunnen worden beheerd en met welke machtigingen. Vervolgens past u deze rollen toe op gebruikers of groepen met een binding. Zie Toegangs- en identiteitsopties voor Azure Kubernetes Service (AKS) voor meer informatie over rollen, clusterrollen en bindingen.

U maakt bijvoorbeeld een rol met volledige toegang tot resources in de naamruimte met de naam finance-app, zoals wordt weergegeven in het volgende YAML-manifest:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role
  namespace: finance-app
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

Vervolgens maakt u een RoleBinding en verbindt u de Azure AD gebruiker developer1@contoso.com eraan, zoals wordt weergegeven in het volgende YAML-manifest:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role-binding
  namespace: finance-app
subjects:
- kind: User
  name: developer1@contoso.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: finance-app-full-access-role
  apiGroup: rbac.authorization.k8s.io

Wanneer developer1@contoso.com is geverifieerd op basis van het AKS-cluster, hebben ze volledige machtigingen voor resources in de naamruimte van de financiële app . Op deze manier kunt u de toegang tot resources logisch scheiden en beheren. Kubernetes RBAC gebruiken met Azure AD-integratie.

Zie Toegang tot clusterresources beheren met op rollen gebaseerd toegangsbeheer en Azure Active Directory-identiteiten in AKS voor meer informatie over het gebruik van Azure AD groepen om de toegang tot Kubernetes-resources te beheren met behulp van Kubernetes RBAC.

Azure RBAC gebruiken

Richtlijnen voor aanbevolen procedures

Gebruik Azure RBAC om de minimaal vereiste gebruikers- en groepsmachtigingen voor AKS-resources in een of meer abonnementen te definiëren.

Er zijn twee toegangsniveaus nodig om een AKS-cluster volledig te kunnen gebruiken:

  • Toegang tot de AKS-resource in uw Azure-abonnement.

    Met dit toegangsniveau kunt u:

    • Het schalen of upgraden van uw cluster beheren met behulp van de AKS-API's
    • Haal uw kubeconfig.

    Zie Toegang tot clusterconfiguratiebestand beperken voor meer informatie over het beheren van de toegang tot de AKS-resource en de kubeconfig.

  • Toegang tot de Kubernetes-API.

    Dit toegangsniveau wordt beheerd door:

    • Kubernetes RBAC (traditioneel) of
    • Door Azure RBAC te integreren met AKS voor kubernetes-autorisatie.

    Zie Azure RBAC gebruiken voor Kubernetes-autorisatie voor meer informatie over het gedetailleerd verlenen van machtigingen aan de Kubernetes-API met behulp van Azure RBAC.

Door pods beheerde identiteiten gebruiken

Gebruik geen vaste referenties in pods of containerinstallatiekopieën, omdat deze risico lopen op blootstelling of misbruik. Gebruik in plaats daarvan pod-identiteiten om automatisch toegang aan te vragen met behulp van Azure AD.

Notitie

Pod-identiteiten zijn alleen bedoeld voor gebruik met Linux-pods en containerinstallatiekopieën. Ondersteuning voor door pods beheerde identiteiten (preview) voor Windows-containers is binnenkort beschikbaar.

Voor toegang tot andere Azure-resources, zoals Azure Cosmos DB, Key Vault of Blob Storage, heeft de pod verificatiereferenties nodig. U kunt verificatiereferenties definiëren met de containerinstallatiekopieën of deze als een Kubernetes-geheim injecteren. In beide gevallen moet u ze handmatig maken en toewijzen. Deze referenties worden meestal opnieuw gebruikt in verschillende pods en worden niet regelmatig geroteerd.

Met door pods beheerde identiteiten (preview) voor Azure-resources vraagt u automatisch toegang tot services aan via Azure AD. Door pods beheerde identiteiten is momenteel in preview voor AKS. Raadpleeg de documentatie Azure Active Directory-identiteiten die door pods worden beheerd in Azure Kubernetes Service (preview) gebruiken om aan de slag te gaan.

Notitie

Als u Azure AD door pods beheerde identiteit hebt ingeschakeld in uw AKS-cluster of als u overweegt deze te implementeren, raden we u aan eerst het artikel Over identiteiten van workloads door te nemen voor meer informatie over onze aanbevelingen en opties voor het instellen van uw cluster voor het gebruik van een Azure AD workloadidentiteit (preview). Deze verificatiemethode vervangt door pods beheerde identiteit (preview), die kan worden geïntegreerd met de systeemeigen Kubernetes-mogelijkheden om te federeren met externe id-providers.

De open source Azure AD door pods beheerde identiteit (preview) in Azure Kubernetes Service is afgeschaft vanaf 24-10-2022.

Door pods beheerde identiteit van Azure Active Directory (preview) ondersteunt twee bewerkingsmodi:

  • Standaardmodus : In deze modus worden de volgende 2 onderdelen geïmplementeerd in het AKS-cluster:

    • Managed Identity Controller (MIC): een Kubernetes-controller die controleert op wijzigingen in pods, AzureIdentity en AzureIdentityBinding via de Kubernetes API-server. Wanneer er een relevante wijziging wordt gedetecteerd, wordt AzureAssignedIdentity door de MIC toegevoegd of verwijderd. Wanneer een pod wordt gepland, wijst de MIC de beheerde identiteit in Azure toe aan de onderliggende virtuele-machineschaalset die tijdens de aanmaakfase door de knooppuntgroep wordt gebruikt. Wanneer alle pods die gebruikmaken van de identiteit worden verwijderd, wordt de identiteit verwijderd uit de virtuele-machineschaalset van de knooppuntgroep, tenzij dezelfde beheerde identiteit wordt gebruikt door andere pods. De MIC voert vergelijkbare acties uit wanneer AzureIdentity of AzureIdentityBinding worden gemaakt of verwijderd.

    • NMI (Node Managed Identity): is een pod die als een DaemonSet wordt uitgevoerd op elk knooppunt in het AKS-cluster. NMI onderschept beveiligingstokenaanvragen naar de Azure Instance Metadata Service op elk knooppunt. Aanvragen worden omgeleid naar zichzelf en gevalideerd of de pod toegang heeft tot de identiteit waarvoor een token wordt aangevraagd en haalt het token op uit de Azure Active Directory-tenant namens de toepassing.

  • Beheerde modus: in deze modus is er alleen NMI. De identiteit moet handmatig worden toegewezen en beheerd door de gebruiker. Zie Pod-identiteit in beheerde modus voor meer informatie. Wanneer u in deze modus de opdracht az aks pod-identity add gebruikt om een pod-identiteit toe te voegen aan een Azure Kubernetes Service (AKS)-cluster, worden de AzureIdentity en AzureIdentityBinding gemaakt in de naamruimte die is opgegeven door de --namespace parameter, terwijl de AKS-resourceprovider de beheerde identiteit toewijst die is opgegeven door de --identity-resource-id parameter aan de virtuele-machineschaalset van elke knooppuntgroep in het AKS-cluster.

Notitie

Als u in plaats daarvan besluit om de door pods beheerde identiteit van Azure Active Directory te installeren met behulp van de invoegtoepassing voor het AKS-cluster, wordt de managed modus gebruikt.

De managed modus biedt de volgende voordelen ten opzichte van de standard:

  • Identiteitstoewijzing op de virtuele-machineschaalset van een knooppuntgroep kan 40-60s duren. Met cronjobs of toepassingen die toegang tot de identiteit vereisen en de toewijzingsvertraging niet kunnen tolereren, kunt u het beste de modus gebruiken managed omdat de identiteit vooraf is toegewezen aan de virtuele-machineschaalset van de knooppuntgroep. Handmatig of met behulp van de opdracht az aks pod-identity add .
  • In standard de modus vereist MIC schrijfmachtigingen voor de virtuele-machineschaalset die wordt gebruikt door het AKS-cluster en Managed Identity Operator machtigingen voor de door de gebruiker toegewezen beheerde identiteiten. Wanneer u in managed modeuitvoert, zijn de roltoewijzingen niet vereist omdat er geen MIC is.

In plaats van handmatig referenties voor pods te definiëren, vragen door pods beheerde identiteiten in realtime een toegangstoken aan, waarbij het wordt gebruikt om alleen toegang te krijgen tot de toegewezen resources. In AKS zijn er twee onderdelen die de bewerkingen verwerken om pods toe te staan beheerde identiteiten te gebruiken:

  • De NMI-server (Node Management Identity) is een pod die als een DaemonSet wordt uitgevoerd op elk knooppunt in het AKS-cluster. De NMI-server luistert naar podaanvragen voor Azure-services.
  • De Azure-resourceprovider voert een query uit op de Kubernetes API-server en controleert op een Azure-identiteitstoewijzing die overeenkomt met een pod.

Wanneer pods een beveiligingstoken van Azure Active Directory aanvragen voor toegang tot een Azure-resource, leiden netwerkregels het verkeer om naar de NMI-server.

  1. De NMI-server:

    • Identificeert pods die toegang tot Azure-resources aanvragen op basis van hun externe adres.
    • Hiermee wordt een query uitgevoerd op de Azure-resourceprovider.

  2. De Azure-resourceprovider controleert op Azure-identiteitstoewijzingen in het AKS-cluster.

  3. De NMI-server vraagt een toegangstoken aan bij Azure AD op basis van de identiteitstoewijzing van de pod.

  4. Azure AD biedt toegang tot de NMI-server, die wordt geretourneerd naar de pod.

    • Dit toegangstoken kan door de pod worden gebruikt om vervolgens toegang tot resources in Azure aan te vragen.

In het volgende voorbeeld maakt een ontwikkelaar een pod die gebruikmaakt van een beheerde identiteit om toegang aan te vragen tot Azure SQL Database:

Met pod-identiteiten kan een pod automatisch toegang tot andere resources aanvragen.

  1. Clusteroperator maakt een serviceaccount om identiteiten toe te wijzen wanneer pods toegang tot resources aanvragen.
  2. De NMI-server wordt geïmplementeerd om podaanvragen, samen met de Azure-resourceprovider, voor toegangstokens naar Azure AD door te sturen.
  3. Een ontwikkelaar implementeert een pod met een beheerde identiteit die een toegangstoken aanvraagt via de NMI-server.
  4. Het token wordt geretourneerd naar de pod en gebruikt voor toegang tot Azure SQL Database

Zie Door pods beheerde identiteiten van Azure Active Directory gebruiken in Azure Kubernetes Service (preview) als u door pods beheerde identiteiten wilt gebruiken.

Volgende stappen

Dit artikel met aanbevolen procedures is gericht op verificatie en autorisatie voor uw cluster en resources. Zie de volgende artikelen om een aantal van deze aanbevolen procedures te implementeren:

Zie de volgende aanbevolen procedures voor meer informatie over clusterbewerkingen in AKS: