Beveilig toegang tot resources met behulp van ingebouwde Linux-beveiligingscontainers.

In dit artikel leert u hoe u containertoegang tot resources voor uw AKS-workloads (Azure Kubernetes Service) kunt beveiligen.

Overzicht

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.

U kunt ingebouwde Kubernetes-beveiligingscontexten voor pods gebruiken om meer machtigingen te definiëren, zoals de gebruiker of groep die moet worden uitgevoerd als, de Linux-mogelijkheden voor het beschikbaar maken of instellen allowPrivilegeEscalation: false in het podmanifest. Voor meer aanbevolen procedures raadpleeg Beveiligde podtoegang tot bronnen.

U kunt gebruikersnaamruimten gebruiken om de hostisolatie te verbeteren en de zijwaartse verplaatsing op Linux te verminderen.

Voor nog gedetailleerdere controle over containeracties kunt u 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.

Gebruikersnaamruimten

Linux-pods worden standaard uitgevoerd met behulp van verschillende naamruimten: een netwerknaamruimten om de netwerkidentiteit en een PID-naamruimte te isoleren om de processen te isoleren. Een gebruikersnaamruimte isoleert de gebruikers in de container van de gebruikers op de host. Het beperkt ook het bereik van mogelijkheden en de interacties van de pod met de rest van het systeem.

De UID's en GID's in de container worden toegewezen aan onbevoegde gebruikers op de host, zodat alle interactie met de rest van de host plaatsvindt als die niet-gemachtigde UID en GID. Root in de container (UID 0) kan bijvoorbeeld worden toegewezen aan gebruiker 65536 op de host. Kubernetes maakt de toewijzing om te garanderen dat deze niet overlapt met andere pods met behulp van gebruikersnaamruimten op het systeem.

De Kubernetes-implementatie heeft enkele belangrijke voordelen:

• Verhoogde hostisolatie: als een container de podgrenzen overschrijdt, zelfs als deze als root binnen de container wordt uitgevoerd, heeft deze geen bevoegdheden op de host. De reden hiervoor is dat de UID's en GID's van de container zijn toegewezen aan onbevoegde gebruikers op de host. Als er sprake is van een escape-container, worden met user-namespaces aanzienlijk beschermd naar welke bestanden op de host een container kan lezen/schrijven. Dit proces kan signalen verzenden. De verleende mogelijkheden zijn alleen geldig in de gebruikersnaamruimte en niet op de host.

• Preventie van laterale verplaatsing: Omdat de UID's en GID's voor verschillende containers worden toegewezen aan verschillende, niet-overlapping van UID's en GID's op de host, hebben containers een moeilijkere tijd om elkaar aan te vallen. Stel dat container A wordt uitgevoerd met verschillende UID's en GID's op de host dan container B. In het geval van een containeronderbreking zijn de bewerkingen die kunnen worden uitgevoerd op de bestanden en processen van container B beperkt: alleen lezen/schrijven wat een bestand toestaat aan anderen. Maar zelfs dat is niet mogelijk, omdat er een extra preventie is op de bovenliggende map van het podhoofdvolume om ervoor te zorgen dat alleen de POD GID er toegang toe heeft.

• Honor Least-privilege principle: Omdat de UID's en GID's worden toegewezen aan onbevoegde gebruikers op de host, krijgen alleen gebruikers die de bevoegdheid op de host nodig hebben (en gebruikersnaamruimten uitschakelen) deze. Zonder gebruikersnaamruimten is er geen scheiding tussen de gebruikers van de container en de gebruikers van de host. We kunnen niet voorkomen dat de host bevoegdheden krijgt voor processen die deze niet nodig hebben, wanneer ze bevoegdheden nodig hebben, net binnen de container.

• Inschakeling van nieuwe gebruiksvoorbeelden: Met gebruikersnaamruimten kunnen containers bepaalde mogelijkheden binnen hun eigen gebruikersnaamruimte verkrijgen zonder dat dit van invloed is op de host. De mogelijkheden die zijn verleend voor de pod, ontgrendelen nieuwe mogelijkheden, zoals het uitvoeren van toepassingen waarvoor bevoegde bewerkingen nodig zijn zonder volledige toegang tot de hoofdmap op de host te verlenen. Veelvoorkomende nieuwe use-cases die veilig kunnen worden geïmplementeerd, zijn: geneste containers en niet-gemachtigde container-builds uitvoeren.

