Sicherer Containerzugriff auf Ressourcen für Azure Kubernetes Service (AKS)-Workloads mit integrierten Linux-Sicherheitsfeatures

Voraussetzungen für Benutzernamespaces

• Ein bestehender AKS-Cluster. Wenn Sie keinen Cluster haben, erstellen Sie einen mithilfe der Azure CLI, der Azure PowerShell oder im Azure-Portal.
• Mindestens Kubernetes Version 1.33 für die Steuerungsebene und die Worker-Knoten. Wenn Sie Kubernetes, Version 1.33 oder höher, nicht verwenden, müssen Sie ihre Kubernetes-Version aktualisieren.
• Worker Knoten, die Azure Linux 3.0 oder Ubuntu 24.04 ausführen, um sicherzustellen, dass Sie die minimalen Stack-Anforderungen für die Aktivierung von Benutzer-Namespaces erfüllen. Wenn Sie ein Upgrade Ihrer Betriebssystemversion (Os) durchführen müssen, lesen Sie das Upgrade Ihrer Betriebssystemversion.

Einschränkungen für Benutzernamespaces

• Das Feature für Benutzernamespaces ist für den Linux-Kernel vorgesehen und wird für Windows-Knotenpools nicht unterstützt.
• Prüfen Sie die Kubernetes-Dokumentation für Benutzer-Namespaces auf weitere Limits.

Übersicht über Benutzernamespaces

Linux-Pods werden standardmäßig mit mehreren Namespaces ausgeführt: einem Netzwerk-Namespaces, um die Netzwerkidentität zu isolieren, und einem PID-Namespace, um die Prozesse zu isolieren. Ein Benutzernamespace (user_namespace) isoliert die Benutzer innerhalb des Containers von den Benutzern auf dem Host. Außerdem werden der Umfang der Funktionen und die Interaktionen des Pods mit dem rest des Systems begrenzt.

Die UIDs und GIDs im Container werden unprivilegierten Benutzern auf dem Host zugeordnet, sodass alle Interaktionen mit dem Rest des Hosts als diese unprivilegierten UIDs und GIDs erfolgen. Beispielsweise kann der Root-Benutzer innerhalb des Containers (UID 0) dem Benutzer 65536 auf dem Host zugeordnet werden. Kubernetes erstellt die Zuordnung, um sicherzustellen, dass sie sich nicht mit anderen Pods überschneidet, die Benutzernamespaces auf dem System verwenden.

Die Kubernetes-Implementierung hat einige wichtige Vorteile. Weitere Informationen finden Sie in der Dokumentation zu Kubernetes-Benutzernamespaces.

Aktivieren von Benutzernamespaces

1. Erstellen Sie eine Datei namens mypod.yaml, und fügen Sie das folgende Manifest ein. Um Benutzernamespaces zu verwenden, muss das YAML über das Feld hostUsers: falseverfügen.

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

2. Stellen Sie die Anwendung über den Befehl „kubectl apply“ bereit, und geben Sie den Namen Ihres YAML-Manifests an.

   kubectl apply -f mypod.yaml
   

3. Überprüfen Sie den Status der bereitgestellten Pods mithilfe des Befehls kubectl get pods.

   kubectl get pods
   

4. Rufen Sie den Pod mit dem kubectl exec-Befehl auf.

   kubectl exec -ti userns -- bash
   

5. Innerhalb des Pods überprüfen Sie /proc/self/uid_map mit dem folgenden Befehl:

   cat /proc/self/uid_map
   

   Die Ausgabe sollte 65536 in der letzten Spalte aufweisen. Beispiel:

   0  833617920      65536
   

   Diese Ausgabe gibt an, dass der Stamm innerhalb des Containers (UID 0) dem Benutzer 65536 auf dem Host zugeordnet ist.

Allgemeine Sicherheitsrisiken und Risiken (CVEs), die durch Benutzernamespaces abgemildert werden

In der folgenden Tabelle sind einige allgemeine Sicherheitsrisiken und Expositionen (CVEs) aufgeführt, die entweder teilweise oder vollständig durch verwendung von user_namespaces abgemildert werden:

Beachten Sie, dass diese Liste nicht vollständig ist. Weitere Informationen finden Sie unter Kubernetes v1.33: Standardmäßig aktivierte Benutzernamespaces.

Voraussetzungen für AppArmor

• Ein bestehender AKS-Cluster. Wenn Sie keinen Cluster haben, erstellen Sie einen mithilfe der Azure CLI, der Azure PowerShell oder im Azure-Portal.

Übersicht über AppArmor

