Åtkomst till säkerhetscontainer till resurser med hjälp av inbyggda Linux-säkerhetsfunktioner

I den här artikeln får du lära dig hur du skyddar containeråtkomsten till resurser för dina Azure Kubernetes Service-arbetsbelastningar (AKS).

Översikt

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.

Du kan använda inbyggda Kubernetes-poddsäkerhetskontexter för att definiera fler behörigheter, till exempel användaren eller gruppen som ska köras som, De Linux-funktioner som ska exponeras eller inställningen allowPrivilegeEscalation: false i poddmanifestet. Mer metodtips finns i Säker poddåtkomst till resurser.

För att förbättra värdisoleringen och minska lateral förflyttning i Linux kan du använda användarnamnrymder.

Om du vill ha ännu mer detaljerad kontroll över containeråtgärder kan du 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.

Användarnamnrymder

Linux-poddar körs som standard med flera namnområden: ett nätverksnamnområden för att isolera nätverksidentiteten och ett PID-namnområde för att isolera processerna. Ett användarnamnområde isolerar användarna i containern från användarna på värden. Det begränsar även omfattningen av funktioner och poddens interaktioner med resten av systemet.

Användargränssnitten och GID:erna i containern mappas till oprivilegierade användare på värden, så all interaktion med resten av värden sker som de oprivilegierade UID och GID. Roten i containern (UID 0) kan till exempel mappas till användaren 65536 på värden. Kubernetes skapar mappningen för att garantera att den inte överlappar andra poddar med hjälp av användarnamnrymder i systemet.

Kubernetes-implementeringen har några viktiga fördelar:

• Ökad värdisolering: Om en container undflyr poddgränserna, även om den körs som rot i containern, har den inga behörigheter på värden. Orsaken är att UID:erna och GID:erna för containern mappas till oprivilegierade användare på värden. Om det finns en container escape skyddar användarnamnrymder i hög grad vilka filer på värden som en container kan läsa/skriva, vilken process den kan skicka signaler till. De funktioner som beviljas är endast giltiga i användarnamnområdet och inte på värden.

• Förebyggande av lateral förflyttning: Eftersom användargränssnitten och GID:erna för olika containrar mappas till olika, icke-överlappande användargränssnitt och GID:er på värden, har containrar svårare att attackera varandra. Anta till exempel att container A körs med olika användargränssnitt och GID:er på värden än container B. I händelse av ett containerutbrott är de åtgärder som kan utföras på filer och processer i container B begränsade: läs/skriv bara vad en fil tillåter för andra. Men inte ens det blir möjligt, eftersom det finns ett extra skydd på den överordnade katalogen för poddrotvolymen för att se till att endast podd-GID:t kan komma åt den.

• Respektera principen för lägsta behörighet: Eftersom användargränssnitten och GID:erna mappas till icke privilegierade användare på värden får endast användare som behöver behörigheten på värden (och inaktiverar användarnamnområden) den. Utan användarnamn finns det ingen separation mellan containerns användare och värdens användare. Vi kan inte undvika att ge värden behörighet till processer som inte behöver det, när de behöver behörighet bara i containern.

• Aktivering av nya användningsfall: Med användarnamn kan containrar få vissa funktioner i sitt eget användarnamnområde utan att det påverkar värden. De funktioner som beviljas begränsade till podden låser upp nya möjligheter, till exempel att köra program som kräver privilegierade åtgärder utan att bevilja fullständig rotåtkomst på värden. Vanliga nya användningsfall som kan implementeras på ett säkert sätt är: köra kapslade containrar och icke-privilegierade containerversioner.

• Konfiguration av oprivilegierad container: Merparten av containerskapandet och konfigurationen körs inte som rot på värden, vilket avsevärt begränsar effekten av många CVE:er.

Inget av det här stämmer när användarnamnrymder inte används. Om containern körs som rot, när användarnamnrymder inte används, körs processen som rot på värden, funktionerna är giltiga på värden och containerkonfigurationen görs som rot på värden.

Innan du börjar

