Sicherheitscontainerzugriff auf Ressourcen mithilfe integrierter Linux-Sicherheitsfeatures

In diesem Artikel erfahren Sie, wie Sie den Containerzugriff auf Ressourcen für Ihre Azure Kubernetes Service (AKS)-Workloads sichern.

Übersicht

Nicht nur Benutzern und Gruppen sollten lediglich die erforderlichen Mindestberechtigungen gewährt werden, auch Container sollten auf die Aktionen und Prozesse beschränkt werden, die unbedingt erforderlich sind. Konfigurieren Sie zur Minimierung des Angriffsrisikos nach Möglichkeit keine Anwendungen und Container, die ausgeweitete Berechtigungen oder Root-Zugriff benötigen.

Sie können integrierte Pod-Sicherheitskontexte in Kubernetes verwenden, um weitere Berechtigungen zu definieren, z. B. den Benutzer oder die Gruppe, die ausgeführt werden soll, die Linux-Funktionen, die verfügbar gemacht werden sollen, oder das Festlegen von allowPrivilegeEscalation: false im Pod-Manifest. Weitere Best Practices finden Sie unter Absichern des Podzugriffs auf Ressourcen.

Um die Hostisolation zu verbessern und die Lateralbewegung unter Linux zu verringern, können Sie Benutzernamespaces verwenden.

Wenn Sie die Steuerungsmöglichkeiten für Containeraktionen noch feiner abstimmen möchten, können Sie dazu integrierte Linux-Sicherheitsfeatures wie AppArmor und seccomp verwenden.

1. Definieren Sie Linux-Sicherheitsfeatures auf Knotenebene.
2. Implementieren Sie Features über ein Podmanifest.

In Linux integrierte Sicherheitsfunktionen sind nur auf Linux-Knoten und -Pods verfügbar.

Benutzer-Namensräume

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

• Erhöhte Hostisolation: Wenn ein Container den Pod-Begrenzungen entgeht, selbst wenn er als Root-Benutzer innerhalb des Containers ausgeführt wird, hat er keine Berechtigungen auf dem Host. Der Grund dafür ist, dass die UIDs und GIDs des Containers nicht privilegierten Benutzern auf dem Host zugeordnet sind. ** Wenn ein Container-Escape auftritt, bieten Benutzernamespaces einen starken Schutz dafür, auf welche Dateien auf dem Host ein Container zugreifen (lesen/schreiben) kann und an welche Prozesse er Signale senden kann. Die gewährten Funktionen sind nur innerhalb des Benutzernamespaces und nicht auf dem Host gültig.

• Verhinderung von Lateral Movement: Da die UIDs und GIDs für verschiedene Container unterschiedlichen, nicht überlappenden UIDs und GIDs auf dem Host zugeordnet sind, ist es für Container schwieriger, gegenseitig anzugreifen. Angenommen, Container A wird mit unterschiedlichen UIDs und GIDs auf dem Host als Container B ausgeführt. Bei einem Container-Breakout sind die Vorgänge, die sie für Container-B-Dateien und -Prozesse ausführen kann, beschränkt: nur Lese-/Schreibzugriff, was eine Datei anderen zulässt. Aber nicht einmal das ist möglich, da es eine zusätzliche Verhinderung im übergeordneten Verzeichnis des Pod-Stammvolumes gibt, um sicherzustellen, dass nur die Pod-GID darauf zugreifen kann.

• Prinzip des geringsten Privilegs: Da die UIDs und GIDs nicht privilegierten Benutzern auf dem Host zugeordnet sind, erhalten nur diejenigen Benutzer, die die Berechtigungen auf dem Host benötigen und die Benutzernamespaces deaktivieren, diese. Ohne Benutzernamespaces gibt es keine Trennung zwischen den Benutzern des Containers und den Hostbenutzern. Wir können nicht vermeiden, dem Host Berechtigungen für Prozesse zu erteilen, die sie nicht benötigen, wenn sie nur innerhalb des Containers Berechtigungen benötigen.