• Niet-gemachtigde containerinstallatie: het grootste deel van de container maken en instellen wordt niet uitgevoerd als root op de host, waardoor de impact van veel CVE's aanzienlijk wordt beperkt.

Geen van deze dingen geldt wanneer gebruikersnaamruimten niet worden gebruikt. Als de container wordt uitgevoerd als root, wanneer gebruikersnaamruimten niet worden gebruikt, wordt het proces uitgevoerd als root op de host, zijn de mogelijkheden geldig op de host en wordt de containerinstallatie uitgevoerd als hoofdmap op de host.

Voordat u begint

Voordat u begint, controleert u of u het volgende hebt:

• Een bestaand AKS-cluster. Als u geen cluster hebt, maakt u er een met behulp van de Azure CLI, Azure PowerShell of Azure Portal.
• Minimale kubernetes-versie 1.33 voor het besturingsvlak en werkknooppunten. Als u geen kubernetes-versie 1.33 of hoger gebruikt, moet u uw kubernetes-versie upgraden.
• Werkknooppunten met Azure Linux 3.0 of Ubuntu 24.04. Als u deze versies van het besturingssysteem niet gebruikt, hebt u niet de minimale stackvereisten om gebruikersnaamruimten in te schakelen. U moet uw versie van het besturingssysteem upgraden.

Beperkingen

• User-namespaces is een Linux-kernelfunctie en wordt niet ondersteund voor Windows-knooppuntgroepen.
• Aarzel niet om de Kubernetes-documentatie voor gebruikersnaamruimten te controleren, met name de sectie beperkingen.

Gebruikersnaamruimten inschakelen

Er zijn geen configuraties nodig om deze functie te gebruiken. Als u de vereiste AKS-versie gebruikt, werkt alles uit de doos.

1. Maak een bestand met de naam mypod.yaml en kopieer dit in het volgende manifest:

   Als u gebruikersnaamruimten wilt gebruiken, moet de yaml het veld hostUsers: falsehebben.

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

2. Implementeer de toepassing met behulp van de kubectl apply opdracht en geef de naam van uw YAML-manifest op.

   kubectl apply -f mypod.yaml
   

3. Controleer de status van de geïmplementeerde pods met behulp van de kubectl get pods opdracht.

   kubectl get pods
   

4. Exec in de pod om te controleren /proc/self/uid_map met behulp van de kubectl exec opdracht:

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

De uitvoer moet 65536 bevatten in de laatste kolom. Voorbeeld:

0  833617920      65536

CV's beperkt

Hier volgen enkele CVE's die volledig/gedeeltelijk worden beperkt met gebruikersnaamruimten.

Houd er rekening mee dat de lijst niet volledig is, het is slechts een selectie van CV's met een hoge score die wordt beperkt:

• CVE-2019-5736 - Score 8,6 (HOOG)
• CVE 2024-21262: Score 8.6 (HOOG)
• CVE 2022-0492: Score 7.8 (HOOG)
• CVE-2021-25741: Score: 8.1 (HOOG) / 8,8 (HOOG)
• CVE-2017-1002101: Score: 9.6 (KRITIEK) / 8,8(HOOG)

Lees dit blogbericht voor meer informatie over user-namespaces.

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.

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 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 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.

Veilig computergebruik (seccomp)

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 containerd runtime die wordt gebruikt door AKS-knooppunten. Met seccomp kunt u de systeemaanroepen van een container beperken. Seccomp brengt een extra beveiligingslaag tot stand tegen veelvoorkomende beveiligingsproblemen van systeemaanroepen die worden misbruikt door kwaadwillende actoren en stelt u in staat om een standaardprofiel op te geven voor alle workloads in het knooppunt.

Een standaardprofiel voor seccomp configureren (preview)

U kunt standaardprofielen voor seccomp toepassen met behulp van aangepaste knooppuntconfiguraties bij het maken van een nieuwe Linux-knooppuntgroep. Er worden twee waarden ondersteund op AKS: RuntimeDefault en Unconfined. Voor sommige workloads is mogelijk een lager aantal syscall-beperkingen vereist dan andere. Dit betekent dat ze kunnen mislukken tijdens uitvoeringstijd met het profiel 'RuntimeDefault'. Als u een dergelijke fout wilt verhelpen, kunt u het Unconfined profiel opgeven. Als uw workload een aangepast profiel vereist, raadpleeg dan Een aangepast seccomp-profiel configureren.

Beperkingen

