seccomp in GKE

Autopilot Standard

Diese Seite enthält Informationen zum Linux-Modus für sicheres Computing (seccomp) in Google Kubernetes Engine (GKE). Anhand dieser Informationen können Sie ermitteln, welche Aktionen Ihre Containeranwendungen auf der Host-VM ausführen können, die Ihre Knoten unterstützt.

Was ist seccomp?

Der Modus für sicheres Computing (seccomp) ist eine Sicherheitsfunktion in Linux, mit der Sie die Systemaufrufe (Syscalls) einschränken können, die ein Prozess auf dem Linux-Kernel ausführen kann.

Standardmäßig verwenden GKE-Knoten das Container-Optimized OS-Betriebssystem mit der Containerd-Containerlaufzeit. Containerd schützt den Linux-Kernel durch die Einschränkung der zulässigen Linux-Funktionen auf eine Standardliste. Die zulässigen Systemaufrufe können mit einem seccomp-Profil weiter eingeschränkt werden. Containerd stellt ein Standard-seccomp-Profil zur Verfügung. Ob GKE das Standard-seccomp-Profil für Sie anwendet, hängt vom verwendeten Clustermodus ab:

Autopilot (empfohlen): GKE wendet das Containerd-Standard-seccomp-Profil automatisch auf alle Arbeitslasten an.
Standard: GKE wendet das Containerd-Standard-seccomp-Profil nicht automatisch auf alle Arbeitslasten an. Wir empfehlen, entweder das seccomp-Standardprofil oder ein benutzerdefiniertes seccomp-Profil auf Ihre Arbeitslasten anzuwenden.

Das containerd-seccomp-Standardprofil bietet eine grundlegende Härtung, während die Kompatibilität mit den meisten Arbeitslasten aufrechterhalten wird. Die vollständige seccomp-Profildefinition für containerd ist auf GitHub verfügbar.

Linux-Funktionen und Syscalls

Für Nicht-Root-Prozesse, die auf Linux-Systemen ausgeführt werden, sind möglicherweise bestimmte Berechtigungen erforderlich, um Aktionen als Root-Nutzer auszuführen. Linux verwendet Funktionen, um die verfügbaren Berechtigungen in Gruppen zu unterteilen, sodass ein Nicht-Root-Prozess eine bestimmte Aktion ausführen kann, ohne alle Berechtigungen zu erhalten. Damit ein Prozess einen bestimmten Syscall erfolgreich durchführen kann, muss er die entsprechenden Berechtigungen haben, die von einer Funktion gewährt werden.

Eine Liste aller Linux-Funktionen finden Sie unter Funktionen.

Abgelehnte Syscalls im GKE-seccomp-Standardprofil

Das containerd-seccomp-Standardprofil blockiert alle Syscalls und lässt dann selektiv bestimmte Syscalls zu, von denen einige von der CPU-Architektur der VM des Knotens und der Kernel-Version abhängen. Die Variable syscalls in der Funktion DefaultProfile listet die zulässigen Syscalls für alle Architekturen auf.

Das seccomp-Standardprofil blockiert Syscalls, mit denen Containerisolationsgrenzen umgangen werden können und privilegierter Zugriff auf den Knoten oder auf andere Container möglich ist. In der folgenden Tabelle werden einige der wichtigsten Syscalls beschrieben, die vom Standard-Seccomp-Profil abgelehnt werden:

