Seguridad de contenedores y Kubernetes

Los contenedores comparten el kernel del host, por lo que están menos aislados que las máquinas virtuales. La seguridad de los contenedores abarca la higiene de las imágenes (sin paquetes vulnerables), la protección en tiempo de ejecución (detección de comportamientos anómalos), las políticas de red (restricción de la comunicación entre pods) y la configuración de RBAC.

Trivy analiza las imágenes de contenedor en busca de CVE de paquetes del sistema operativo, vulnerabilidades de dependencias de aplicaciones, configuraciones incorrectas y secretos. Intégrelo en CI/CD para bloquear las imágenes con vulnerabilidades críticas antes de que lleguen a producción.

Utilice imágenes base mínimas (alpine, distroless). Ejecute como un usuario sin privilegios (USER 1000). Evite COPY . .; especifique los archivos concretos. Las compilaciones en varias etapas reducen el tamaño de la imagen final. Analice las imágenes antes de publicarlas. Nunca codifique secretos ni credenciales en las capas.

Kubernetes RBAC controla el acceso al servidor de API. ClusterRoles y Roles definen permisos sobre recursos (pods, secrets, deployments). ClusterRoleBindings y RoleBindings los asignan a usuarios, grupos o ServiceAccounts. Evite cluster-admin salvo para la automatización.

PSS define tres perfiles: Privileged (sin restricciones), Baseline (restricciones mínimas) y Restricted (reforzado). Aplíquelos mediante etiquetas de namespace del controlador de admisión PodSecurity. El perfil Restricted impide ejecutarse como root, no permite la escalada de privilegios y exige sistemas de archivos de solo lectura.

De forma predeterminada, todos los pods pueden comunicarse con los demás. Las NetworkPolicies de Kubernetes definen reglas de entrada y salida por selector de pod. Implemente políticas de denegación predeterminada y permita explícitamente solo las rutas de comunicación necesarias para limitar el alcance de una intrusión.

Los Secrets de Kubernetes están codificados en base64, pero no cifrados, de forma predeterminada. Habilite el cifrado en reposo para etcd. Utilice External Secrets Operator o Vault Agent Injector para obtener secretos de HashiCorp Vault o de administradores de secretos en la nube, en lugar de utilizar Secrets de Kubernetes.

Los controladores de admisión interceptan las solicitudes a la API antes de que se creen los objetos. OPA/Gatekeeper aplica políticas personalizadas (por ejemplo, exigir etiquetas específicas o bloquear contenedores privilegiados). Kyverno proporciona políticas como código con una sintaxis YAML más sencilla para las restricciones de seguridad habituales de K8s.

Falco detecta comportamientos anómalos en tiempo de ejecución mediante eBPF: shells iniciadas en contenedores, conexiones salientes inesperadas, archivos escritos en /etc, intentos de escalada de privilegios y ejecución de herramientas de ataque conocidas. Las reglas de alerta se pueden personalizar en YAML.

Habilite los registros de auditoría del servidor de API para registrar cada solicitud con el usuario, la acción, el recurso y la marca de tiempo. Reenvíelos a un SIEM para detectar actividad inusual en la API: listado de tokens de ServiceAccount, enumeración de secretos, escalada de roles y uso de kubectl exec en pods de producción.

Firme las imágenes de contenedor con Cosign (Sigstore) para garantizar la integridad de la cadena de suministro. Los controladores de políticas (Connaisseur, Kyverno) pueden exigir que solo se admitan en el clúster imágenes firmadas procedentes de registros de confianza, bloqueando la descarga de imágenes no confiables.

¿Qué consigue una Kubernetes NetworkPolicy con un podSelector vacío y policyTypes Ingress/Egress?

La seguridad de los contenedores y de Kubernetes requiere proteger la cadena de suministro de imágenes, aplicar RBAC y los estándares de seguridad de pods, implementar políticas de red, gestionar correctamente los secretos y utilizar detección en tiempo de ejecución para identificar ataques que eludan los controles preventivos.