¿Qué es la seguridad de contenedores?

¿Qué es la seguridad de contenedores?

La seguridad de contenedores es la práctica de proteger las aplicaciones en contenedores y lo que las ejecuta durante todo su ciclo de vida: la imagen que se construye, el registro que la almacena, el orquestador que la despliega, el contenedor en ejecución y el host que hay debajo. Los contenedores comparten el kernel del host y se reconstruyen con frecuencia, así que el contenido de la imagen y la configuración pesan más que el endurecimiento de un servidor de larga vida. El NIST trata el tema en SP 800-190, la Application Container Security Guide.

Las cinco capas

1. Imágenes (tiempo de compilación)

• Partir de una imagen base mínima: hay menos paquetes que parchear.
• Fijar versiones, idealmente por digest, en lugar de usar latest.
• Escanear las imágenes en busca de vulnerabilidades conocidas en la CI y hacer fallar la compilación a partir de la gravedad que se elija.
• Ejecutar con un usuario no root y no incluir secretos en la imagen.
• Firmar las imágenes y verificar la firma antes del despliegue.

2. Registro

• Usar un registro privado con control de acceso y logs de auditoría.
• Volver a escanear las imágenes almacenadas, porque se publican nuevas vulnerabilidades después del push.

3. Orquestador (Kubernetes)

• RBAC con privilegios mínimos y una cuenta de servicio distinta por carga de trabajo.
• NetworkPolicies que denieguen el tráfico por defecto y permitan solo lo que cada pod necesita.
• Aplicar los Pod Security Standards de Kubernetes (Privileged, Baseline, Restricted) y preferir Restricted para cargas de aplicación.
• Controladores de admisión que rechacen manifiestos no conformes y registro de auditoría en el servidor de la API.
• Secretos mediante la API de Secrets con cifrado en reposo, o un gestor de secretos externo.

4. Ejecución

• Eliminar las capabilities de Linux innecesarias, usar un sistema de archivos raíz de solo lectura cuando la aplicación lo permita y evitar contenedores privilegiados.
• Aplicar perfiles seccomp y AppArmor o SELinux para limitar las llamadas al sistema.
• Vigilar comportamientos extraños, como una shell que arranca en un contenedor de producción o conexiones salientes inesperadas.

5. Host

• Parchear el kernel y el runtime de contenedores. Al compartir kernel, un fallo del kernel afecta a todos los contenedores del nodo.
• Usar un sistema operativo de host mínimo y orientado a contenedores y restringir los accesos directos.

Ejemplo

Un equipo despliega un servicio Node sobre una imagen base de sistema completo, como root, con la etiqueta latest y una contraseña de base de datos en una variable de entorno. Pasar a una imagen ligera fijada por digest, usuario no root, sistema de archivos de solo lectura, un Secret montado en ejecución y una NetworkPolicy de denegación por defecto elimina casi todas las vías por las que un fallo en una dependencia acaba dando acceso a la base de datos o al nodo.

Errores frecuentes

• Ejecutar como root porque la imagen lo permite por defecto.
• Usar latest en producción: una reconstrucción cambia lo que se ejecuta sin revisión.
• Contenedores privilegiados "para que funcione", lo que elimina casi todo el aislamiento.
• Escanear solo al compilar y no volver a revisar lo ya desplegado.
• Dejar abierto todo el tráfico entre pods y el saliente, de modo que un pod comprometido llega a todo.
• Compartir una cuenta de servicio amplia entre cargas de trabajo.
• Configurar los clústeres a mano. Los manifiestos deben estar en control de versiones y revisarse como código; vea infraestructura como código.

Conceptos relacionados

Dividir una aplicación en microservicios multiplica las imágenes y las rutas de red que hay que proteger. El acceso de cargas y personas debe seguir los principios de la gestión de identidades y accesos, y el panorama de lo que intentan los atacantes está en amenazas de ciberseguridad.

Dónde encaja LoadFocus

LoadFocus no es un producto de seguridad de contenedores: no escanea imágenes, no revisa la configuración del clúster ni detecta intrusiones. Ayuda con la parte de rendimiento de una configuración endurecida. Los sidecars, mTLS, los motores de políticas y los agentes de ejecución añaden latencia y consumo de CPU, y una prueba de carga muestra si el servicio sigue cumpliendo su objetivo de tiempo de respuesta con el tráfico esperado. La monitorización de API vigila después la disponibilidad y la velocidad de los endpoints tras cada despliegue. Sobre pruebas de seguridad en la nube, vea buenas prácticas de seguridad en pruebas en la nube.

Preguntas frecuentes: seguridad de contenedores

¿Son los contenedores menos seguros que las máquinas virtuales?

Aíslan de otra manera. Los contenedores comparten el kernel del host, así que un fallo del kernel o un contenedor privilegiado puede afectar a todo el nodo, mientras que una máquina virtual tiene su propio kernel. Los contenedores son más pequeños y fáciles de reconstruir y escanear. Ambos pueden ser seguros o inseguros según la configuración.

¿Qué corrijo primero?

Ejecutar sin root, dejar de usar latest y escanear imágenes en la CI. Es barato y elimina los problemas más habituales.

¿Necesito herramientas de seguridad en ejecución?

El escaneo en compilación solo encuentra vulnerabilidades conocidas. La detección en ejecución capta comportamientos que el escaneo no ve, como una shell o una conexión saliente inesperadas. Importa sobre todo en clústeres de producción sensibles.

¿Qué hacen los Pod Security Standards de Kubernetes?

Definen tres niveles: Privileged (sin restricciones), Baseline (bloquea escaladas de privilegios conocidas) y Restricted (sigue las prácticas actuales de endurecimiento de pods). Se aplica uno por namespace.

¿Lo resuelve el alojamiento serverless de contenedores?

Traslada la seguridad del host y del orquestador al proveedor. El contenido de la imagen, los secretos, los permisos y las reglas de red siguen siendo su responsabilidad.