¿Cómo se asegura un contenedor?

La seguridad de un contenedor se garantiza mediante la aplicación de controles por capas en los cinco componentes de la pila de contenedores: la imagen, el registro, el orquestador, el contenedor en ejecución y el sistema operativo anfitrión. La publicación especial 800-190 del NIST, la Guía de seguridad de contenedores de aplicaciones, define este modelo por capas y sus contramedidas.

Para proteger un contenedor, analice las imágenes en busca de vulnerabilidades antes de la implementación, descárguelas únicamente de registros privados de confianza, firme las imágenes para verificar su origen, ejecute los contenedores como usuario sin privilegios de administrador (sin privilegios de superusuario), refuerce la seguridad del orquestador y del sistema operativo anfitrión, mantenga la información confidencial fuera de las imágenes y supervise continuamente el comportamiento en tiempo de ejecución. La norma NIST SP 800-190 define estas contramedidas.

Puntos Clave

• La seguridad de los contenedores abarca cinco capas definidas en la norma NIST SP 800-190: imagen, registro, orquestador, entorno de ejecución del contenedor y sistema operativo anfitrión.
• Las imágenes base mínimas, la ejecución sin privilegios de administrador y la firma de imágenes eliminan las rutas de ataque más comunes a los contenedores antes de su implementación.
• Kubernetes eliminó PodSecurityPolicy en la versión 1.25; ahora, la admisión de seguridad de pods aplica los estándares Privilegiado, Baseline y Restringido mediante etiquetas de espacio de nombres.
• Docker comenzó a retirar Docker Content Trust en agosto de 2025; Sigstore Cosign y Notary Project Notation son los estándares actuales para firmar imágenes de contenedores.
• Todas las plataformas de contenedores funcionan con claves, certificados y secretos. Las claves de firma deben estar en un HSM, y las credenciales en un gestor de secretos, nunca en la imagen.

¿Qué es un contenedor?

Un contenedor es una unidad de software independiente que empaqueta el código de una aplicación junto con sus dependencias, de modo que la aplicación se ejecute de forma consistente en diferentes entornos informáticos.

Los contenedores son una forma de virtualización de sistemas operativos. Un contenedor almacena los ejecutables, binarios, bibliotecas y archivos de configuración que necesita una aplicación, pero no una imagen completa del sistema operativo, lo que los mantiene ligeros y portátiles. Un solo contenedor puede ejecutar desde un pequeño microservicio hasta una aplicación de mayor tamaño.

Los contenedores se crean a partir de imágenes de contenedor. Una imagen se compone de capas de archivos, con una imagen base en la parte inferior y capas de aplicación encima. Dado que cada imagen derivada hereda la capa base, esta última es la capa más crítica que se debe proteger.

¿Qué es la gestión de contenedores?

La gestión de contenedores consiste en la automatización de la creación, el despliegue y el escalado de contenedores en un entorno.

Las plataformas de gestión de contenedores permiten a los equipos añadir, reemplazar y organizar contenedores a gran escala. En la práctica, esto implica analizar y controlar las imágenes que los equipos descargan y crean, alojarlas en registros privados, aplicar acceso basado en roles, automatizar políticas y detectar vulnerabilidades antes de que las imágenes lleguen a producción. La automatización reduce los errores humanos inherentes a las operaciones manuales con contenedores.

¿Por qué es importante la seguridad de los contenedores?

La seguridad de los contenedores es importante porque actualmente ejecutan una gran parte de las cargas de trabajo de producción, y un solo contenedor vulnerable puede convertirse en un punto de entrada a la infraestructura general.

Los contenedores ofrecen importantes ventajas de aislamiento, pero también amplían la superficie de ataque. Los contenedores en el mismo host comparten el núcleo del host, por lo que una fuga de un contenedor amenaza todas las cargas de trabajo en esa máquina. La mayor parte del tráfico de contenedores es tráfico bidireccional entre servicios dentro del clúster, que las herramientas de seguridad perimetral, como los firewalls de aplicaciones web y los sistemas de prevención de intrusiones, no están diseñadas para inspeccionar. Los controles específicos deben cubrir esta necesidad.

¿Cómo se protege un contenedor? El modelo NIST SP 800-190.

