Best practices voor clusterbeveiliging en upgrades in Azure Kubernetes Service (AKS)

Bij het beheren van clusters in Azure Kubernetes Service (AKS) is workload- en gegevensbeveiliging een belangrijke overweging. Wanneer u clusters met meerdere tenants met logische isolatie gebruikt, moet u met name de toegang tot resources en workloads beveiligen. Minimaliseer het risico op aanvallen door de nieuwste beveiligingsupdates voor Kubernetes en knooppuntbesturingssystemen toe te passen.

Dit artikel is gericht op het beveiligen van uw AKS-cluster. In deze zelfstudie leert u procedures om het volgende te doen:

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

U kunt ook Azure Kubernetes Services-integratie met Defender for Cloud gebruiken om bedreigingen te detecteren en aanbevelingen te bekijken voor het beveiligen van uw AKS-clusters.

Beveiligde toegang tot de API-server en clusterknooppunten

Richtlijnen voor best practices

Een van de belangrijkste manieren om uw cluster te beveiligen, is om de toegang tot de Kubernetes-API-server te beveiligen. Als u de toegang tot de API-server wilt beheren, integreert u Kubernetes RBAC met Azure Active Directory (Azure AD). 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 om acties binnen een cluster uit te voeren. 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 deze vooral belangrijk wanneer u uw AKS-cluster logisch hebt geïsoleerd voor gebruik met meerdere tenants.

Azure AD biedt een oplossing voor identiteitsbeheer die bedrijfsklaar is en kan worden geïntegreerd met AKS-clusters. Omdat Kubernetes geen oplossing voor identiteitsbeheer biedt, kan het lastig zijn om de toegang tot de API-server gedetailleerd te beperken. Met met Azure AD geïntegreerde clusters in AKS gebruikt u uw bestaande gebruikers- en groepsaccounts om gebruikers te verifiëren bij de API-server.

Met behulp van Kubernetes RBAC en Azure AD-integratie kunt u de API-server beveiligen en de minimale machtigingen bieden die zijn vereist voor een resourceset met een bereik, zoals één naamruimte. U kunt verschillende Azure AD-gebruikers of -groepen verschillende Kubernetes-rollen verlenen. Met gedetailleerde machtigingen kunt u de toegang tot de API-server beperken en een duidelijk audittrail bieden van uitgevoerde acties.

Het aanbevolen best practice is om groepen te gebruiken om toegang te bieden tot bestanden en mappen in plaats van afzonderlijke identiteiten. Gebruik bijvoorbeeld een Azure AD-groepslidmaatschap om gebruikers te binden aan Kubernetes-rollen in plaats van aan afzonderlijke gebruikers. Naarmate het groepslidmaatschap van een gebruiker verandert, worden de toegangsmachtigingen voor het AKS-cluster dienovereenkomstig gewijzigd.

Stel dat u de afzonderlijke gebruiker rechtstreeks aan een rol bindt en dat de functie van de taak wordt gewijzigd. Tijdens het bijwerken van de Azure AD-groepslidmaatschap, zijn de machtigingen voor het AKS-cluster niet van die groep. In dit scenario krijgt de gebruiker meer machtigingen dan nodig is.

Zie Best practices for authentication and authorization in AKS (Best practices voor verificatie en autorisatie in AKS)voor meer informatie over Azure AD-integratie, Kubernetes RBAC en Azure RBAC.

Containertoegang tot resources 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 roottoegang of bevoegde escalatie.

Op dezelfde manier als u gebruikers of groepen de minimaal vereiste bevoegdheden moet verlenen, moet u containers ook beperken tot alleen de benodigde acties en processen. Om het risico op aanvallen te minimaliseren, moet u voorkomen dat u toepassingen en containers configureert waarvoor geëscaleerde bevoegdheden of roottoegang is vereist.

Stel bijvoorbeeld in allowPrivilegeEscalation: false het podmanifest in. Met deze ingebouwde Kubernetes-beveiligingscontexten voor pods kunt u aanvullende machtigingen definiëren, zoals de gebruiker of groep die moet worden uitgevoerd als of de Linux-mogelijkheden om weer te geven. Zie Toegang tot beveiligde pods tot resources voor meer best practices.

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

1. Definieer Linux-beveiligingsfuncties op knooppuntniveau.
2. Functies implementeren via een podmanifest.

Ingebouwde Linux-beveiligingsfuncties zijn alleen beschikbaar op Linux-knooppunten en -pods.

