Aanbevolen procedures voor clusterbeveiliging en -upgrades in Azure Kubernetes Service (AKS)

Van toepassing op: ✔️ AKS Automatic ✔️ AKS Standard

Wanneer u clusters beheert in Azure Kubernetes Service (AKS), is workload- en gegevensbeveiliging een belangrijke overweging. Wanneer u clusters met meerdere tenants uitvoert met behulp van logische isolatie, moet u met name de toegang tot resources en werkbelastingen beveiligen. Minimaliseer het risico op aanvallen door de meest recente beveiligingsupdates voor Kubernetes en het knooppuntbesturingssysteem toe te passen.

Dit artikel is gericht op het beveiligen van uw AKS-cluster. U leert het volgende:

U kunt ook de best practices voor beheer van containerimages en podbeveiliging lezen.

Beveiligingsverantwoordelijkheden voor AKS-clustermodus

AKS ondersteunt twee clustermodi: AKS Automatic en AKS Standard. Beveiligingsdoelstellingen zijn in beide modi hetzelfde, maar de verantwoordelijkheid voor de implementatie verschilt.

AKS Automatic bevat een beperkte basislijn met meer vooraf geconfigureerde besturingselementen in ondersteunde configuraties. AKS Standard biedt een breder direct configuratiebeheer, waardoor de verantwoordelijkheid van de operator voor de basislijninstallatie en doorlopende bewerkingen wordt verhoogd.

Bedreigingsbeveiliging inschakelen

Richtlijnen voor best practices

U kunt Defender for Containers inschakelen om uw containers te beveiligen. Defender for Containers kan clusterconfiguraties beoordelen en beveiligingsaanbevelingen bieden, beveiligingsscans uitvoeren en realtime bescherming en waarschuwingen bieden voor Kubernetes-knooppunten en -clusters.

Deze richtlijnen zijn van toepassing op beide modi. Zelfs wanneer AKS Automatic vooraf geconfigureerde beveiligingsstandaarden biedt, blijven onboarding- en waarschuwingsresponswerkstromen operationele verantwoordelijkheden voor uw team.

Toegang tot de API-server en clusterknooppunten beveiligen

Richtlijnen voor best practices

Een van de belangrijkste manieren om uw cluster te beveiligen, is door de toegang tot de Kubernetes-API-server te beveiligen. Als u de toegang tot de API-server wilt beheren, integreert u Kubernetes RBAC met Microsoft Entra-id. Met deze besturingselementen beveiligt u AKS op dezelfde manier als u de toegang tot uw Azure-abonnementen beveiligt.

De Kubernetes-API-server biedt één verbindingspunt voor aanvragen voor het uitvoeren van acties binnen een cluster. Als u de toegang tot de API-server wilt beveiligen en controleren, beperkt u de toegang en geeft u de laagst mogelijke machtigingsniveaus op. Hoewel deze benadering niet uniek is voor Kubernetes, is het vooral belangrijk wanneer u uw AKS-cluster logisch hebt geïsoleerd voor gebruik met meerdere tenants.

Microsoft Entra ID biedt een oplossing voor identiteitsbeheer die gereed is voor ondernemingen die kan worden geïntegreerd met AKS-clusters. Omdat Kubernetes geen oplossing voor identiteitsbeheer biedt, is het mogelijk moeilijk om de toegang tot de API-server gedetailleerd te beperken. Met geïntegreerde Microsoft Entra-clusters in AKS gebruikt u uw bestaande gebruikers- en groepsaccounts om gebruikers te verifiëren bij de API-server.

Met Kubernetes RBAC en Microsoft Entra ID-integratie kunt u de API-server beveiligen en de minimale machtigingen opgeven die vereist zijn voor een scoped resourceset, zoals één naamruimte. U kunt verschillende Microsoft Entra-gebruikers of groepen verschillende Kubernetes-rollen verlenen. Met gedetailleerde machtigingen kunt u de toegang tot de API-server beperken en een duidelijk audittrail met uitgevoerde acties opgeven.

In AKS Automatic zijn autorisatie en beveiligingsbaselines in ondersteunde configuraties verder vooraf geconfigureerd, zodat operators zich kunnen richten op validatie, governance en afhandeling van uitzonderingen. In AKS Standard configureren beheerders deze maatregelen meestal direct zelf en zijn ze verantwoordelijk voor het beheer ervan gedurende de hele levenscyclus.

Zie Best practices voor verificatie en autorisatie in AKS voor meer informatie over Microsoft Entra-integratie, Kubernetes RBAC en Azure RBAC.

Toegang tot de API voor exemplaarmetagegevens beperken

Richtlijnen voor best practices

Voeg een netwerkbeleid toe aan alle gebruikersnaamruimten om het uitgaand verkeer van pods te blokkeren naar het eindpunt van de metagegevens.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-instance-metadata
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.10.0.0/0#example
        except:
        - 169.254.169.254/32

Zorg ervoor dat uw geselecteerde netwerkmodel en beleidsengine dit beleidspad ondersteunen in AKS Standard. Pas in AKS Automatic equivalente uitgaande beperkingen op naamruimteniveau toe, waarbij deze worden ondersteund in de clusterconfiguratie.

Toegang tot containerbronnen beveiligen

Richtlijnen voor best practices

Beperk de toegang tot acties die containers kunnen uitvoeren. Geef het minste aantal machtigingen op en vermijd het gebruik van hoofdtoegang of escalatie met bevoegdheden.

