Acerca de seccomp en GKE

Autopilot Estándar

En esta página, se proporciona información sobre el modo de computación segura de Linux (seccomp) en Google Kubernetes Engine (GKE). Usa esta información para comprender qué acciones pueden realizar tus aplicaciones alojadas en contenedores en la máquina virtual (VM) host que respalda tus nodos.

¿Qué es seccomp?

El modo de procesamiento seguro, o seccomp, es una capacidad de seguridad en Linux que te permite restringir las llamadas al sistema (syscalls) que un proceso puede realizar en el kernel de Linux.

De forma predeterminada, los nodos de GKE usan el sistema operativo Container-Optimized OS con el entorno de ejecución del contenedor containerd. containerd protege el kernel de Linux mediante la limitación de las capacidades de Linux permitidas a una lista predeterminada, y puedes limitar aún más las llamadas al sistema permitidas con un perfil de seccomp. containerd tiene disponible un perfil de seccomp predeterminado. Que GKE aplique el perfil de seccomp predeterminado por ti depende del modo de clúster que uses, de la siguiente manera:

Autopilot (recomendado): GKE aplica el perfil de seccomp predeterminado de containerd a todas las cargas de trabajo de forma automática.
Standard: GKE no aplica el perfil seccomp predeterminado de containerd a todas las cargas de trabajo de forma automática. Te recomendamos aplicar el perfil seccomp predeterminado o un perfil de seccomp personalizado a tus cargas de trabajo.

El perfil de seccomp predeterminado de containerd proporciona endurecimiento del modelo de referencia y, al mismo tiempo, mantiene la compatibilidad con la mayoría de las cargas de trabajo. La definición completa del perfil de seccomp para containerd está disponible en GitHub.

Capacidades de Linux y llamadas al sistema

Los procesos no raíz que se ejecutan en sistemas Linux pueden requerir privilegios específicos para realizar acciones como el usuario raíz. Linux usa capacidades para dividir los privilegios disponibles en grupos, de modo que un proceso no raíz pueda realizar una acción específica sin que se le otorguen todos los privilegios. Para que un proceso realice una llamada de sistema específica de forma correcta, el proceso debe tener los privilegios correspondientes otorgados por una función.

Para obtener una lista de todas las capacidades de Linux, consulta capacidades.

Llamadas al sistema denegadas en el perfil predeterminado de GKE seccomp

El perfil seccomp predeterminado de containerd bloquea todas las llamadas al sistema y, luego, permite llamadas al sistema específicas, algunas de las cuales dependen de la arquitectura de CPU de la VM del nodo y la versión del kernel. La variable syscalls en la función DefaultProfile enumera las llamadas al sistema permitidas para todas las arquitecturas.

El perfil predeterminado seccomp bloquea las llamadas al sistema que se pueden usar para omitir los límites de aislamiento del contenedor y permitir el acceso con privilegios al nodo o a otros contenedores. En la siguiente tabla, se describen algunas de las llamadas al sistema significativas que rechaza el perfil de seccomp predeterminado:

Llamadas al sistema denegadas
`mount`, `umount`, `umount2`, `fsmount`, `mount_setattr`	Restringe los procesos para acceder o manipular el sistema de archivos del nodo fuera de los límites del contenedor. También se rechaza porque la función `CAP_SYS_ADMIN` se descarta.
`bpf`	Restringe los procesos de creación de programas de eBPF en el kernel, lo que puede generar elevación de privilegios en el nodo. Por ejemplo, CVE-2021-3490 usó la llamada al sistema `bpf`. También se rechaza porque la función `CAP_SYS_ADMIN` se descarta.
`clone`, `clone3`, `unshare`	Restringe la capacidad de los procesos para crear procesos nuevos en espacios de nombres nuevos que podrían estar fuera del espacio de nombres restringido del contenedor. Estos procesos nuevos pueden tener permisos y capacidades elevados. Por ejemplo, CVE-2022-0185 usó la llamada al sistema `unshare`. También se rechaza porque la función `CAP_SYS_ADMIN` se descarta.
`reboot`	Restringe los procesos para que no se reinicie el nodo. También se rechaza porque la función `CAP_SYS_BOOT` se descarta.
`open_by_handle_at`, `name_to_handle_at`	Restringe el acceso a los archivos fuera del contenedor. Estas llamadas al sistema se usaron en una de las primeras vulnerabilidades de escape de contenedores de Docker. También se rechaza porque la función `CAP_DAC_READ_SEARCH` y la función `CAP_SYS_ADMIN` se descartan.

Cómo usar seccomp en GKE

En los clústeres de Autopilot, GKE aplica de forma automática el perfil de seccomp predeterminado de containerd a todas tus cargas de trabajo. No es necesario que realices ninguna otra acción. Los intentos de realizar llamadas al sistema restringidas fallarán. Autopilot no permite perfiles seccomp personalizados porque GKE administra los nodos.

En los clústeres estándar, debes aplicar un perfil seccomp de forma manual. GKE no aplica un perfil por ti.

Habilita seccomp en clústeres de Standard

Aplica un perfil seccomp de forma manual mediante la configuración del contexto de seguridad del Pod o del contenedor mediante el campo spec.securityContext.seccompProfile en la especificación del Pod, como en el siguiente ejemplo. Te recomendamos que uses un perfil de seccomp para tus cargas de trabajo, a menos que tu caso de uso requiera un uso de llamadas al sistema restringidas. Los dos tipos seccompProfile admitidos son los siguientes:

RuntimeDefault: el perfil predeterminado especificado por el entorno de ejecución de containerd.
Localhost: una definición de perfil personalizado.

En el siguiente manifiesto de ejemplo, se establece el perfil de seccomp en el perfil predeterminado del entorno de ejecución:

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

Cuando implementas este manifiesto, si un contenedor en el Pod intenta realizar una llamada al sistema que infringe el perfil seccomp predeterminado del entorno de ejecución, el Pod o la carga de trabajo puede experimentar un comportamiento inesperado. Por ejemplo, un Pod que realiza una llamada al sistema restringida durante el inicio no se inicia. Si una aplicación intenta realizar una llamada al sistema restringida mientras se ejecuta el Pod, es posible que notes errores en el contenedor. La gravedad de una llamada al sistema con errores depende de cómo la aplicación maneja los errores.

Usa un perfil de seccomp personalizado en clústeres de Standard

Si el perfil de seccomp predeterminado del entorno de ejecución es demasiado restrictivo para tu aplicación (o no es lo suficientemente restrictivo), puedes aplicar un perfil de seccomp personalizado a los Pods en clústeres estándar. Este proceso requiere acceso al sistema de archivos en el nodo. Para obtener un instructivo sobre cómo cargar y usar perfiles seccomp personalizados, consulta Restringe las llamadas al sistema de un contenedor con seccomp.