App Armor

Als u containeracties wilt beperken, kunt u de AppArmor Linux-kernelbeveiligingsmodule gebruiken. AppArmor is beschikbaar als onderdeel van het onderliggende besturingssysteem van het AKS-knooppunt en is standaard ingeschakeld. U maakt AppArmor-profielen die lees-, schrijf- of uitvoeracties beperken, of systeemfuncties zoals het toevoegen van bestandssystemen. Standaard AppArmor-profielen beperken de toegang tot verschillende locaties en bieden een manier om containers logisch te isoleren /proc /sys van het onderliggende knooppunt. AppArmor werkt voor elke toepassing die wordt uitgevoerd op Linux, niet alleen kubernetes-pods.

Als u AppArmor in actie wilt zien, wordt in het volgende voorbeeld een profiel gemaakt dat schrijven naar bestanden voorkomt.

1. SSH naar een AKS-knooppunt.

2. Maak een bestand met de naam deny-write.profile.

3. Plak de volgende inhoud:

   #include <tunables/global>
   profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
     #include <abstractions/base>
   
     file,
     # Deny all file writes.
     deny /** w,
   }
   

AppArmor-profielen worden toegevoegd met behulp van de apparmor_parser opdracht .

1. Voeg het profiel toe aan AppArmor.

2. Geef de naam op van het profiel dat u in de vorige stap hebt gemaakt:

   sudo apparmor_parser deny-write.profile
   

   Als het profiel correct is geparseerd en toegepast op AppArmor, ziet u geen uitvoer en keert u terug naar de opdrachtprompt.

3. Maak op uw lokale computer een podmanifest met de naam aks-apparmor.yaml. Dit manifest:

   • Hiermee definieert u een aantekening voor container.apparmor.security.beta.kubernetes .
   • Verwijst naar het profiel voor weigeren/schrijven dat in de vorige stappen is gemaakt.

   apiVersion: v1
   kind: Pod
   metadata:
     name: hello-apparmor
     annotations:
       container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write
   spec:
     containers:
     - name: hello
       image: mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
       command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
   

4. Wanneer de pod is geïmplementeerd, gebruikt u controleren of de hello-apparmor-pod wordt weergeblokkeerd:

   $ kubectl get pods
   
   NAME             READY   STATUS    RESTARTS   AGE
   aks-ssh          1/1     Running   0          4m2s
   hello-apparmor   0/1     Blocked   0          50s
   

Zie AppArmor-profielen in Kubernetesvoor meer informatie over AppArmor.

Beveiligde computing

Hoewel AppArmor werkt voor elke Linux-toepassing, werkt seccomp (sec ure comp uting) op procesniveau. Seccomp is ook een Linux-kernelbeveiligingsmodule en wordt standaard ondersteund door de Docker-runtime die wordt gebruikt door AKS-knooppunten. Met seccomp kunt u containerproces-aanroepen beperken. Lijn af met de best practice om de container alleen minimale machtigingen te verlenen om te worden uitgevoerd door:

• Definiëren met filters welke acties moeten worden toegestaan of weigeren.
• Aantekeningen maken in een YAML-manifest van een pod om te koppelen aan het seccomp-filter.

Als u seccomp in actie wilt zien, maakt u een filter dat voorkomt dat machtigingen voor een bestand worden veranderd.

1. SSH naar een AKS-knooppunt.

2. Maak een seccomp-filter met de naam /var/lib/kubelet/seccomp/prevent-chmod.

3. Plak de volgende inhoud:

   {
     "defaultAction": "SCMP_ACT_ALLOW",
     "syscalls": [
       {
         "name": "chmod",
         "action": "SCMP_ACT_ERRNO"
       },
       {
         "name": "fchmodat",
         "action": "SCMP_ACT_ERRNO"
       },
       {
         "name": "chmodat",
         "action": "SCMP_ACT_ERRNO"
       }
     ]
   }
   

   In versie 1.19 en hoger moet u het volgende configureren:

   {
     "defaultAction": "SCMP_ACT_ALLOW",
     "syscalls": [
       {
         "names": ["chmod","fchmodat","chmodat"],
         "action": "SCMP_ACT_ERRNO"
       }
     ]
   }
   

4. Maak op uw lokale computer een podmanifest met de naam aks-seccomp.yaml en plak de volgende inhoud. Dit manifest:

   • Hiermee definieert u een aantekening voor seccomp.security.alpha.kubernetes.io .
   • Verwijst naar het filter prevent-chmod dat u in de vorige stap hebt gemaakt.

   apiVersion: v1
   kind: Pod
   metadata:
     name: chmod-prevented
     annotations:
       seccomp.security.alpha.kubernetes.io/pod: localhost/prevent-chmod
   spec:
     containers:
     - name: chmod
       image: mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
       command:
         - "chmod"
       args:
        - "777"
        - /etc/hostname
     restartPolicy: Never
   

   In versie 1.19 en hoger moet u het volgende configureren:

   apiVersion: v1
   kind: Pod
   metadata:
     name: chmod-prevented
   spec:
     securityContext:
       seccompProfile:
         type: Localhost
         localhostProfile: prevent-chmod
     containers:
     - name: chmod
       image: mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
       command:
         - "chmod"
       args:
        - "777"
        - /etc/hostname
     restartPolicy: Never
   

5. Implementeer de voorbeeldpod met behulp van de opdracht kubectl apply:

   kubectl apply -f ./aks-seccomp.yaml
   

6. Bekijk de podstatus met behulp van de opdracht kubectl get pods.

   • De pod rapporteert een fout.
   • De chmod opdracht kan niet worden uitgevoerd door het seccomp-filter, zoals wordt weergegeven in de volgende voorbeelduitvoer:

   $ kubectl get pods
   
   NAME                      READY     STATUS    RESTARTS   AGE
   chmod-prevented           0/1       Error     0          7s
   

Zie Beveiligingsprofielen voor Seccomp voor Docker voor meer informatie over beschikbare filters.

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, moet u regelmatig de Kubernetes-versie in uw AKS-cluster bijwerken.

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

• Nieuwe functies
• Oplossingen voor fouten of beveiliging

Nieuwe functies worden doorgaans door de alfa- en bètastatus verplaatst voordat ze stabiel worden. Eenmaal stabiel, algemeen beschikbaar en aanbevolen voor productiegebruik. Met de nieuwe releasecyclus van Kubernetes-functies kunt u Kubernetes bijwerken zonder dat u regelmatig wijzigingen ondervindt die problemen ondervinden of uw implementaties en sjablonen moet aanpassen.

AKS ondersteunt drie secundaire versies van Kubernetes. Zodra een nieuwe secundaire patchversie is geïntroduceerd, worden de oudste secundaire versie en ondersteunde patchreleases teruggetrokken. Kleine Kubernetes-updates worden periodiek uitgevoerd. Zorg ervoor dat u een governanceproces hebt om te controleren op benodigde upgrades om binnen de ondersteuning te blijven. 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

U kunt vervolgens uw AKS-cluster upgraden met de opdracht az aks upgrade. Het upgradeproces veilig:

• Cordons en één knooppunt per keer leeg.
• Plant pods op resterende knooppunten.
• Implementeert een nieuw knooppunt met de nieuwste versies van het besturingssysteem en Kubernetes.

az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version KUBERNETES_VERSION

Zie Ondersteunde Kubernetes-versies in AKS en Een AKS-cluster upgradenvoor meer informatie over upgrades in AKS.

Updates van Linux-knooppunt verwerken

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

Upgrades voor knooppuntafbeeldingen

Upgrades zonder toezicht passen updates toe op het besturingssysteem van het Linux-knooppunt, maar de afbeelding die wordt gebruikt om knooppunten voor uw cluster te maken, blijft ongewijzigd. Als er een nieuw Linux-knooppunt wordt toegevoegd aan uw cluster, wordt de oorspronkelijke afbeelding gebruikt om het knooppunt te maken. Dit nieuwe knooppunt ontvangt alle beveiligings- en kernelupdates die elke nacht beschikbaar zijn tijdens de automatische controle, maar blijft ongepatcht totdat alle controles en opnieuw opstarten zijn voltooid. U kunt de upgrade van knooppuntafbeeldingen gebruiken om te controleren op knooppuntafbeeldingen die door uw cluster worden gebruikt en deze bij te werken. Zie voor meer informatie over het upgraden van knooppuntafbeeldingen Azure Kubernetes Service (AKS) node image upgrade.

Updates Windows Server-knooppunt verwerken

Voor Windows Server-knooppunten voert u regelmatig een upgradebewerking voor de knooppuntafbeelding uit om pods veilig aan te houden en te verwijderen en bijgewerkte knooppunten te implementeren.