• Aktivierung neuer Anwendungsfälle: Mithilfe von Benutzernamespaces können Container bestimmte Funktionen innerhalb ihres eigenen Benutzernamespaces erhalten, ohne dass sich dies auf den Host auswirkt. Die dem Pod zugewiesenen, eingeschränkten Berechtigungen eröffnen neue Möglichkeiten, wie das Ausführen von Anwendungen, die privilegierte Vorgänge erfordern, ohne vollen Root-Zugriff auf dem Host zu gewähren. Häufige neue Anwendungsfälle, die sicher implementiert werden können, sind: Ausführen geschachtelter Container und unprivilegiertes Container-Build.

• Nicht privilegiertes Container-Setup: Der Großteil der Containererstellung und -einrichtung wird nicht als Root auf dem Hostsystem ausgeführt, wodurch die Auswirkungen vieler CVEs erheblich eingeschränkt werden.

Keine dieser Punkte gilt, wenn Benutzernamespaces nicht verwendet werden. Wenn der Container als Stamm ausgeführt wird, wenn Benutzernamespaces nicht verwendet werden, wird der Prozess als Stamm auf dem Host ausgeführt, die Funktionen sind auf dem Host gültig, und das Containersetup erfolgt als Stamm auf dem Host.

Bevor Sie anfangen

Bevor Sie beginnen, sollten Sie sicherstellen, dass Folgendes vorhanden ist:

• Ein bestehender AKS-Cluster. Wenn Sie keinen Cluster haben, erstellen Sie einen mithilfe der Azure CLI, der Azure PowerShell oder im Azure-Portal.
• Mindestversion von Kubernetes 1.33 für die Kontrollebene und die Arbeitsknoten. Wenn Sie kubernetes Version 1.33 oder höher nicht verwenden, müssen Sie ihre Kubernetes-Version aktualisieren.
• Arbeitsknoten mit Azure Linux 3.0 oder Ubuntu 24.04. Wenn Sie diese Betriebssystemversionen nicht verwenden, verfügen Sie nicht über die Mindeststapelanforderungen , um Benutzernamespaces zu aktivieren. Sie müssen Ihre Betriebssystemversion aktualisieren.

Einschränkungen

• Benutzernamespaces sind ein Linux-Kernelfeature und werden für Windows-Knotenpools nicht unterstützt.
• Zögern Sie nicht, die Kubernetes-Dokumentation für Benutzernamespaces zu überprüfen, insbesondere den Abschnitt "Einschränkungen".

Aktivieren von Benutzernamespaces

Es sind keine Konfigurationen erforderlich, um dieses Feature zu verwenden. Wenn Sie die erforderliche AKS-Version verwenden, funktioniert alles sofort.

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. Führen Sie in einem Pod, aus um /proc/self/uid_map mit dem kubectl exec-Befehl zu überprüfen:

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

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

0  833617920      65536

CVEs entschärft

Hier sind einige CVEs, die vollständig/teilweise mit Benutzernamespaces abgemildert werden.

Beachten Sie, dass die Liste nicht erschöpfend ist; es handelt sich lediglich um eine Auswahl von CVEs mit hoher Punktzahl, die entschärft werden.

• CVE-2019-5736 – Bewertung 8,6 (HOCH)
• CVE 2024-21262: Bewertung 8,6 (HOCH)
• CVE 2022-0492: Bewertung 7,8 (HOCH)
• CVE-2021-25741: Bewertung: 8,1 (HOCH) / 8,8 (HOCH)
• CVE-2017-1002101: Bewertung: 9,6 (KRITISCH) / 8,8 (HOCH)

Weitere Informationen finden Sie in diesem Blogbeitrag mit zusätzlichen Informationen zu Benutzernamespaces.

AppArmor

