Aanbevolen procedures voor clusterbeveiliging en -upgrades in Azure Kubernetes Service (AKS)
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:
- Gebruik Microsoft Entra ID en Kubernetes op rollen gebaseerd toegangsbeheer (Kubernetes RBAC) om toegang tot API-servers te beveiligen.
- Beveilig containertoegang tot knooppuntbronnen.
- Een AKS-cluster upgraden naar de nieuwste Kubernetes-versie.
- Houd knooppunten up-to-date en pas automatisch beveiligingspatches toe.
U kunt ook de aanbevolen procedures voor containerinstallatiekopieën beheren en voor podbeveiliging lezen.
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.
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.
De aanbevolen best practice is om groepen te gebruiken om toegang te bieden tot bestanden en mappen in plaats van afzonderlijke identiteiten. Gebruik bijvoorbeeld een Microsoft Entra ID-groepslidmaatschap om gebruikers te binden aan Kubernetes-rollen in plaats van afzonderlijke gebruikers. Als het groepslidmaatschap van een gebruiker verandert, worden de toegangsmachtigingen voor het AKS-cluster dienovereenkomstig gewijzigd.
Laten we ondertussen zeggen dat u de afzonderlijke gebruiker rechtstreeks verbindt aan een rol en dat de functie van de gebruiker wordt gewijzigd. Hoewel de Microsoft Entra-groepslidmaatschappen worden bijgewerkt, zouden hun machtigingen voor het AKS-cluster niet worden bijgewerkt. In dit scenario heeft de gebruiker meer machtigingen dan ze nodig hebben.
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.
Notitie
Als u netwerkbeleid wilt implementeren, neemt u het kenmerk --network-policy azure op bij het maken van het AKS-cluster. Gebruik de volgende opdracht om het cluster te maken: az aks create -g myResourceGroup -n myManagedCluster --network-plugin azure --network-policy azure --generate-ssh-keys
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
Toegang tot resources voor containers 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.
Voor nog gedetailleerdere controle over containeracties kunt u ook ingebouwde Linux-beveiligingsfuncties zoals AppArmor en seccomp gebruiken. 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.
Als u de versies wilt controleren die beschikbaar zijn voor uw cluster, gebruikt u de opdracht az aks get-upgrades , zoals wordt weergegeven in het volgende voorbeeld:
az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table
Vervolgens kunt u uw AKS-cluster upgraden met behulp van de opdracht az aks upgrade . Het upgradeproces veilig:
- Cordons en afvoert één knooppunt tegelijk.
- Hiermee worden pods op resterende knooppunten gepland.
- Hiermee wordt een nieuw knooppunt geïmplementeerd waarop de nieuwste versies van het besturingssysteem en Kubernetes worden uitgevoerd.
Belangrijk
Test nieuwe secundaire versies in een ontwikkeltestomgeving en controleer of uw workload in orde blijft met de nieuwe Kubernetes-versie.
Kubernetes kan API's (zoals in versie 1.16) waarvoor uw workloads afhankelijk zijn, verwijderen. Wanneer u nieuwe versies in productie neemt, kunt u overwegen om meerdere knooppuntgroepen te gebruiken in afzonderlijke versies en afzonderlijke pools één voor één bij te werken om de update geleidelijk over een cluster te rollen. Als u meerdere clusters uitvoert, moet u één cluster tegelijk upgraden om progressief te controleren op impact of wijzigingen.
az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version KUBERNETES_VERSION
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.
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 installatiekopieën 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 voor meer informatie over upgrade van knooppuntinstallatiekopieën azure Kubernetes Service (AKS)-knooppuntinstallatiekopieën.
Windows Server-knooppuntupdates verwerken
Voor Windows Server-knooppunten voert u regelmatig een upgradebewerking voor knooppuntinstallatiekopieën uit om veilig cordon- en afvoerpods uit te voeren en bijgewerkte knooppunten te implementeren.
Azure Kubernetes Service