La Guía de seguridad de contenedores de aplicaciones , publicada por el NIST como Publicación Especial 800-190 en septiembre de 2017, organiza la seguridad de los contenedores en torno a cinco componentes: imágenes, registros, orquestadores, contenedores y el sistema operativo anfitrión. Proteger un contenedor implica aplicar controles en cada capa.

Capa	Riesgos primarios	Controles básicos
Imagen	Vulnerabilidades conocidas, secretos ocultos, fuentes no confiables	Escanee en CI y en el registro, use imágenes base mínimas, firme con Cosign o Notación
Registro	Imágenes obsoletas, acceso inseguro	Registro privado, autenticación robusta, eliminación de imágenes antiguas, escaneo al enviar
Orchestrator	Acceso de administrador sin restricciones, tráfico de pod a pod sin protección	RBAC privilegios mínimos, admisión de seguridad de pods, políticas de red
Envase	Ataques en tiempo de ejecución, escalada de privilegios, desviación de imágenes	Usuarios sin privilegios de administrador, capacidades reducidas, detección de amenazas en tiempo de ejecución
SO del host	Gran superficie de ataque, núcleo compartido	Sistema operativo anfitrión específico del contenedor, aplicación de parches inmediata, acceso restringido

Tres recomendaciones del NIST merecen especial atención. Primero, ejecute los contenedores en un sistema operativo específico para contenedores, que incluye menos funciones y una superficie de ataque menor que un sistema operativo de propósito general. Segundo, agrupe los contenedores por propósito, sensibilidad y perfil de riesgo en hosts separados, de modo que si se compromete un grupo, el atacante no tendrá acceso a los demás. Tercero, utilice herramientas de seguridad en tiempo de ejecución y de gestión de vulnerabilidades compatibles con contenedores. Los escáneres tradicionales tienen puntos ciegos en las capas de imagen y la configuración, y pueden indicar que todo está bien cuando no es así.

Mejores prácticas de seguridad para contenedores Docker

Los controles de Docker con mayor impacto son las imágenes mínimas de confianza, el principio de mínimo privilegio en tiempo de ejecución y los artefactos firmados.

1. Utilice imágenes base mínimas y fiables: Descarga solo de fuentes fiables, como las imágenes oficiales de Docker y los editores verificados, y da preferencia a las variantes ligeras o sin distribución. Menos paquetes significan menos vulnerabilidades que heredar.
2. Ejecutar como usuario no root con privilegios mínimos: En el Dockerfile, configure un usuario que no sea root, elimine las funcionalidades de Linux que la aplicación no necesite y evite el modo privilegiado.
3. Mantén los secretos fuera de las imágenes: Nunca incluyas contraseñas, tokens o claves en un Dockerfile o en una capa de la imagen. Inyecta las credenciales en tiempo de ejecución desde un gestor de secretos.
4. Firma y verifica las imágenes: Utilice Sigstore Cosign o Notary Project Notation. Docker comenzó a retirar Docker Content Trust el 8 de agosto de 2025, y el servicio Notary v1 que lo respalda se cerrará el 8 de diciembre de 2026, por lo que no cree nuevas verificaciones en DCT.
5. Escanee continuamente y reconstruya en lugar de aplicar parches.Analiza las imágenes en la canalización y en el registro, y trata los contenedores como objetos efímeros e inmutables. Cuando se implemente una corrección, reconstruye y vuelve a desplegar la imagen.
6. No ejecute SSH dentro de contenedores: Solucione los problemas mediante docker exec o el orquestador en lugar de incluir un demonio de inicio de sesión en cada carga de trabajo.

Mejores prácticas de seguridad para contenedores Kubernetes

La seguridad de Kubernetes comienza con la compatibilidad con versiones y la aplicación de políticas a nivel de espacio de nombres.