Op dezelfde manier dat u gebruikers of groepen de vereiste minimale bevoegdheden moet verlenen, moet u ook containers beperken tot alleen noodzakelijke acties en processen. Vermijd het configureren van toepassingen en containers waarvoor geëscaleerde bevoegdheden of toegang tot de hoofdmap zijn vereist om het risico op aanvallen te minimaliseren.

Met behulp van gebruikersnaamruimten verbetert u de isolatie van de host en beperkt u de zijdelingse verplaatsing bij containeruitbraken. Deze verbeteringen zijn aanzienlijk, ongeacht of de pod als root draait of niet als root draait.

Voor nog gedetailleerdere controle over containeracties kunt u ook ingebouwde Linux-beveiligingsfuncties zoals AppArmor en seccomp gebruiken.

Zelfs wanneer AKS Automatic beperkte standaardinstellingen biedt, blijven beveiligingsmaatregelen op workloadniveau de verantwoordelijkheden van het toepassings- en platformteam.

Zie Beveiligde containertoegang tot resources voor meer informatie.

Regelmatig bijwerken naar de nieuwste versie van Kubernetes

Richtlijnen voor best practices

Als u op de hoogte wilt blijven van nieuwe functies en oplossingen voor fouten, voert u regelmatig een upgrade uit van de Kubernetes-versie in uw AKS-cluster.

Kubernetes brengt nieuwe functies sneller uit dan meer traditionele infrastructuurplatforms. Kubernetes-updates zijn onder andere:

• Nieuwe functies
• Bug- of beveiligingsoplossingen

Nieuwe functies doorlopen doorgaans de alfa - en bètastatus voordat ze stabiel worden. Eenmaal stabiel, zijn algemeen beschikbaar en aanbevolen voor productiegebruik. Met de nieuwe releasecyclus van Kubernetes kunt u Kubernetes bijwerken zonder dat er regelmatig wijzigingen optreden die fouten veroorzaken of uw implementaties en sjablonen aanpassen.

AKS ondersteunt drie secundaire versies van Kubernetes. Zodra een nieuwe secundaire patchversie is geïntroduceerd, worden de oudste secundaire versie en patchreleases die worden ondersteund buiten gebruik gesteld. Kleine Kubernetes-updates worden periodiek uitgevoerd. Als u binnen de ondersteuning wilt blijven, moet u ervoor zorgen dat u een governanceproces hebt om te controleren op de benodigde upgrades. Zie Ondersteunde Kubernetes-versies AKS voor meer informatie.

In AKS Automatic is upgrade-gerelateerd gedrag meer vooraf geconfigureerd in ondersteunde configuraties en moeten operators zich richten op validatie van workloadgereedheid en releasebeheer. In AKS Standard kiezen en beheren operators de upgradestrategie en de timing van de implementatie meer rechtstreeks.

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table

Get-AzAksUpgradeProfile -ResourceGroupName myResourceGroup -ClusterName myAKSCluster |
Select-Object -Property Name, ControlPlaneProfileKubernetesVersion -ExpandProperty ControlPlaneProfileUpgrade |
Format-Table -Property *

Zie Ondersteunde Kubernetes-versies in AKS en een AKS-cluster upgraden voor meer informatie over upgrades in AKS.

Updates voor Linux-knooppunten verwerken

Elke avond krijgen Linux-knooppunten in AKS beveiligingspatches via hun distributie-updatekanaal. Dit gedrag wordt automatisch geconfigureerd omdat de knooppunten worden geïmplementeerd in een AKS-cluster. Om onderbrekingen en mogelijke gevolgen voor actieve workloads te minimaliseren, worden knooppunten niet automatisch opnieuw opgestart als een beveiligingspatch of kernelupdate dit vereist. Zie Beveiligings- en kernelupdates toepassen op knooppunten in AKS voor meer informatie over het afhandelen van opnieuw opstarten van knooppunten.

In AKS Automatic is het gedrag van knooppuntupdates meer vooraf geconfigureerd in ondersteunde configuraties. In AKS Standard definiëren operators vaak patch- en herstartbeheer met expliciete operationele besturingselementen.

Upgrades van knooppuntinstallatiekopieën

Bij upgrades zonder toezicht worden updates toegepast op het besturingssysteem van het Linux-knooppunt, maar de installatiekopieën die worden gebruikt om knooppunten voor uw cluster te maken, blijven ongewijzigd. Als er een nieuw Linux-knooppunt aan uw cluster wordt toegevoegd, wordt de oorspronkelijke image gebruikt om het knooppunt te maken. Dit nieuwe knooppunt ontvangt alle beveiligingsupdates en kernelupdates die elke nacht beschikbaar zijn tijdens de automatische controle, maar blijven niet gepatcht totdat alle controles en opnieuw opstarten zijn voltooid. U kunt de upgrade van de knooppuntinstallatiekopieën gebruiken om te controleren op knooppuntinstallatiekopieën die door uw cluster worden gebruikt en bij te werken. Zie Azure Kubernetes Service (AKS) knooppuntafbeeldingsupgrade voor meer informatie over het upgraden van knooppuntafbeeldingen.

Windows Server-knooppuntupdates verwerken

Voor Windows Server-knooppunten voert u regelmatig een upgradebewerking van de knooppuntimage uit om knooppunten veilig te cordonen, pods leeg te maken en bijgewerkte knooppunten uit te rollen.

Verwante inhoud

Zie de volgende artikelen voor meer informatie over AKS en het beveiligen van uw AKS-cluster:

• Vergelijking van AKS Automatic- en AKS Standard-functies
• Aanbevolen procedures voor verificatie en autorisatie in AKS