Kontrollera att du har följande innan du börjar:

• Ett befintligt AKS-kluster. Om du inte har ett kluster skapar du ett med hjälp av Azure CLI, Azure PowerShell eller Azure Portal.
• Minsta kubernetes version 1.33 för kontrollplanet och arbetsnoderna. Om du inte använder kubernetes version 1.33 eller senare måste du uppgradera kubernetes-versionen.
• Arbetsnoder som kör Azure Linux 3.0 eller Ubuntu 24.04. Om du inte använder dessa os-versioner har du inte de minsta stackkraven för att aktivera användarnamnrymder. Du måste uppgradera operativsystemversionen.

Begränsningar

• User-namespaces är en linux-kernelfunktion och stöds inte för Windows-nodpooler.
• Tveka inte att kontrollera Kubernetes-dokumentationen för användarnamnrymder, särskilt avsnittet begränsningar.

Aktivera användarnamnrymder

Det behövs inga konfigurationer för att använda den här funktionen. Om du använder den nödvändiga AKS-versionen fungerar allt direkt.

1. Skapa en fil med namnet mypod.yaml och kopiera i följande manifest:

   Om du vill använda användarnamn måste yaml-filen ha fältet hostUsers: false.

   apiVersion: v1
   kind: Pod
   metadata:
     name: userns
   spec:
     hostUsers: false
     containers:
     - name: shell
       command: ["sleep", "infinity"]
       image: debian
   

2. Distribuera programmet med kommandot kubectl apply och ange namnet på ditt YAML-manifest.

   kubectl apply -f mypod.yaml
   

3. Kontrollera statusen för de distribuerade poddarna med kommandot kubectl get pods .

   kubectl get pods
   

4. Gå till podden för att kontrollera /proc/self/uid_map med hjälp kubectl exec av kommandot :

   kubectl exec -ti userns -- bash
   # Now inside the pod run
   cat /proc/self/uid_map
   

Utdata ska ha 65536 i den sista kolumnen. Till exempel:

0  833617920      65536

CVE:er har åtgärdats

Här följer några CVE:er som är helt/delvis minimerade med användarnamnrymder.

Kom ihåg att listan inte är fullständig, det är bara ett urval av CVE:er med höga poäng som minimeras:

• CVE-2019-5736 - Poäng 8,6 (HÖG)
• CVE 2024-21262: Poäng 8,6 (HÖG)
• CVE 2022-0492: Poäng 7,8 (HÖG)
• CVE-2021-25741: Poäng: 8,1 (HÖG) / 8,8 (HÖG)
• CVE-2017-1002101: Poäng: 9,6 (KRITISK) / 8,8 (HÖG)

Mer information finns i det här blogginlägget med ytterligare information om användarnamnrymder.

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.

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 återgår 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 (sekcomp)

Medan AppArmor fungerar för alla Linux-program fungerar seccomp (secure computing) på processnivå. Seccomp är också en Säkerhetsmodul för Linux-kernel och stöds internt av den containerd körning som används av AKS-noder. Med seccomp kan du begränsa en containers systemanrop. Seccomp etablerar ett extra skydd mot vanliga sårbarheter för systemanrop som utnyttjas av skadliga aktörer och gör att du kan ange en standardprofil för alla arbetsbelastningar i noden.

Konfigurera en standardprofil för seccomp (förhandsversion)

Du kan använda standardprofiler för seccomp med hjälp av anpassade nodkonfigurationer när du skapar en ny Linux-nodpool. Det finns två värden som stöds i AKS: RuntimeDefault och Unconfined. Vissa arbetsbelastningar kan kräva ett lägre antal syscall-begränsningar än andra. Det innebär att de kan misslyckas under körningen med profilen "RuntimeDefault". Om du vill undvika ett sådant fel kan du ange profilen Unconfined . Om din arbetsbelastning kräver en anpassad profil kan du läsa Konfigurera en anpassad seccomp-profil.

Begränsningar

• SeccompDefault är inte en parameter som stöds för windows-nodpooler.
• SeccompDefault är tillgängligt från och med 2024-09-02-preview API.

