Metodtips för klustersäkerhet och uppgraderingar i Azure Kubernetes Service (AKS)

  • Artikel

När du hanterar kluster i Azure Kubernetes Service (AKS) är arbetsbelastning och datasäkerhet en viktig faktor. När du kör kluster för flera klientorganisationer med logisk isolering behöver du särskilt skydda åtkomsten till resurser och arbetsbelastningar. Minimera risken för angrepp genom att tillämpa de senaste säkerhetsuppdateringarna för Kubernetes och nodens operativsystem.

Den här artikeln fokuserar på hur du skyddar ditt AKS-kluster. Du lär dig att:

  • Använd Microsoft Entra ID och rollbaserad Kubernetes-åtkomstkontroll (Kubernetes RBAC) för att skydda API-serveråtkomst.
  • Skydda containeråtkomst till nodresurser.
  • Uppgradera ett AKS-kluster till den senaste Kubernetes-versionen.
  • Håll noderna uppdaterade och tillämpa säkerhetskorrigeringar automatiskt.

Du kan också läsa metodtipsen för hantering av containeravbildningar och för poddsäkerhet.

Aktivera skydd mot hot

Vägledning för bästa praxis

Du kan aktivera Defender for Containers för att skydda dina containrar. Defender for Containers kan utvärdera klusterkonfigurationer och tillhandahålla säkerhetsrekommendationer, köra sårbarhetsgenomsökningar och tillhandahålla realtidsskydd och aviseringar för Kubernetes-noder och kluster.

Säker åtkomst till API-servern och klusternoderna

Vägledning för bästa praxis

Ett av de viktigaste sätten att skydda klustret är att skydda åtkomsten till Kubernetes API-servern. Om du vill styra åtkomsten till API-servern integrerar du Kubernetes RBAC med Microsoft Entra-ID. Med dessa kontroller skyddar du AKS på samma sätt som du skyddar åtkomsten till dina Azure-prenumerationer.

Kubernetes API-servern tillhandahåller en enda anslutningspunkt för begäranden om att utföra åtgärder i ett kluster. För att skydda och granska åtkomsten till API-servern begränsar du åtkomsten och ger lägsta möjliga behörighetsnivåer. Även om den här metoden inte är unik för Kubernetes är det särskilt viktigt när du logiskt har isolerat DITT AKS-kluster för användning med flera klientorganisationer.

Microsoft Entra ID tillhandahåller en företagsklar identitetshanteringslösning som integreras med AKS-kluster. Eftersom Kubernetes inte tillhandahåller någon identitetshanteringslösning kan du vara hårt pressad att detaljerad begränsa åtkomsten till API-servern. Med Microsoft Entra-integrerade kluster i AKS använder du dina befintliga användar- och gruppkonton för att autentisera användare till API-servern.

Microsoft Entra integration for AKS clusters

Med Kubernetes RBAC och Microsoft Entra ID-integrering kan du skydda API-servern och ange de minsta behörigheter som krävs för en begränsad resursuppsättning, till exempel ett enda namnområde. Du kan bevilja olika Microsoft Entra-användare eller grupper olika Kubernetes-roller. Med detaljerade behörigheter kan du begränsa åtkomsten till API-servern och tillhandahålla en tydlig spårningslogg med åtgärder som utförs.

Vi rekommenderar att du använder grupper för att ge åtkomst till filer och mappar i stället för enskilda identiteter. Använd till exempel ett Microsoft Entra ID-gruppmedlemskap för att binda användare till Kubernetes-roller i stället för enskilda användare. När en användares gruppmedlemskap ändras ändras deras åtkomstbehörigheter för AKS-klustret i enlighet med detta.

Anta samtidigt att du binder den enskilda användaren direkt till en roll och att deras jobbfunktion ändras. Även om Microsoft Entra-gruppmedlemskapen uppdateras skulle deras behörigheter för AKS-klustret inte göra det. I det här scenariot får användaren fler behörigheter än de behöver.

Mer information om Microsoft Entra-integrering, Kubernetes RBAC och Azure RBAC finns i Metodtips för autentisering och auktorisering i AKS.

Begränsa åtkomsten till API för instansmetadata

Vägledning för bästa praxis

Lägg till en nätverksprincip i alla användarnamnrymder för att blockera poddutgåendet till metadataslutpunkten.

Kommentar

Om du vill implementera nätverksprincip tar du med attributet --network-policy azure när du skapar AKS-klustret. Använd följande kommando för att skapa klustret: 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

Skydda containeråtkomst till resurser

Vägledning för bästa praxis

Begränsa åtkomsten till åtgärder som containrar kan utföra. Ange minst antal behörigheter och undvik att använda rotåtkomst eller privilegierad eskalering.

