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

  • Artikel

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.

Microsoft Entra integration for AKS clusters

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 --enable-managed-identity --network-plugin azure --network-policy azure

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.

Stel bijvoorbeeld allowPrivilegeEscalation: false in het podmanifest in. Met deze ingebouwde Kubernetes-beveiligingscontexten kunt u aanvullende machtigingen definiëren, zoals de gebruiker of groep die moet worden uitgevoerd als, of de Linux-mogelijkheden om beschikbaar te maken. Zie Beveiligde podtoegang tot resources voor meer aanbevolen procedures.

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

  1. Definieer Linux-beveiligingsfuncties op knooppuntniveau.
  2. Implementeer functies via een podmanifest.

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

Notitie

Momenteel zijn Kubernetes-omgevingen niet volledig veilig voor vijandig gebruik met meerdere tenants. Aanvullende beveiligingsfuncties, zoals Microsoft Defender for ContainersAppArmor, seccomp, Pod Security Admission of Kubernetes RBAC voor knooppunten, blokkeren aanvallen efficiënt.

Voor echte beveiliging bij het uitvoeren van vijandige workloads met meerdere tenants vertrouwt u alleen een hypervisor. Het beveiligingsdomein voor Kubernetes wordt het hele cluster, niet een afzonderlijk knooppunt.

Voor deze typen vijandige workloads met meerdere tenants moet u fysiek geïsoleerde clusters gebruiken.

App Armor

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

AppArmor profiles in use in an AKS cluster to limit container actions

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

  1. SSH naar een AKS-knooppunt.

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

  3. Kopieer en 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 wordt geparseerd en toegepast op AppArmor, ziet u geen uitvoer en wordt u teruggezet 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 deny-write-profiel 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/dotnet/runtime-deps:6.0
    command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]

  4. Wanneer de pod is geïmplementeerd, voert u de volgende opdracht uit en controleert u of de hello-apparmor-pod de status Actief heeft:

    kubectl get pods

NAME             READY   STATUS    RESTARTS   AGE
aks-ssh          1/1     Running   0          4m2s
hello-apparmor   0/1     Running   0          50s

Zie AppArmor-profielen in Kubernetes voor meer informatie over AppArmor.

Beveiligde computing

Hoewel AppArmor werkt voor elke Linux-toepassing, werkt seccomp (secure compting) op procesniveau. Seccomp is ook een Linux-kernelbeveiligingsmodule en wordt systeemeigen ondersteund door de Docker-runtime die wordt gebruikt door AKS-knooppunten. Met seccomp kunt u containerprocesaanroepen beperken. Uitlijnen op de aanbevolen procedure voor het verlenen van minimale machtigingen aan de container om alleen te worden uitgevoerd door:

  • Definiëren met filters welke acties moeten worden toegestaan of geweigerd.
  • Aantekeningen toevoegen in een YAML-manifest voor pods om te koppelen aan het seccomp-filter.

Als u seccomp in actie wilt zien, maakt u een filter waarmee het wijzigen van machtigingen voor een bestand wordt voorkomen.

  1. SSH naar een AKS-knooppunt.

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

  3. Kopieer en 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 in de vorige stap is 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/dotnet/runtime-deps:6.0
    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/dotnet/runtime-deps:6.0
    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 Seccomp-beveiligingsprofielen 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, 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.