• SeccompDefault is geen ondersteunde parameter voor Windows-knooppuntgroepen.
• SeccompDefault is beschikbaar vanaf 2024-09-02-preview-API.

KubeletDefaultSeccompProfilePreview De functievlag registreren

1. Registreer de KubeletDefaultSeccompProfilePreview functievlag met behulp van de az feature register opdracht.

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

   Het duurt enkele minuten voordat de status Geregistreerd wordt weergegeven.

2. Controleer de registratiestatus met behulp van de az feature show opdracht.

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

3. Wanneer de status Geregistreerd weergeeft, vernieuwt u de registratie van de Microsoft.ContainerService-resourceprovider met behulp van de az provider register-opdracht.

   az provider register --namespace Microsoft.ContainerService
   

Systeemaanroepen van uw container beperken met seccomp

1. Volg de stappen om een seccomp-profiel toe te passen in uw kubelet-configuratie door op te "seccompDefault": "RuntimeDefault"geven.

RuntimeDefault maakt gebruik van het standaard seccomp-profiel van containerd, waardoor bepaalde systeemaanroepen worden beperkt om de beveiliging te verbeteren. Beperkte systeemoproepen zullen mislukken. Zie het standaard seccomp-profiel voor containerD voor meer informatie.

2. Controleer of de configuratie is toegepast.

U kunt controleren of de instellingen worden toegepast op de knooppunten door verbinding te maken met de host en te controleren of er configuratiewijzigingen zijn aangebracht in het bestandssysteem.

3. Problemen met workload oplossen.

Wanneer SeccompDefault is ingeschakeld, wordt het standaard seccomp-profiel van de containerruntime standaard gebruikt voor alle workloads die op het knooppunt zijn gepland. Dit kan ertoe leiden dat werkbelastingen mislukken vanwege geblokkeerde syscalls. Als er een workloadfout is opgetreden, ziet u mogelijk fouten zoals:

• De workload treedt onverwacht op nadat de functie is ingeschakeld en geeft de fout 'machtiging geweigerd'.
• Seccomp-foutberichten kunnen ook worden weergegeven in gecontroleerd of syslog door SCMP_ACT_ERRNO te vervangen door SCMP_ACT_LOG in het standaardprofiel.

Als u de bovenstaande fouten ondervindt, wordt u aangeraden uw seccomp-profiel te wijzigen in Unconfined. Unconfined plaatst geen beperkingen op syscalls, waardoor alle systeemoproepen worden toegestaan, waardoor de beveiliging wordt verminderd.

Een aangepast seccomp-profiel configureren

Met een aangepast seccomp-profiel kunt u meer gedetailleerde controle hebben over beperkte syscalls. 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 met het seccomp-filter, zoals wordt weergegeven in de voorbeelduitvoer:

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

Zie het artikel Problemen met de configuratie van seccomp-profielen in Azure Kubernetes Service oplossen voor hulp bij het oplossen van problemen met uw seccomp-profiel.

Beveiligingsprofielopties voor seccomp

Seccomp-beveiligingsprofielen zijn een set gedefinieerde syscalls die zijn toegestaan of beperkt. De meeste containerruntimes hebben een standaard seccomp-profiel dat vergelijkbaar is als niet hetzelfde als het profiel dat door Docker wordt gebruikt. Zie Docker - of containerD-standaard seccomp-profielen voor meer informatie over beschikbare profielen.

AKS gebruikt het standaard seccomp-profiel voor containerD voor onze RuntimeDefault wanneer u seccomp configureert met behulp van aangepaste knooppuntconfiguratie.

Belangrijke syscalls geblokkeerd in het standaardprofiel

Zowel Docker als containerD onderhouden acceptatielijsten van veilige syscalls. Deze tabel bevat de significante (maar niet alle) syscalls die effectief worden geblokkeerd omdat ze niet op de acceptatielijst staan. Als een van de geblokkeerde syscalls vereist is voor uw workload, gebruik dan het RuntimeDefault seccomp-profiel niet.

Wanneer er wijzigingen worden aangebracht in Docker en containerD, werkt AKS de standaardconfiguratie bij zodat deze overeenkomt. Bijwerken van deze lijst kan leiden tot een storing in de werklast. Raadpleeg de AKS-releasenotities voor release-updates.

Volgende stappen

Zie Best practices voor clusterbeveiliging en -upgrades in AKS en aanbevolen procedures voor podbeveiliging in AKS voor gekoppelde aanbevolen procedures.