Esta página se ha traducido con Cloud Translation API.

Acerca de seccomp en GKE

Autopilot Standard

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

Esta página está dirigida a especialistas en seguridad que usan seccomp como parte de la estrategia de seguridad de su organización y quieren saber cómo interactúa GKE con los perfiles de seccomp. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE. Google Cloud

¿Qué es seccomp?

El modo de computación segura (seccomp) es una función de seguridad de Linux que te permite restringir las llamadas al sistema (syscalls) que un proceso puede hacer al kernel de Linux.

De forma predeterminada, los nodos de GKE usan el sistema operativo Container-Optimized OS con el runtime de contenedores containerd. containerd protege el kernel de Linux limitando las capacidades de Linux permitidas a una lista predeterminada. Además, puedes limitar aún más las llamadas al sistema permitidas con un perfil de seccomp. containerd tiene un perfil de seccomp predeterminado disponible. Si GKE aplica el perfil seccomp predeterminado por ti, depende del modo de clúster que utilices, como se indica a continuación:

Autopilot (opción recomendada): GKE aplica el perfil seccomp predeterminado de containerd a todas las cargas de trabajo automáticamente.
Estándar: GKE no aplica el perfil seccomp predeterminado de containerd a todas las cargas de trabajo automáticamente. Te recomendamos que apliques el perfil seccomp predeterminado o un perfil seccomp personalizado a tus cargas de trabajo.

El perfil seccomp predeterminado de containerd proporciona un nivel de protección básico y, al mismo tiempo, mantiene la compatibilidad con la mayoría de las cargas de trabajo. La definición completa del perfil seccomp de containerd está disponible en GitHub.

Funciones y llamadas al sistema de Linux

Los procesos que no son root y que se ejecutan en sistemas Linux pueden requerir privilegios específicos para realizar acciones como usuario root. Linux usa capacidades para dividir los privilegios disponibles en grupos, de forma que un proceso que no sea root pueda realizar una acción específica sin que se le concedan todos los privilegios. Para que un proceso pueda hacer una llamada al sistema específica, debe tener los privilegios correspondientes concedidos por una función.

Para ver una lista de todas las funciones de Linux, consulta Funciones.

Llamadas al sistema denegadas en el perfil seccomp predeterminado de GKE

El perfil seccomp predeterminado de containerd bloquea todas las llamadas al sistema y, a continuación, permite de forma selectiva llamadas al sistema específicas, algunas de las cuales dependen de la arquitectura de la CPU de la VM del nodo y de la versión del kernel. La variable syscalls de la función DefaultProfile muestra los syscalls permitidos para todas las arquitecturas.

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

Syscalls denegadas
`mount`, `umount`, `umount2`, `fsmount`, `mount_setattr`	Restringe el acceso o la manipulación del sistema de archivos del nodo por parte de los procesos fuera de los límites del contenedor. También se ha denegado porque se ha retirado la `CAP_SYS_ADMIN` capacidad.
`bpf`	Restringe los procesos para que no creen programas eBPF en el kernel, lo que puede provocar una elevación de privilegios en el nodo. Por ejemplo, CVE-2021-3490 usó la llamada al sistema `bpf`. También se ha denegado porque se ha retirado la `CAP_SYS_ADMIN` capacidad.
`clone`, `clone3`, `unshare`	Restringe los procesos para que no creen procesos nuevos en espacios de nombres nuevos que puedan estar fuera del espacio de nombres restringido del contenedor. Estos nuevos procesos pueden tener permisos y funciones elevados. Por ejemplo, CVE-2022-0185 usó la llamada al sistema `unshare`. También se ha denegado porque se ha retirado la `CAP_SYS_ADMIN` capacidad.
`reboot`	Restringe los procesos para que no reinicien el nodo. Se ha denegado porque se ha retirado la `CAP_SYS_BOOT` capacidad.
`open_by_handle_at`, `name_to_handle_at`	Restringe el acceso a archivos que no estén en el contenedor. Estas llamadas al sistema se usaron en una de las primeras vulnerabilidades de escape de contenedores de Docker. También se ha denegado porque se han retirado las funciones `CAP_DAC_READ_SEARCH` y `CAP_SYS_ADMIN`.

Cómo usar seccomp en GKE

En los clústeres Autopilot, GKE aplica automáticamente el perfil seccomp predeterminado de containerd a todas tus cargas de trabajo. No es necesario hacer nada más. Los intentos de hacer llamadas al sistema restringidas fallan. Autopilot no permite perfiles seccomp personalizados porque GKE gestiona los nodos.

En los clústeres estándar, debes aplicar manualmente un perfil seccomp. GKE no aplica ningún perfil por ti.

Habilitar seccomp en clústeres estándar

Aplica un perfil de seccomp manualmente configurando el contexto de seguridad del pod o del contenedor con el campo spec.securityContext.seccompProfile en la especificación del pod, como en el siguiente ejemplo. Te recomendamos que uses un perfil seccomp para tus cargas de trabajo, a menos que tu caso práctico requiera usar llamadas al sistema restringidas. Los dos tipos de seccompProfile admitidos son los siguientes:

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

En el siguiente ejemplo de archivo de manifiesto se define el perfil seccomp como el perfil predeterminado del tiempo 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 implementes este manifiesto, si un contenedor del pod intenta hacer una llamada al sistema que infringe el perfil seccomp predeterminado del tiempo de ejecución, el pod o la carga de trabajo podrían experimentar un comportamiento inesperado. Por ejemplo, un pod que haga una llamada al sistema restringida durante el inicio no podrá iniciarse. Si una aplicación intenta hacer una llamada al sistema restringida mientras el pod está en ejecución, es posible que observes errores en el contenedor. La gravedad de un error de llamada al sistema depende de cómo gestione los errores la aplicación.

Usar un perfil seccomp personalizado en clústeres estándar

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