Mit dem Kernelsicherheitsmodul AppArmor von Linux können Sie Containeraktionen einschränken. AppArmor ist als Teil des zugrunde liegenden AKS-Knotenbetriebssystems (OS) verfügbar und ist standardmäßig aktiviert. Sie können AppArmor-Profile erstellen, die Lese-, Schreib- oder Ausführungsaktionen oder Systemfunktionen wie das Einbinden von Dateisystemen einschränken. Standardprofile von AppArmor beschränken den Zugriff auf verschiedene /proc- und /sys-Speicherorte und ermöglichen es, Container logisch vom zugrunde liegenden Knoten zu isolieren. AppArmor funktioniert nicht nur mit Kubernetes-Pods, sondern zusammen mit jeder Anwendung, die auf Linux ausgeführt werden kann.

Sichere Pods mit AppArmor

Sie können AppArmor-Profile auf der Pod- oder Containerebene angeben. Das Container-AppArmor-Profil hat Vorrang vor dem Pod AppArmor-Profil. Wenn keine der beiden Angaben gemacht wird, wird der Container ohne Einschränkungen ausgeführt. Weitere Informationen zu AppArmor-Profilen finden Sie in der Dokumentation zum Sichern eines Pods mit AppArmor Kubernetes.

Konfigurieren eines benutzerdefinierten AppArmor-Profils

Im folgenden Beispiel wird ein Profil erstellt, das das Schreiben in Dateien in einem Container verhindert.

1. Stellen Sie eine SSH-Verbindung mit einem AKS-Knoten her.

2. Erstellen Sie eine Datei mit dem Namen "deny-write.profile ", und fügen Sie den folgenden Inhalt ein:

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

