En los orígenes de Kubernetes como software libre, cuando Google lo liberó en 2014, la seguridad fue dejada de lado por la comunidad de desarrolladores, delegando esta tarea a sistemas externos como: sistema de contenedores utilizado, sistema operativo, seguridad de red de proveedor, sistemas perimetrales antiDDoS, IDS, IPS, firewall de red…etc.

Lo importante era escalar y desarrollar un sistema tolerante a fallos basado en contenedores frente a sus competidores, por entonces escasos y poco desarrollados.

Pero no solo de escalar vive el software, por lo que se pusieron manos a la obra para dar cobertura de seguridad a un ecosistema cada vez más extendido y con algunos competidores y muchas versiones Enterprise en la actualidad como por ejemplo:

• AWS ECS
• Docker Swarm
• HashiCorp Nomad
• Red Hat Openshift
• Rancher

Hoy hablamos de seccomProfile, (acrónimo elegido de Secure Computing), que implementa parte de la seguridad  de los procesos Linux para filtrar las llamadas al sistema de los contenedores en función de las reglas definidas.

Se introdujo en la versión v1.19 a través de la definición de los securityContext, desactivado por defecto para dar compatibilidad a versiones anteriores.

Los tipos de profiles disponibles son:

• Unconfined (por defecto): seccomp desactivado.
• RuntimeDefault: seccomp activado con opciones por defecto.
• Localhost: seccomp en modo local indicando el path a utilizar <kubelet-root-dir>/seccomp en kubelet.

Para facilitar su uso se introdujo la funcionalidad en kubelet de SeccomDefault en la versión v1.22.0-alpha, que permite activar por defecto el profile RuntimeDefault y mejorar la seguridad base de los procesos. Basta con añadir el parámetro de ejecución a kubelet SeccompDefault=true.

A partir de la versión v1.25.0-beta.0, SeccomDefault se activa por defecto en la configuración de kubelet. En los pods podemos indicarlo de la siguiente forma:

securityContext:
  seccompProfile:
    type: "RuntimeDefault"

Y dirás, sí, todo esto está muy bien pero, ¿qué limitaciones y protecciones nos ofrece por defecto esta funcionalidad una vez aplicado? Dependiendo de las Pod Security Standards definidas en nuestro cluster o Namespace, nos encontraremos estas restricciones: 

• Evita ejecuciones de pods con escalada de privilegios, por lo que obligatoriamente debe definirse allowPrivilegeEscalation: false en securityContext.
• Las llamadas al sistema serán filtradas (pero no denegadas) y deben configurarse explícitamente en la sección capabilities de securityContext del contenedor. Para mayor protección, el pod deberá limitar cualquier llamada al sistema no necesaria por el servicio implementado:

capabilities:
    drop:
    - ALL

• Otras restricciones aplicables a nivel de pod o de contenedor son:

A nivel de pod:

runAsUser: <uid>
  runAsGroup: <gid>
  runAsNonRoot: true

A nivel de contenedor:

readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false

Además, podemos definir nuestros propios profiles con las llamadas al sistema que permitimos, así como otras restricciones que queramos configurar, e incluirlas de forma local y personalizada.

Ahora tenemos la tranquilidad de poder ejecutar imágenes públicas de contenedores, con uso de las llamadas al sistema restringido y otras limitaciones a nivel de proceso bajo control.