Abgelehnte Syscalls
`mount`, `umount`, `umount2`, `fsmount`, `mount_setattr`	Verhindern, dass Prozesse auf das Knotendateisystem außerhalb der Containergrenzen zugreifen oder es bearbeiten. Wird auch abgelehnt, da die Funktion `CAP_SYS_ADMIN` verworfen wird.
`bpf`	Verhindern, dass Prozesse eBPF-Programme im Kernel erstellen, was zu einer Rechteausweitung auf dem Knoten führen kann. In CVE-2021-3490 wurde beispielsweise der Syscall `bpf` verwendet. Wird auch abgelehnt, da die Funktion `CAP_SYS_ADMIN` verworfen wird.
`clone`, `clone3`, `unshare`	Verhindern, dass Prozesse neue Prozesse in neuen Namespaces erstellen, die sich außerhalb des eingeschränkten Namespace des Containers befinden können. Diese neuen Prozesse haben möglicherweise erhöhte Berechtigungen und Funktionen. In CVE-2022-0185 wurde beispielsweise der Syscall `unshare` verwendet. Wird auch abgelehnt, da die Funktion `CAP_SYS_ADMIN` verworfen wird.
`reboot`	Verhindern, dass Prozesse den Knoten neu starten. Wird auch abgelehnt, da die Funktion `CAP_SYS_BOOT` verworfen wird.
`open_by_handle_at`, `name_to_handle_at`	Zugriff auf Dateien außerhalb des Containers einschränken. Diese Syscalls wurden in einem der ersten Docker-Container-Escape-Exploits verwendet. Wird auch abgelehnt, da die `CAP_DAC_READ_SEARCH`-Funktion und die `CAP_SYS_ADMIN`-Funktion verworfen werden.

seccomp in GKE verwenden

In Autopilot-Clustern wendet GKE das containerd-seccomp-Standardprofil automatisch auf alle Arbeitslasten an. Es sind keine weiteren Maßnahmen erforderlich. Versuche, eingeschränkte Syscalls auszuführen, schlagen fehl. Autopilot lässt keine benutzerdefinierten seccomp-Profile zu, da GKE die Knoten verwaltet.

In Standard-Clustern müssen Sie manuell ein seccomp-Profil anwenden. GKE wendet kein Profil für Sie an.

seccomp in Standard-Clustern aktivieren

Wenden Sie ein seccomp-Profil manuell an. Legen Sie dazu den Pod- oder Container-Sicherheitskontext mithilfe des Felds spec.securityContext.seccompProfile in der Pod-Spezifikation fest, wie im folgenden Beispiel gezeigt. Es wird dringend empfohlen, für Ihre Arbeitslasten ein seccomp-Profil zu verwenden, es sei denn, für Ihren Anwendungsfall sind eingeschränkte Syscalls erforderlich. Die folgenden zwei seccompProfile-Typen werden unterstützt:

RuntimeDefault: das Standardprofil, das von der containerd-Laufzeit angegeben wird.
Localhost: eine benutzerdefinierte Profildefinition.

Im folgenden Beispielmanifest wird das seccomp-Profil auf das Laufzeitstandardprofil festgelegt:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    app: default-pod
spec:
  replicas: 3
  selector:
    matchLabels:
      app: default-pod
  template:
    metadata:
      labels:
        app: default-pod
    spec:
      securityContext:
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: seccomp-test
        image: nginx

Wenn bei der Bereitstellung dieses Manifests ein Container im Pod versucht, einen Syscall auszuführen, der gegen das Laufzeit-seccomp-Profil verstößt, kann beim Pod oder bei der Arbeitslast ein unerwartetes Verhalten auftreten. Beispielsweise kann ein Pod, der beim Start einen eingeschränkten Syscall durchführt, nicht gestartet werden. Wenn eine Anwendung versucht, einen eingeschränkten Syscall durchzuführen, während der Pod ausgeführt wird, treten möglicherweise Fehler im Container auf. Der Schweregrad eines fehlgeschlagenen Syscalls hängt davon ab, wie die Anwendung mit Fehlern umgeht.

Benutzerdefiniertes seccomp-Profil in Standard-Clustern verwenden

Wenn das seccomp-Standardprofil der Laufzeit für Ihre Anwendung zu restriktiv (oder nicht restriktiv genug) ist, können Sie ein benutzerdefiniertes seccomp-Profil auf Pods in Standard-Clustern anwenden. Dieser Prozess erfordert Zugriff auf das Dateisystem auf dem Knoten. Eine Anleitung zum Laden und Verwenden benutzerdefinierter seccomp-Profile finden Sie unter Syscalls eines Containers mit seccomp einschränken.