3. Laden Sie das AppArmor-Profil auf den Knoten.

   # This example assumes that node names match host names, and are reachable via SSH.
   NODES=($( kubectl get node -o jsonpath='{.items[*].status.addresses[?(.type == "Hostname")].address}' ))
   
   for NODE in ${NODES[*]}; do ssh $NODE 'sudo apparmor_parser -q <<EOF
   #include <tunables/global>
   
   profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
     #include <abstractions/base>
   
     file,
   
     # Deny all file writes.
     deny /** w,
   }
   EOF'
   done
   

Bereitstellen eines Pods mit dem benutzerdefinierten AppArmor-Profil

1. Stellen Sie einen "Hello AppArmor" -Pod mit dem Deny-Write-Profil bereit.

   apiVersion: v1
   kind: Pod
   metadata:
     name: hello-apparmor
   spec:
     securityContext:
       appArmorProfile:
         type: Localhost
         localhostProfile: k8s-apparmor-example-deny-write
     containers:
     - name: hello
       image: busybox:1.28
       command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
   

2. Wenden Sie das Pod-Manifest mithilfe des kubectl apply Befehls an.

   kubectl apply -f hello-apparmor.yaml
   

3. Führen Sie den Befehl in dem Pod aus und verifizieren Sie, dass der Container mit dem AppArmor-Profil ausgeführt wird.

   kubectl exec hello-apparmor -- cat /proc/1/attr/current
   

   Die Ausgabe sollte das verwendete AppArmor-Profil anzeigen. Beispiel:

   k8s-apparmor-example-deny-write (enforce)
   

Voraussetzungen für Seccomp

• Ein bestehender AKS-Cluster. Wenn Sie keinen Cluster haben, erstellen Sie einen mithilfe der Azure CLI, der Azure PowerShell oder im Azure-Portal.
• Sie müssen das KubeletDefaultSeccompProfilePreview Feature-Flag registrieren, um Standard-seccomp-Profile in Ihren Knotenpools zu verwenden.

Registrieren des KubeletDefaultSeccompProfilePreview-Featureflags

1. Registrieren Sie das Featureflag KubeletDefaultSeccompProfilePreview mithilfe des Befehls az feature register.

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

   Es dauert einige Minuten, bis als Status Registriert angezeigt wird.

2. Überprüfen Sie den Registrierungsstatus mithilfe des Befehls az feature show.

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

3. Wenn der Status Registriert lautet, aktualisieren Sie die Registrierung des Ressourcenanbieters Microsoft.ContainerService mithilfe des Befehls az provider register.

   az provider register --namespace Microsoft.ContainerService
   

Seccomp-Einschränkungen

• AKS unterstützt nur die Standard seccomp Profile (RuntimeDefault und Unconfined). Benutzerdefinierte Seccomp-Profile werden nicht unterstützt.
• SeccompDefault ist kein unterstützter Parameter für Windows-Knotenpools.

Übersicht über Standard-Seccomp-Profile (Vorschau)

Während AppArmor für jede Linux-Anwendung funktioniert, funktioniert Seccomp (oder secure Computing) auf Prozessebene. Seccomp ist auch ein Linux-Kernel-Sicherheitsmodul. Die von AKS-Knoten verwendete containerd Laufzeitumgebung bietet native Unterstützung für seccomp. Mit seccomp können Sie die Systemaufrufe eines Containers einschränken. seccomp stellt eine zusätzliche Schutzebene vor gängigen Systemanrufrisiken her, die von böswilligen Akteuren ausgenutzt werden, und ermöglicht es Ihnen, ein Standardprofil für alle Workloads im Knoten anzugeben.

Sie können standardmäßige seccomp-Profile mit benutzerdefinierten Knotenkonfigurationen anwenden, wenn Sie einen neuen Linux-Knotenpool erstellen. AKS unterstützt die RuntimeDefault- und Unconfined-Werte. Einige Workloads erfordern möglicherweise eine geringere Anzahl von Syscall-Einschränkungen als andere. Das bedeutet, dass sie während der Laufzeit mit dem Profil RuntimeDefault fehlschlagen können. Um einen solchen Fehler zu vermeiden, können Sie das Unconfined-Profil angeben. Wenn Ihre Workload ein benutzerdefiniertes Profil erfordert, lesen Sie Konfigurieren eines benutzerdefinierten seccomp-Profils.

Einschränken von Containersystemaufrufen mit Seccomp

1. Führen Sie die Schritte aus, um ein Seccomp-Profil in Ihrer Kubelet-Konfiguration anzuwenden , indem Sie angeben "seccompDefault": "RuntimeDefault".
2. Stellen Sie eine Verbindung mit dem Host her.
3. Überprüfen Sie, ob die Konfiguration auf die Knoten angewendet wurde.

Beheben von Workloadfehlern mit Seccomp

Wenn SeccompDefault aktiviert ist, wird das standardmäßige Seccomp-Profil der Containerlaufzeit standardmäßig für alle Workloads verwendet, die auf dem Knoten angesetzt sind. Dies kann dazu führen, dass Workloads aufgrund blockierter Syscalls fehlschlagen. Wenn ein Fehler bei der Arbeitslast auftritt, könnten Fehlermeldungen erscheinen, z. B.:

• Der Workload wird unerwartet beendet, nachdem die Funktion aktiviert wurde, mit der Fehlermeldung „Berechtigung verweigert“.
• Seccomp-Fehlermeldungen können auch in Überwachung oder Syslog angezeigt werden, indem SCMP_ACT_ERRNO durch SCMP_ACT_LOG im Standardprofil ersetzt wird.

Wenn diese Fehler auftreten, empfehlen wir Ihnen, Ihr seccomp-Profil in Unconfined zu ändern. Unconfined legt keine Einschränkungen für Syscalls fest, sodass alle Systemaufrufe ausgeführt werden können.

Übersicht über benutzerdefinierte Seccomp-Profile

Mit einem benutzerdefinierten Seccomp-Profil haben Sie eine genauere Kontrolle über eingeschränkte Syscalls für Ihre Container. Sie können eigene Seccomp-Profile erstellen, indem Sie:

• Verwenden von Filtern, um anzugeben, welche Aktionen zulässig oder verweigert werden sollen.
• Verwenden Sie Anmerkungen innerhalb eines YAML-Podmanifests für die Zuordnung zum entsprechenden seccomp-Filter.

Konfigurieren eines benutzerdefinierten seccomp-Profils

In der folgenden Beispielverwendung von Seccomp erstellen Sie einen Filter, der verhindert, dass Berechtigungen für eine Datei geändert werden können.

1. Stellen Sie eine SSH-Verbindung mit einem AKS-Knoten her.

2. Erstellen Sie einen seccomp-Filter mit dem Namen /var/lib/kubelet/seccomp/prevent-chmod.

3. Kopieren Sie den folgenden Inhalt, und fügen Sie ihn ein:

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

   Ab Version 1.19 muss Folgendes konfiguriert werden:

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

4. Erstellen Sie auf Ihrem lokalen Computer ein Podmanifest namens aks-seccomp.yaml, und fügen Sie den folgenden Inhalt ein. Dieses Manifest definiert eine Anmerkung für seccomp.security.alpha.kubernetes.io und verweist auf den vorhandenen Prevent-chmod-Filter .

   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
   

   Ab Version 1.19 muss Folgendes konfiguriert werden:

   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. Stellen Sie den Beispiel-Pod mithilfe des kubectl apply Befehls bereit:

   kubectl apply -f ./aks-seccomp.yaml
   

6. Zeigen Sie den Podstatus mithilfe des kubectl get pods Befehls an.

   kubectl get pods
   

   In der Ausgabe sollten Sie sehen, dass der Pod einen Fehler liefert. Wie in der Beispielausgabe ersichtlich wird, wird das Ausführen des chmod-Befehls vom seccomp-Filter verhindert:

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