¿Qué es la Seguridad de Contenedores?

¿Qué es la seguridad de contenedores?

La seguridad de contenedores es la disciplina de proteger aplicaciones containerizadas y la infraestructura en la que corren, a través de todo el ciclo de vida: build de imagen, almacenamiento de registro, despliegue, ejecución de runtime y orquestación. Como los contenedores (Docker, OCI, containerd) y Kubernetes se han convertido en el sustrato de despliegue dominante para aplicaciones cloud-native, la seguridad de contenedores se ha convertido en una sub-especialidad distinta dentro de la seguridad cloud — distinta porque los contenedores introducen superficies de ataque que las VMs y bare-metal no tienen (kernel compartido, supply chain de imagen, workloads efímeros, tasas de cambio rápidas).

Comprometer contenedores es cada vez más atractivo para los atacantes. Mineros de cripto inyectados vía imágenes de contenedor vulnerables, ataques de supply chain vía imágenes base envenenadas en Docker Hub, exploits de escape contra el kernel desde dentro de un contenedor, movimiento lateral a través de un cluster Kubernetes — todas son amenazas reales y documentadas en 2026. El modelo de defensa en profundidad para contenedores abarca escaneo de imágenes, políticas de registro, detección runtime, segmentación de red y endurecimiento de host.

Las cinco capas de seguridad de contenedores

1. Seguridad de imagen (build-time)

El fundamento. Las vulnerabilidades en imágenes de contenedor son heredadas por cada workload que las usa.

• Usa imágenes base mínimas (distroless, Alpine, scratch) — menos paquetes = menos CVEs.
• Fija versiones específicas, no latest. Fija por digest (sha256), no por tag.
• Escanea durante build con Trivy, Grype, Snyk, Anchore, Docker Scout. Falla builds en CVEs críticos.
• No corras como root. Añade USER nonroot en Dockerfile.
• No incluyas secretos en imágenes. Usa inyección en mount-time.
• Firma imágenes con cosign o Notary. Verifica firmas en deploy.

2. Seguridad de registro

Donde viven las imágenes construidas. Compromiso aquí = ataque de supply chain.

• Usa un registro privado (ECR, GCR, ACR, Harbor) con acceso controlado por IAM.
• Escaneo continuo de imágenes almacenadas (los CVEs se descubren después del push).
• Restringe pulls por IP / VPC / cuenta de servicio.
• Logs de auditoría de quién pusheó y pulleó qué.

3. Seguridad runtime

Lo que el contenedor hace una vez corriendo. El área de investigación más activa en 2026.

• Suelta capabilities de Linux; el predeterminado es excesivo. Usa capabilities: { drop: ["ALL"] } y añade solo lo necesario.
• Sistema de archivos raíz de solo lectura (readOnlyRootFilesystem: true) — la mayoría de las apps pueden correr con esto.
• Perfiles seccomp + AppArmor / SELinux para limitar syscalls.
• Detección runtime: Falco, Sysdig, Aqua, Sysdig Secure detectan comportamiento anómalo (ejecución de shell en contenedores producción, conexiones de red inusuales).
• Sin contenedores privilegiados en producción. privileged: true es esencialmente equivalente a root en el host.

4. Seguridad de orquestación / Kubernetes

Kubernetes es el orquestador dominante y una superficie de ataque profunda en sí misma.

• RBAC: cuentas de servicio con privilegios mínimos. La mayoría de los pods no necesitan cluster-admin.
• NetworkPolicies: ingress y egress default-deny, luego permitir solo lo necesario.
• Pod Security Standards (reemplazando PodSecurityPolicies): perfil Restricted por defecto.
• Admission controllers (OPA, Kyverno) para hacer cumplir políticas en deploy time.
• Logging de auditoría en el servidor API.
• Deshabilitar acceso anónimo, endurecimiento de API kubelet.

5. Seguridad de host

El SO debajo de los contenedores.

• Mantén el kernel parcheado (los CVEs de kernel habilitan escapes de contenedor).
• Usa SOs endurecidos (Bottlerocket, Talos, CoreOS) — mínimos, inmutables.
• SSH deshabilitado en producción (usa acceso just-in-time vía herramientas como Teleport o AWS SSM).
• Detección de intrusión a nivel de host (auditd, monitorización basada en eBPF).

El modelo de amenaza de contenedores: lo que los atacantes realmente hacen

• Explotación de imagen vulnerable. El atacante escanea tu registro, encuentra un CVE en tu versión de nginx, lo explota.
• Supply chain. Una imagen base popular en Docker Hub es comprometida; cada imagen downstream hereda la puerta trasera.
• Escape de contenedor. Exploit de kernel (Dirty Pipe, Dirty COW históricamente) da root en host desde dentro del contenedor.
• Kubernetes mal configurado. API kubelet expuesta, cuenta de servicio predeterminada con demasiados permisos, o cluster admin anónimo habilitado.
• Inyección de minería de cripto. Imagen / runtime comprometido convierte tu cluster en una granja de minería. Común porque alineado económicamente.
• Movimiento lateral. Compromiso inicial de un pod → acceso a cuentas de servicio compartidas → acceso a otros pods → acceso al control plane del cluster.
• Filtración de secretos. Secretos almacenados como variables de entorno visibles en kubectl describe pod para cualquiera con acceso de lectura.