• Mantente en una versión compatible: Kubernetes lanza tres versiones menores al año, y cada una recibe parches durante aproximadamente 14 meses. Ejecutar una versión sin soporte implica ejecutarla sin correcciones de seguridad.
• Aplicar los estándares de seguridad de los podsPodSecurityPolicy quedó obsoleto en la versión 1.21 y se eliminó en la versión 1.25. Aplique el estándar Baseline o Restricted mediante las etiquetas del espacio de nombres de Pod Security Admission y agregue un motor de políticas como OPA Gatekeeper o Kyverno donde necesite reglas personalizadas.
• Acceso restringido: Aplique RBAC de privilegios mínimos al servidor API y restrinja SSH Acceso a los nodos. El puerto 22 debe estar cerrado en todos los nodos, excepto a través de su VPN o una ruta de acceso seguro (bastion path).
• Utilice los espacios de nombres y las políticas de red como límites: Separe las cargas de trabajo en espacios de nombres y aplique objetos NetworkPolicy para que los pods solo puedan comunicarse con los servicios que necesitan.
• Proteger secretos: Habilite el cifrado en reposo para los secretos de Kubernetes y dé preferencia a un almacén de secretos externo para las credenciales de alto valor.
• Auditoría y seguimiento: Habilite los registros de auditoría y reciba alertas sobre fallos de autorización, que a menudo indican que se están intentando utilizar credenciales robadas contra la API.

Mejores prácticas de seguridad para contenedores de AWS

En AWS, la seguridad de los contenedores se centra en Amazon Elastic Container Service (ECS), Amazon Elastic Kubernetes Service (EKS) y el análisis de imágenes en Amazon Elastic Container Registry (ECR).

• Escaneo en ECR: Habilita el análisis al realizar un push. El análisis básico utiliza tecnología nativa de AWS para detectar vulnerabilidades en los paquetes del sistema operativo. El análisis mejorado, integrado con Amazon Inspector, incluye paquetes de lenguajes de programación, análisis continuo a medida que se publican nuevas vulnerabilidades (CVE) y, desde 2025, cubre bases mínimas como imágenes scratch, distroless y Chainguard. Inspector también asigna las imágenes a las cargas de trabajo de ECS y EKS que las ejecutan, lo que te ayuda a corregir primero lo que se implementa.
• Respetar el modelo de responsabilidad compartidaAWS protege la infraestructura subyacente; usted protege sus imágenes, la configuración de tareas y pods, los permisos de IAM y el acceso a la red. Herramientas como Prowler ayudan a verificar el entorno antes del despliegue.
• Eliminar privilegios innecesarios: Asigne a las tareas y a los pods roles de IAM con ámbito definido, en lugar de permisos generales a nivel de nodo. Cuanto mayor sea el acceso predeterminado de un contenedor, mayor será el impacto y más difícil será el análisis forense tras una brecha de seguridad.
• Mira más allá del contenedor: Evalúe también los hosts y el plano de control, realice escaneos periódicos y mantenga todos los componentes actualizados.

Mejores prácticas de seguridad para contenedores de Microsoft Azure

En Azure, la seguridad de los contenedores se centra en Azure Container Registry (ACR) y Microsoft Defender for Containers.

• Utilice un registro privado: Almacene y descargue imágenes desde ACR en lugar de repositorios públicos, ya que las imágenes públicas se componen de múltiples capas de software y cualquier capa puede contener una vulnerabilidad. Tenga en cuenta que ACR está dejando de usar Docker Content Trust (la descontinuación comenzó el 31 de marzo de 2025 y se eliminará el 31 de marzo de 2028) en favor de la firma de proyectos Notary con Notation.
• Escanee con Defender en busca de contenedores: Microsoft Defender for Cloud, el servicio anteriormente conocido como Azure Security Center hasta su cambio de nombre en noviembre de 2021, realiza evaluaciones de vulnerabilidad sin agente en imágenes ACR mediante Microsoft Defender Vulnerability Management. El escáner de contenedores Qualys integrado anteriormente se retiró en marzo de 2024.
• Credenciales seguras: Los contenedores se distribuyen entre regiones y clústeres, por lo que conviene guardar las contraseñas, los tokens y las claves de API en Azure Key Vault y usar identidades administradas para la autenticación entre servicios en lugar de secretos integrados.

El papel de la criptografía en la seguridad de los contenedores

Cada capa de una plataforma de contenedores depende de claves, certificados y secretos.