Mit dem Kernelsicherheitsmodul AppArmor von Linux können Sie Containeraktionen einschränken. AppArmor ist als Teil des zugrunde liegenden AKS Knotens des Betriebssystems verfügbar und standardmäßig aktiviert. Sie erstellen AppArmor-Profile, die Aktionen wie „Lesen“, „Schreiben“ oder „Ausführen“ oder Systemfunktionen wie das Einbinden von Dateisystemen beschrä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.

In der folgenden Beispielverwendung von AppArmor wird ein Profil erstellt, das den Schreibzugriff auf Dateien verhindert.

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

2. Erstellen Sie eine Datei mit dem Namen deny-write.profile.

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

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

AppArmor-Profile werden mithilfe des apparmor_parser-Befehls hinzugefügt.

1. Fügen Sie das Profil zu AppArmor hinzu.

2. Geben Sie den Namen des im vorherigen Schritt erstellten Profils an:

   sudo apparmor_parser deny-write.profile
   

   Wenn das Profil ordnungsgemäß analysiert und auf AppArmor angewendet wurde, wird keine Ausgabe angezeigt, und Sie befinden sich wieder an der Eingabeaufforderung.

3. Erstellen Sie auf Ihrem lokalen Computer ein Podmanifest namens aks-apparmor.yaml. Für dieses Manifest gilt Folgendes:

   • Es definiert eine Anmerkung für container.apparmor.security.beta.kubernetes.
   • Es verweist auf das Profil deny-write, das in den vorherigen Schritten erstellt wurde.

   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. Führen Sie nach der Podbereitstellung den folgenden Befehl aus, und überprüfen Sie, ob der Pod hello-apparmor den Status Wird ausgeführt anzeigt:

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

Weitere Informationen zu AppArmor finden Sie im Kubernetes-Artikel AppArmor.

Sicheres Computing (seccomp)

AppArmor ist für jede Linux-Anwendung geeignet. Seccomp (Secure Computing, sicheres Computing) arbeitet dagegen auf Prozessebene. seccomp ist ebenfalls ein Kernelsicherheitsmodul von Linux und wird nativ von der containerd-Runtime unterstützt, die für AKS-Knoten verwendet wird. 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.

Konfigurieren eines standardmäßigen seccomp-Profils (Vorschau)

Sie können standardmäßige seccomp-Profile mit benutzerdefinierten Knotenkonfigurationen anwenden, wenn Sie einen neuen Linux-Knotenpool erstellen. Für AKS werden zwei Werte unterstützt: RuntimeDefault und Unconfined. Einige Workloads erfordern möglicherweise eine geringere Anzahl von Syscall-Einschränkungen als andere. Dies 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änkungen

• SeccompDefault ist kein unterstützter Parameter für Windows-Knotenpools.
• SeccompDefault ist ab 2024-09-02-Preview-API verfügbar.

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
   

Einschränken der Systemaufrufe Ihres Containers mit seccomp

1. Führen Sie die Schritte aus, um ein seccomp-Profil in Ihrer Kubelet-Konfiguration anzuwenden, indem Sie "seccompDefault": "RuntimeDefault" angeben.

RuntimeDefault verwendet das seccomp-Standardprofil von containerD und schränkt bestimmte Systemaufrufe ein, um die Sicherheit zu verbessern. Eingeschränkte Syscalls führen zu Fehlern. Weitere Informationen finden Sie im containerD-Standardprofil für seccomp.

2. Überprüfen Sie, ob die Konfiguration angewendet wurde.

Sie können bestätigen, dass die Einstellungen auf die Knoten angewendet werden, indem Sie eine Verbindung mit dem Host herstellen und überprüfen, ob Konfigurationsänderungen im Dateisystem vorgenommen wurden.

3. Behandeln von Workloadfehlern.

Wenn SeccompDefault aktiviert ist, wird das seccomp-Standardprofil der Containerruntime standardmäßig für alle Workloads verwendet, die auf dem Knoten geplant sind. Dies kann dazu führen, dass Workloads aufgrund blockierter Syscalls fehlschlagen. Wenn ein Workloadfehler aufgetreten ist, werden möglicherweise Fehler angezeigt, wie:

• Die Workload ist unerwartet vorhanden, nachdem das Feature mit dem Fehler „Berechtigung verweigert“ aktiviert wurde.
• Seccomp-Fehlermeldungen können auch in Überwachung oder Syslog angezeigt werden, indem SCMP_ACT_ERRNO durch SCMP_ACT_LOG im Standardprofil ersetzt wird.

Wenn die oben genannten Fehler auftreten, empfehlen wir, Ihr seccomp-Profil in Unconfined zu ändern. Unconfined legt keine Einschränkungen für Syscalls fest, sodass alle Systemaufrufe zugelassen werden, wodurch die Sicherheit reduziert wird.

Konfigurieren eines benutzerdefinierten seccomp-Profils

Mit einem benutzerdefinierten seccomp-Profil können Sie genauere Kontrolle über eingeschränkte Syscalls haben. Es empfiehlt sich, dem Container nur minimale Berechtigungen für die Ausführung zu erteilen. Gehen Sie dazu wie folgt vor:

• Definieren Sie mithilfe von Filtern, welche Aktionen zugelassen oder verweigert werden sollen.
• Verwenden Sie Anmerkungen innerhalb eines YAML-Podmanifests für die Zuordnung zum entsprechenden seccomp-Filter.

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. Für dieses Manifest gilt Folgendes:

   • Es definiert eine Anmerkung für seccomp.security.alpha.kubernetes.io.
   • Es verweist auf den Filter prevent-chmod, der im vorherigen Schritt erstellt wurde.

   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 Beispielpod mithilfe des Befehls kubectl apply bereit:

   kubectl apply -f ./aks-seccomp.yaml
   

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

   • Der Pod gibt eine Fehlermeldung zurück.
   • Wie in der Beispielausgabe ersichtlich wird, wird das Ausführen des chmod-Befehls vom seccomp-Filter verhindert:

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

Hilfe zur Problembehandlung Ihres Seccomp-Profils finden Sie im Artikel "Problembehandlung bei der Konfiguration von Seccomp-Profilen" in Azure Kubernetes Service.

Sicherheitsprofiloptionen für seccomp

seccomp-Sicherheitsprofile sind eine Reihe definierter Syscalls, die zulässig oder eingeschränkt sind. Die meisten Containerruntimes verfügen über ein seccomp-Standardprofil, das ähnlich, wenn nicht sogar gleich ist, wie das von Docker verwendete. Weitere Informationen zu verfügbaren Profilen finden Sie unter Docker- oder containerD-seccomp-Standardprofilen.

AKS verwendet das containerD-seccomp-Standardprofil für unsere RuntimeDefault, wenn Sie seccomp mithilfe der benutzerdefinierten Knotenkonfiguration konfigurieren.

Signifikante Syscalls, die durch das Standardprofil blockiert werden

Sowohl Docker als auch containerD pflegen Ausnahmelisten sicherer Syscalls. In dieser Tabelle sind die signifikanten (aber nicht alle) Syscalls aufgeführt, die effektiv blockiert werden, da sie nicht in der Ausnahmeliste enthalten sind. Wenn einer der blockierten Syscalls von Ihrer Workload benötigt wird, verwenden Sie nicht das seccomp-Profil RuntimeDefault.

Wenn Änderungen an Docker und containerD vorgenommen werden, aktualisiert AKS ihre Standardkonfiguration entsprechend. Aktualisierungen dieser Liste können zu Workloadfehlern führen. Versionsupdates finden Sie in den AKS-Versionshinweisen.

Nächste Schritte

Entsprechende bewährte Methoden finden Sie unter Best Practices für Clustersicherheit und Upgrades in Azure Kubernetes Service (AKS) und Best Practices für Podsicherheit in Azure Kubernetes Service (AKS).