Errores comunes de seguridad de contenedores

• Correr como root por defecto. La mayoría de las imágenes de contenedor corren como root a menos que se diga explícitamente lo contrario. Usa usuarios non-root en Dockerfiles.
• Pullear :latest en producción. Un nuevo "latest" puede ser pusheado en cualquier momento. Usa tags o digests específicos.
• Contenedores privilegiados "porque es más fácil". privileged: true derrota la mayoría del aislamiento de contenedor. Usa capabilities específicas en su lugar.
• Sin escaneo de imagen en CI. Las vulnerabilidades llegan a prod sin detectar. Añade Trivy / Grype a tu pipeline.
• Egress abierto. El networking predeterminado de Kubernetes permite a pods comprometidos llamar a casa, exfiltrar datos, escanear servicios internos. Usa NetworkPolicies.
• Compartir cuentas de servicio entre pods. Un pod comprometido obtiene acceso a todo lo que esa cuenta puede hacer. Cuentas de servicio por workload.
• Almacenar secretos en env vars sin rotación. Visibles en salida de describe, en env de contenedor, en logs. Usa Secretos de Kubernetes con encriptación en reposo, o gestores de secretos externos (Vault, AWS Secrets Manager).
• Confiar en el registro sin verificación. Firma imágenes y verifica firmas. De lo contrario un atacante que comprometa tu registro puede inyectar cualquier cosa.

FAQ: Seguridad de Contenedores

¿Cuál es la vulnerabilidad de contenedor más común en 2026?

Imágenes base obsoletas que llevan CVEs conocidos. La mayoría de las imágenes de contenedor derivan de imágenes base que han tenido vulnerabilidades descubiertas desde la publicación original. El re-escaneo continuo lo atrapa; los rebuilds periódicos lo parchean.

¿Son los contenedores más o menos seguros que las VMs?

Los contenedores comparten el kernel del host, así que los exploits de kernel afectan a todos los contenedores; las VMs tienen aislamiento asistido por hardware. Pero los contenedores tienen superficies de ataque más pequeñas (sin SO completo por workload), ciclos de parcheo más rápidos y mejor herramienta para escaneo a nivel de imagen. Evaluación neta: seguridad comparable con diferentes tradeoffs, cuando ambos están bien configurados.

¿Necesito una herramienta de seguridad runtime como Falco?

Para producción a escala, sí. Falco / Sysdig / Aqua detectan comportamiento anómalo (contenedor corriendo shell, contenedor haciendo conexiones de red inesperadas) que el escaneo en build-time no puede. Para staging y clusters pequeños, saltarse es razonable.

¿Qué hay sobre la seguridad Kubernetes específicamente?

Trata tu cluster como un límite de seguridad multi-tenant incluso si aún no tienes multi-tenancy. RBAC, NetworkPolicies, Pod Security Standards, admission controllers, logs de auditoría. CIS Benchmarks para Kubernetes es la checklist de endurecimiento canónica.

¿Cómo aseguro la supply chain?

Firma imágenes en build (cosign), verifica firmas en admisión (controllers de política Sigstore), usa SBOMs (CycloneDX, SPDX) para rastrear qué hay en cada imagen, escanea registros continuamente. El framework SLSA define niveles de madurez para seguridad de supply chain.

¿Necesito una herramienta CSPM?

Para despliegues Kubernetes multi-cloud, las herramientas Cloud Security Posture Management (Wiz, Orca, Prisma Cloud) ayudan a rastrear configuraciones erróneas a través de clusters. Para single-cloud single-cluster, las herramientas nativas (AWS Inspector, GCP Security Command Center) son suficientes.

¿Qué hay sobre los contenedores serverless?

AWS Fargate, Google Cloud Run, Azure Container Apps reducen la seguridad de host a la responsabilidad de la plataforma, pero la seguridad de imagen y la seguridad runtime aún aplican. La historia de supply chain no cambia.

Cómo se relaciona LoadFocus con la seguridad de contenedores

Las aplicaciones containerizadas necesitan manejar validación de seguridad bajo carga realista — el middleware de seguridad lento (proxies de auth, terminadores mTLS, WAFs) a menudo se convierte en el cuello de botella bajo tráfico. Las pruebas de carga LoadFocus validan que las stacks de seguridad endurecidas (con todos tus agentes de seguridad runtime habilitados) todavía cumplen los objetivos de latencia a escala de producción. La monitorización de API rastrea la latencia por endpoint continuamente, atrapando cuando una degradación de actualización de seguridad golpea producción.