Las firmas de imagen son tan seguras como las claves privadas que las respaldan, por lo que las claves de firma deben estar en un módulo de seguridad de hardware o en un KMS administrado, no en un servidor de compilación. Los certificados TLS protegen el tráfico entre registros, servidores API y cargas de trabajo, y las mallas de servicios van más allá con TLS mutuo entre pods, lo que requiere la emisión y rotación de certificados a velocidad de máquina desde su infraestructura de clave pública (PKI) . Las identidades de canalizaciones y cargas de trabajo siguen la misma regla que la cadena de herramientas DevOps en la que se ejecutan: credenciales de corta duración, emitidas centralmente y revocables instantáneamente. Una plataforma de contenedores es tan confiable como las claves, certificados y secretos que la ejecutan.

Cómo ayuda la consultoría de cifrado

Las soluciones de seguridad para DevOps de Encryption Consulting protegen la capa criptográfica de la que depende cada canalización de contenedores. CodeSign Secure centraliza la firma de código y artefactos detrás de HSM validados según FIPS 140-2 Nivel 3 y se integra con herramientas de CI/CD como Jenkins, GitLab y Azure DevOps, de modo que cada imagen y artefacto se firma, se marca con la hora y se registra sin ralentizar la entrega. Los equipos de consultoría le ayudan a gestionar los certificados, las claves y los secretos que utilizan sus clústeres. Respaldado por las prácticas certificadas ISO/IEC 27001:2022 y SOC 2.

Preguntas frecuentes

¿Qué es la seguridad de los contenedores en términos sencillos?

La seguridad de contenedores consiste en proteger las aplicaciones en contenedores en todas sus capas: la imagen a partir de la cual se crea el contenedor, el registro que lo almacena, el orquestador que lo programa, el propio contenedor en ejecución y el sistema operativo subyacente. La norma NIST SP 800-190 define los riesgos y las contramedidas para cada una de estas cinco capas.

¿Cómo se protege un contenedor Docker?

Comience con una imagen base mínima y confiable, y reconstruyala periódicamente en lugar de parchear contenedores en ejecución. Ejecute el contenedor como un usuario sin privilegios de administrador, elimine las funcionalidades de Linux innecesarias y nunca incluya credenciales en la imagen. Analice las imágenes en el flujo de trabajo y el registro, y fírmelas con Sigstore Cosign o Notation para que solo las imágenes verificadas lleguen a producción.

¿Qué es NIST SP 800-190?

La publicación especial 800-190 del NIST, Guía de seguridad para contenedores de aplicaciones, fue publicada por el Instituto Nacional de Estándares y Tecnología de EE. UU. en septiembre de 2017. Describe los riesgos de seguridad de las tecnologías de contenedores en imágenes, registros, orquestadores, contenedores y sistemas operativos anfitriones, y recomienda contramedidas para cada uno. Sigue siendo la referencia fundamental para los programas y auditorías de seguridad de contenedores.

¿Qué reemplazó a las políticas de seguridad de pods en Kubernetes?

Pod Security Admission reemplazó a PodSecurityPolicy, que quedó obsoleto en Kubernetes 1.21 y se eliminó en la versión 1.25. Pod Security Admission aplica los tres estándares de seguridad de pods (Privileged, Baseline y Restricted) mediante etiquetas de espacio de nombres. Los equipos que necesitan reglas más específicas que las estándar integradas suelen añadir un motor de políticas como OPA Gatekeeper o Kyverno.

¿Deben firmarse las imágenes de los contenedores?

Sí. La firma digital permite que tu clúster verifique que una imagen proviene de un editor de confianza y que no ha sido modificada después de su creación. Docker Content Trust, el mecanismo de firma anterior, comenzó a retirarse en agosto de 2025 y su servicio Notary v1 se cerrará en diciembre de 2026, por lo que las nuevas canalizaciones deberían usar Sigstore Cosign o Notary Project Notation, y los controles de admisión deberían impedir que las imágenes sin firmar lleguen a producción.

Asegure su oleoducto de contenedores

Las imágenes firmadas, las claves protegidas y los clústeres reforzados garantizan la fiabilidad de una plataforma de contenedores rápida. Explore la sección «Protegiendo DevOps» , vea CodeSign Secure en acción o consulte con un asesor de Encryption Consulting.