Registrera funktionsflaggan KubeletDefaultSeccompProfilePreview

1. Registrera funktionsflaggan KubeletDefaultSeccompProfilePreviewaz feature register med kommandot .

   az feature register --namespace "Microsoft.ContainerService" --name "KubeletDefaultSeccompProfilePreview"
   

   Det tar några minuter för statusen att visa Registrerad.

2. Kontrollera registreringsstatusen az feature show med kommandot .

   az feature show --namespace "Microsoft.ContainerService" --name "KubeletDefaultSeccompProfilePreview"
   

3. När statusen visar Registrerad uppdaterar du registreringen av resursprovidern Microsoft.ContainerService med hjälp av az provider register kommandot .

   az provider register --namespace Microsoft.ContainerService
   

Begränsa containerns systemanrop med seccomp

1. Följ stegen för att tillämpa en seccomp-profil i kubelet-konfigurationen genom att "seccompDefault": "RuntimeDefault"ange .

RuntimeDefault använder containerds standardprofil för seccomp, vilket begränsar vissa systemanrop för att förbättra säkerheten. Begränsade syscalls misslyckas. Mer information finns i standardprofilen för seccomp för containerD.

2. Kontrollera att konfigurationen har tillämpats.

Du kan bekräfta att inställningarna tillämpas på noderna genom att ansluta till värden och verifiera att konfigurationsändringar har gjorts i filsystemet.

3. Felsöka arbetsbelastningsfel.

När SeccompDefault är aktiverat används standardprofilen seccomp för containerkörning som standard för alla arbetsbelastningar som schemalagts på noden. Detta kan orsaka att arbetsbelastningar misslyckas på grund av blockerade syscalls. Om ett arbetsbelastningsfel har inträffat kan du se fel som:

• Arbetsbelastningen finns oväntat när funktionen har aktiverats, med felet "behörighet nekad".
• Seccomp-felmeddelanden kan också visas i gransknings- eller syslog genom att ersätta SCMP_ACT_ERRNO med SCMP_ACT_LOG i standardprofilen.

Om du får ovanstående fel rekommenderar vi att du ändrar seccomp-profilen till Unconfined. Unconfined ställer inga begränsningar för syscalls, vilket tillåter alla systemanrop, vilket minskar säkerheten.

Konfigurera en anpassad seccomp-profil

Med en anpassad seccomp-profil kan du ha mer detaljerad kontroll över begränsade syscalls. 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:

   {
     "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:

   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, vilket visas i exempelutdata:

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

Hjälp med att felsöka din seccomp-profil finns i artikeln Felsöka konfiguration av seccomp-profil i Azure Kubernetes Service.

Säkerhetsprofilalternativ för Seccomp

Seccomp-säkerhetsprofiler är en uppsättning definierade syscalls som är tillåtna eller begränsade. De flesta containerkörningar har en standardprofil för seccomp som är liknande om inte samma som den Som Docker använder. Mer information om tillgängliga profiler finns i Docker - eller containerD-standardprofiler för seccomp.

AKS använder standardprofilen för seccomp för containerD för vår RuntimeDefault när du konfigurerar seccomp med hjälp av anpassad nodkonfiguration.

Betydande syscalls blockerade som standardprofil

Både Docker och containerD underhåller tillåtna listor över säkra syscalls. Den här tabellen visar de betydande (men inte alla) syscalls som effektivt blockeras eftersom de inte finns på listan över tillåtna. Om någon av de blockerade syscalls krävs av din arbetsbelastning ska du inte använda RuntimeDefault seccomp-profilen.

När ändringar görs i Docker och containerD uppdaterar AKS sin standardkonfiguration så att den matchar. Uppdateringar av den här listan kan orsaka arbetsbelastningsfel. Information om versionsuppdateringar finns i viktig information om AKS.

Nästa steg

För tillhörande metodtips, se Metodtips för klustersäkerhet och uppgraderingar i AKS och Metodtips för poddsäkerhet i AKS.