På samma sätt som du bör ge användare eller grupper de minsta behörigheter som krävs bör du också begränsa containrar till endast nödvändiga åtgärder och processer. Undvik att konfigurera program och containrar som kräver eskalerade privilegier eller rotåtkomst för att minimera risken för angrepp.

Ange till exempel allowPrivilegeEscalation: false i poddmanifestet. Med de här inbyggda Kubernetes-poddsäkerhetskontexterna kan du definiera ytterligare behörigheter, till exempel den användare eller grupp som ska köras som, eller de Linux-funktioner som ska exponeras. Mer metodtips finns i Säker poddåtkomst till resurser.

Om du vill ha ännu mer detaljerad kontroll över containeråtgärder kan du också använda inbyggda Linux-säkerhetsfunktioner som AppArmor och seccomp.

  1. Definiera Linux-säkerhetsfunktioner på nodnivå.
  2. Implementera funktioner via ett poddmanifest.

Inbyggda Linux-säkerhetsfunktioner är endast tillgängliga på Linux-noder och poddar.

Kommentar

För närvarande är Kubernetes-miljöer inte helt säkra för fientlig användning av flera klientorganisationer. Ytterligare säkerhetsfunktioner, till exempel Microsoft Defender for ContainersAppArmor, seccomp, Pod Security Admission eller Kubernetes RBAC för noder, blockerar effektivt kryphål.

För verklig säkerhet när du kör fientliga arbetsbelastningar med flera klientorganisationer kan du bara lita på ett hypervisor-program. Säkerhetsdomänen för Kubernetes blir hela klustret, inte en enskild nod.

För dessa typer av fientliga arbetsbelastningar med flera klientorganisationer bör du använda fysiskt isolerade kluster.

App Armor

Om du vill begränsa containeråtgärder kan du använda säkerhetsmodulen AppArmor Linux kernel. AppArmor är tillgängligt som en del av det underliggande AKS-nodoperativsystemet och är aktiverat som standard. Du skapar AppArmor-profiler som begränsar läs-, skriv- eller körningsåtgärder eller systemfunktioner som montering av filsystem. AppArmor-standardprofiler begränsar åtkomsten till olika /proc platser och /sys ger ett sätt att logiskt isolera containrar från den underliggande noden. AppArmor fungerar för alla program som körs på Linux, inte bara Kubernetes-poddar.

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

Om du vill se hur AppArmor fungerar skapar följande exempel en profil som förhindrar att filer skrivs.

  1. SSH till en AKS-nod.

  2. Skapa en fil med namnet deny-write.profile.

  3. Kopiera och klistra in följande innehåll:

    #include <tunables/global>
profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
  #include <abstractions/base>

  file,
  # Deny all file writes.
  deny /** w,
}

AppArmor-profiler läggs till med kommandot apparmor_parser .

  1. Lägg till profilen i AppArmor.

  2. Ange namnet på profilen som skapades i föregående steg:

    sudo apparmor_parser deny-write.profile

    Om profilen parsas och tillämpas korrekt på AppArmor visas inga utdata och du kommer att returneras till kommandotolken.

  3. Skapa ett poddmanifest med namnet aks-apparmor.yaml från den lokala datorn. Det här manifestet:

    • Definierar en anteckning för container.apparmor.security.beta.kubernetes.
    • Refererar till den neka-skriv-profil som skapades i föregående steg.
    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. När podden har distribuerats kör du följande kommando och kontrollerar att hello-apparmor-podden visar statusen Körs :

    kubectl get pods

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

Mer information om AppArmor finns i AppArmor-profiler i Kubernetes.

Säker databehandling

Medan AppArmor fungerar för alla Linux-program fungerar seccomp (secure computing) på processnivå. Seccomp är också en Linux-kernelsäkerhetsmodul och stöds internt av Den Docker-körning som används av AKS-noder. Med seccomp kan du begränsa containerprocessanrop. Anpassa till bästa praxis för att ge containern minimal behörighet att endast köras av:

  • Definiera med filter vilka åtgärder som ska tillåtas eller nekas.
  • Kommentera i ett YAML-poddmanifest som ska associeras med seccomp-filtret.

Om du vill se seccomp i praktiken skapar du ett filter som förhindrar att behörigheter ändras för en fil.

  1. SSH till en AKS-nod.

  2. Skapa ett seccomp-filter med namnet /var/lib/kubelet/seccomp/prevent-chmod.

  3. Kopiera och klistra in följande innehåll:

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

    I version 1.19 och senare måste du konfigurera följande:

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

  4. Från den lokala datorn skapar du ett poddmanifest med namnet aks-seccomp.yaml och klistrar in följande innehåll. Det här manifestet:

    • Definierar en anteckning för seccomp.security.alpha.kubernetes.io.
    • Refererar till filtret prevent-chmod som skapades i föregående steg.
    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

    I version 1.19 och senare måste du konfigurera följande:

    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. Distribuera exempelpodden med kommandot kubectl apply :

    kubectl apply -f ./aks-seccomp.yaml

  6. Visa poddstatus med kommandot kubectl get pods .

    • Podden rapporterar ett fel.
    • Kommandot chmod hindras från att köras av seccomp-filtret, enligt följande exempelutdata:
    kubectl get pods

NAME                      READY     STATUS    RESTARTS   AGE
chmod-prevented           0/1       Error     0          7s

Mer information om tillgängliga filter finns i Seccomp-säkerhetsprofiler för Docker.

Uppdatera regelbundet till den senaste versionen av Kubernetes

Vägledning för bästa praxis

Om du vill hålla dig uppdaterad om nya funktioner och felkorrigeringar uppgraderar du regelbundet Kubernetes-versionen i AKS-klustret.

Kubernetes släpper nya funktioner i snabbare takt än mer traditionella infrastrukturplattformar. Kubernetes-uppdateringar inkluderar:

  • Nya funktioner
  • Bugg- eller säkerhetskorrigeringar

Nya funktioner går vanligtvis igenom alfa- och betastatus innan de blir stabila. När de är stabila är de allmänt tillgängliga och rekommenderas för produktionsanvändning. Med kubernetes nya funktionsversionscykel kan du uppdatera Kubernetes utan att regelbundet stöta på icke-bakåtkompatibla ändringar eller justera dina distributioner och mallar.

AKS stöder tre mindre versioner av Kubernetes. När en ny delkorrigeringsversion introduceras dras den äldsta delversionen och korrigeringsversionerna som stöds tillbaka. Mindre Kubernetes-uppdateringar sker regelbundet. Se till att du har en styrningsprocess för att söka efter nödvändiga uppgraderingar för att hålla dig inom supporten. Mer information finns i Kubernetes-versioner som stöds AKS.

Om du vill kontrollera vilka versioner som är tillgängliga för klustret använder du kommandot az aks get-upgrades enligt följande exempel:

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

Du kan sedan uppgradera AKS-klustret med hjälp av kommandot az aks upgrade . Uppgraderingsprocessen på ett säkert sätt:

  • Avspärrningar och tömmer en nod i taget.
  • Schemalägger poddar på återstående noder.
  • Distribuerar en ny nod som kör de senaste versionerna av operativsystemet och Kubernetes.

Viktigt!

Testa nya delversioner i en utvecklingstestmiljö och kontrollera att din arbetsbelastning förblir felfri med den nya Kubernetes-versionen.

Kubernetes kan inaktuella API:er (till exempel i version 1.16) som dina arbetsbelastningar förlitar sig på. När du tar nya versioner till produktion bör du överväga att använda flera nodpooler i separata versioner och uppgradera enskilda pooler en i taget för att successivt rulla uppdateringen över ett kluster. Om du kör flera kluster uppgraderar du ett kluster i taget för att progressivt övervaka påverkan eller ändringar.

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

Mer information om uppgraderingar i AKS finns i Kubernetes-versioner som stöds i AKS och Uppgradera ett AKS-kluster.

Bearbeta linux-noduppdateringar

Varje kväll får Linux-noder i AKS säkerhetskorrigeringar via distributionsuppdateringskanalen. Det här beteendet konfigureras automatiskt när noderna distribueras i ett AKS-kluster. För att minimera störningar och potentiell påverkan på arbetsbelastningar som körs startas noder inte automatiskt om en säkerhetskorrigering eller kerneluppdatering kräver det. Mer information om hur du hanterar nodomstarter finns i Tillämpa säkerhets- och kerneluppdateringar på noder i AKS.

Uppgraderingar av nodbild

Obevakade uppgraderingar tillämpar uppdateringar på Linux-nodoperativsystemet, men avbildningen som används för att skapa noder för klustret förblir oförändrad. Om en ny Linux-nod läggs till i klustret används den ursprungliga avbildningen för att skapa noden. Den här nya noden får alla säkerhets- och kerneluppdateringar som är tillgängliga under den automatiska kontrollen varje natt, men förblir okopplade tills alla kontroller och omstarter har slutförts. Du kan använda nodavbildningsuppgradering för att söka efter och uppdatera nodavbildningar som används av klustret. Mer information om uppgradering av nodbild finns i Azure Kubernetes Service (AKS) nodbilduppgradering.

Bearbeta windows server-noduppdateringar

För Windows Server-noder utför du regelbundet en uppgraderingsåtgärd för nodavbildning för att på ett säkert sätt spärra och tömma poddar och distribuera uppdaterade noder.