¿Qué prácticas son más importantes?
Comenzar con imágenes base fiables y minimalistas
: utilice imágenes base bien mantenidas que incluyan únicamente los paquetes, las bibliotecas y las utilidades que la aplicación necesita. Esto reduce la superficie de ataque y facilita la aplicación de parches.
Analizar imágenes y dependencias antes de la implementación
: el análisis debe identificar vulnerabilidades conocidas, información confidencial expuesta y errores de configuración obvios antes de que los artefactos avancen más en la canalización. Esto no abarca toda la seguridad de los contenedores, pero sigue siendo uno de los controles más prácticos para reducir los riesgos evitables desde las primeras etapas.
Tratar los manifiestos de Kubernetes y la infraestructura como código (IaC) como artefactos críticos para la seguridad:
las definiciones de las cargas de trabajo (por ejemplo, de Kubernetes: pods y permisos), los gráficos Helm (configuraciones de Kubernetes empaquetadas), Terraform (aprovisionamiento de infraestructura, como recursos en la nube y redes) y otros artefactos de implementación (cualquier configuración utilizada para aprovisionar sistemas) pueden introducir problemas de privilegios, redes y exposición mucho antes del entorno de ejecución.
Aplicar privilegios mínimos en el clúster:
el RBAC de Kubernetes debe diseñarse cuidadosamente para los usuarios, las cuentas de servicio y las cargas de trabajo. El exceso de privilegios aumenta el riesgo de uso indebido y de escalada de privilegios.
Usar el control de admisiones y la aplicación de directivas
: las reglas de seguridad son más eficaces cuando se aplican automáticamente en el momento de la implementación. Los controles de admisión pueden detener recursos de riesgo antes de que sean admitidos en el clúster, mientras que los motores de políticas pueden ayudar a estandarizar los requisitos entre equipos y entornos.
Segmentar las redes para reducir el alcance potencial del impacto
: las políticas de red deben reflejar la forma en que las aplicaciones se comunican entre sí, al tiempo que limitan el movimiento este-oeste innecesario.
Supervisar el comportamiento del el runtime:
el análisis durante la fase de compilación no detectará todos los problemas que pueden surgir en el runtime. Los equipos aún necesitan visibilidad sobre el comportamiento de los procesos, las conexiones, el consumo de recursos, la desviación de políticas y la actividad sospechosa dentro de los contenedores en ejecución. Por este motivo, la supervisión en el runtime debe ir más allá del estado de las imágenes y abarcar las aplicaciones en ejecución, la actividad del orquestador y las comunicaciones entre contenedores.
Registrar lo suficiente para investigar
: los entornos de contenedor y Kubernetes generan registros en varias capas, y esa telemetría es importante para la detección y la investigación posterior al incidente.
¿Cómo deberían los equipos de DevSecOps aplicar estos controles sin ralentizar la entrega?
El enfoque más eficaz es poner el control correcto en la etapa correcta.
Durante la fase de compilación, céntrese en la higiene de las imágenes, el análisis de dependencias, la detección de secretos y la procedencia del software.
En la fase de implementación, céntrese en la validación del manifiesto, la aplicación de la política y el control de admisión.
Durante el el runtime, céntrese en la supervisión del comportamiento, la generación de alertas, la detección de desviaciones y la preparación para la investigación de incidentes.
Un enfoque por etapas es importante porque no todos los problemas deben abordarse en el mismo punto de control. Algunas verificaciones deberían bloquear la implementación, mientras que otras deberían activar la revisión, la corrección o la supervisión del el runtime. Los equipos con un mayor grado de madurez distinguen entre las vulneraciones que deben corregirse y los problemas de menor riesgo, para que la seguridad siga siendo aplicable sin convertirse en un cuello de botella. Un enfoque por etapas ofrece los mejores resultados cuando los equipos utilizan puntos de control de calidad para las imágenes y el código de infraestructura y, luego, los complementan con controles en el runtime y controles de cumplimiento a lo largo de todo el ciclo de vida.
¿Cómo son las buenas prácticas en las operaciones diarias?
En los entornos mejor gestionados, la seguridad de los contenedores no es una actividad aislada al final del ciclo de lanzamiento, sino una parte integral de la forma en que se desarrolla y se entrega el software. Los desarrolladores saben qué imágenes base están aprobadas, las canalizaciones de CI ejecutan controles de forma automática, los equipos de plataforma definen claramente las medidas de protección del clúster y los equipos de seguridad analizan las tendencias, las excepciones y las debilidades recurrentes, en lugar de depender únicamente de revisiones puntuales.
Ese ritmo operativo es importante porque DevSecOps funciona mejor cuando los controles son predecibles. Es mucho más probable que los equipos acepten los requisitos de seguridad cuando están integrados en las herramientas y el flujo de trabajo, en lugar de presentarse como objeciones en una etapa avanzada.
¿Qué deberían revisar los equipos periódicamente?
Los buenos programas de seguridad de los contenedores se mantienen en el tiempo; no basta con ponerlos en marcha. Los equipos deben revisar periódicamente lo siguiente:
- Qué imágenes están aprobadas y todavía en uso
- Si las vulnerabilidades antiguas se están trasladando a nuevas compilaciones
- Si las excepciones a la política aumentan con el tiempo
- Si las cuentas de servicio y los roles siguen teniendo privilegios excesivos
- Si las políticas de red siguen correspondiendo a la forma en que realmente se comunican las cargas de trabajo
- Si las alertas en el runtime generan investigaciones útiles o solo ruido
- Si el registro es suficiente para la respuesta ante incidentes y la revisión posterior al incidente.
Estos puntos de revisión ayudan a prevenir la desviación de los controles; sin ellos, incluso políticas de seguridad bien diseñadas pueden quedar desactualizadas o aplicarse de manera inconsistente.
Dónde se equivocan las organizaciones
Un error habitual consiste en desplazar la seguridad demasiado hacia el inicio del ciclo (shift-left) y asumir que el el runtime deja de ser importante. El enfoque shift-left es valioso, pero los contenedores son dinámicos y la visibilidad en el runtime sigue siendo fundamental para detectar comportamientos sospechosos, el uso indebido de privilegios y las fallas en los controles que solo se manifiestan después de la implementación.
Otro error es tratar la política de seguridad como una etapa de revisión externa, en lugar de algo integrado en el proceso de entrega. Si los desarrolladores solo se enteran de los incumplimientos al final del proceso, la corrección se vuelve más lenta y conflictiva.
Un tercer error es tratar de asegurar contenedores sin asegurar la plataforma alrededor de ellos. Los equipos de DevSecOps pueden mejorar la calidad de la imagen, pero el control de acceso a nivel de clúster, las políticas de admisión, el registro y la segmentación aún requieren una estrecha alineación con la plataforma y los equipos de seguridad.
¿Qué debe incluir una lista de verificación práctica de DevSecOps?
Una lista de verificación viable generalmente incluye lo siguiente:
- Imágenes base aprobadas y procedencia de la imagen
- Análisis de imágenes y dependencias en CI
- Detección de secretos antes de la fusión o compilación
- Manifiesto y revisión de IaC para la configuración de seguridad
- RBAC de privilegios mínimos y diseño de cuentas de servicio
- Control de admisión para las medidas de seguridad de la implementación
- Políticas de red para el aislamiento de la carga de trabajo
- Supervisión del el runtime para la actividad del contenedor y del clúster
- Registro centralizado y preparación para la investigación
- Revisión regular de políticas y excepciones y reglas desactualizadas.
Conclusión clave
La mejor práctica de seguridad de los contenedores para los equipos de DevSecOps consiste en un modelo de entrega: proteger las entradas, aplicar medidas de protección durante la implementación, supervisar el comportamiento en el runtime y mantener un ciclo de retroalimentación lo suficientemente ágil para que los equipos de ingeniería puedan corregir los problemas antes de que se conviertan en un riesgo para producción.
Agregue seguridad de contenedores a su canalización de DevSecOps
La eficacia de DevSecOps depende de los controles de seguridad que funcionan dentro del proceso de desarrollo de software. Kaspersky Container Security ayuda a los equipos a verificar las imágenes de los contenedores, detectar vulnerabilidades en los contenedores en ejecución, supervisar el consumo de recursos y las comunicaciones y automatizar las verificaciones de seguridad y cumplimiento.
Fuentes y lecturas adicionales:
- Lista de verificación de seguridad de las aplicaciones de Kubernetes
- CNCF Cloud Native Security Whitepaper (documento técnico de seguridad nativa en la nube)
- NIST SP 800-190: Guía de seguridad para contenedores de aplicaciones
- OWASP Kubernetes Top 10 OWASP Kubernetes Top 10 (lista de los diez riesgos de seguridad más críticos en entornos Kubernetes)
