Seguridad en ecosistemas Cloud Native

Desarrollo del tema

La industria tecnológica se ha inclinado hacia patrones de desarrollo y despliegue considerados "Cloud Native". Al mismo tiempo, el ecosistema de tecnologías, productos, estándares y soluciones está en constante expansión, lo que desafía a los tomadores de decisiones a mantenerse al día con diseños complejos. Mientras tanto, los patrones "Cloud Native" también han impulsado cambios en el consumo y la adopción de flujos de trabajo modernos que fomentan prácticas de seguridad integradas.

En el panorama actual, las preocupaciones de seguridad son complejas debido al enfoque en el desarrollo y despliegue rápidos. La dependencia de identificadores estáticos, como las direcciones IP de red, en un modelo de seguridad tradicional basado en perímetros es impráctica. Por lo tanto, se requiere un cambio de paradigma para proteger las aplicaciones.

Este nuevo enfoque se basa en la seguridad de las cargas de trabajo dinámicas, identificadas según atributos y metadatos (por ejemplo, labels y tags). Se adapta a los cambios constantes y asegura las cargas de trabajo para alinearse con la escala de las aplicaciones “Cloud Native”. Para lograrlo, se necesita una mayor automatización de los controles de seguridad en el ciclo de vida de la aplicación y arquitecturas de diseño seguro, como Zero Trust.

A diferencia de los enfoques tradicionales, aquí se inyecta seguridad a lo largo de todas las fases, en lugar de cerrar el ciclo de vida con intervenciones de seguridad gestionadas por separado. En resumen, el aprendizaje continuo de estos conceptos y procesos es fundamental para una aplicación segura a largo plazo. Si tienes más preguntas o necesitas más detalles, no dudes en preguntar.

¿Qué es la seguridad de Kubernetes?

Mientras que algunos equipos adoptan un enfoque centrado en el contenedor para la seguridad de Kubernetes, que se centra principalmente en asegurar imágenes de contenedores y el tiempo de ejecución del contenedor, otros optan por la "seguridad nativa de Kubernetes", que toma un enfoque más amplio, extrayendo en contexto de Kubernetes y utilizando controles incorporados de Kubernetes para implementar las mejores prácticas de seguridad basadas en el riesgo en todo el ciclo de vida del desarrollo de aplicaciones. La seguridad nativa de Kubernetes también aborda riesgos y vulnerabilidades específicas de Kubernetes, como las políticas RBAC de Kubernetes mal configuradas, los componentes del controlplane de Kubernetes inseguros y los secrets mal usados de Kubernetes.

La seguridad de Kubernetes se basa en el 4C de seguridad de Cloud Native: Cloud, Cluster, Container y Code:

• Cloud (o centro de datos corporativo): la infraestructura física subyacente es la base de la seguridad de Kubernetes. Ya sea que el clúster se base en el propio centro de datos o un proveedor de nubes, se deben observar las mejores prácticas del proveedor de nubes básico (o seguridad física).

• Cluster: asegurar un clúster Kubernetes involucra tanto los componentes configurables, como la API de Kubernetes como la seguridad de todas las aplicaciones que forman parte del clúster. Dado que la mayoría de las aplicaciones nativas en la nube están diseñadas en torno a microservicios y API, las aplicaciones son tan seguras como el link más débil en la cadena de servicios que comprenden toda la aplicación.

• Container: el diseño del contenedor, en donde se deben seguir las mejores prácticas, por ejemplo, comenzando con la base de código más pequeña posible (excluyendo bibliotecas o funciones innecesarias), evitando otorgar privilegios innecesarios a los usuarios en el contenedor y garantizar que los contenedores sean escaneados para vulnerabilidades en el tiempo de construcción.

• Code: El código presenta una superficie de ataque importante para cualquier entorno de Kubernetes. Políticas simples, como TCP Encription, utilizando TLS Handshake, no exponer puertos, escaneo y pruebas no utilizados regularmente pueden ayudar a evitar que los problemas de seguridad surjan en un entorno de producción.

¿Por qué es importante la seguridad de Kubernetes?

Kubernetes, como tecnología relativamente nueva, ha visto una gran adopción en los últimos años, pero la inversión en seguridad no siempre se ha mantenido. Combinado con una falta de conciencia de seguridad y la brecha de habilidades siempre presentes, los incidentes de seguridad pueden tener consecuencias devastadoras. Los problemas de seguridad son responsables de retrasar o ralentizar el desarrollo y la implementación de aplicaciones. Al culminar en un incidente, los problemas de seguridad de Kubernetes y contenedores también contribuyen a los ingresos o la pérdida de clientes, la terminación de los empleados e impactos adicionales en las operaciones comerciales.

Los kubernetes y la contenedores facilitan las devops más rápidas y escalables, pero también vienen con riesgos de seguridad adicionales. A medida que se implementan más contenedores, su superficie de ataque se expande y la capacidad de identificar qué contenedores tienen vulnerabilidades o configuraciones erróneas se vuelve más desafiante.

Riesgos y desafíos comunes

Kubernetes Pod-To-Pod Networking

Un beneficio importante de Kubernetes es su amplia gama de opciones de configuración de red, que controlan cómo se comunican los pods dentro de un clúster. Sin embargo, Kubernetes no restringe la comunicación de red entre POD dentro de un clúster de forma predeterminada, por lo que cada POD puede comunicarse con cualquier otro POD hasta que se asigne una política de red relevante. Esto significa que un solo POD que ha sido alterado por un mal actor puede usarse como vector para atacar a cualquier otro POD en ese clúster. Las políticas de red de Kubernetes se escriben utilizando archivos YAML. Esta es solo una de las muchas razones por las cuales la operación de las políticas de red de Kubernetes puede ser un desafío, lo que puede llevar a simplemente renunciar a la segmentación de red a favor de la velocidad.

Gestión de configuración

Las configuraciones erróneas, que a menudo son causadas por el error humano y la ausencia de escaneos de seguridad automatizados, presentan un riesgo grave para los entornos de Kubernetes y pueden provocar infracciones. Debido a la naturaleza dinámica de los contenedores, identificar configuraciones erróneas y mantener una postura de seguridad consistente puede ser un desafío. Kubernetes se desarrolló para priorizar la velocidad y la operabilidad, por lo que las configuraciones predeterminadas generalmente están abiertas/sin restricciones. Esto deja a las organizaciones susceptibles a los ataques.

Problemas de la cadena de suministro de software

Los problemas de seguridad en la cadena de suministro de software, incluidos los componentes de la aplicación vulnerables, los controles de acceso insuficientes, la falta de una factura de materiales de software (SBOM), las debilidades de la pipeline de CI/CD y la aplicación de políticas inconsistente, también son una preocupación importante para las organizaciones. Las extensas cadenas de suministro de software emblemáticas de los entornos de Kubernetes Cloud Native requieren un conjunto único de controles. La seguridad de la cadena de suministro de software debe comenzar en el entorno de desarrollador individual (IDE) y extender hasta el entorno de tiempo de ejecución. Debe tener en cuenta todo el contenido (código fuente, imágenes, artefactos), herramientas (desarrollador y seguridad) y personas involucradas en la cadena de suministro. Análisis del código fuente, control de acceso, certificación, SBOMS son solo algunas de las muchas consideraciones de seguridad para la seguridad de la cadena de suministro de software.

Shifting security left

Estrechamente relacionado con la seguridad de la cadena de suministro de software está el desafío de cambiar la seguridad a la izquierda (Shifting security left). La seguridad cambiante a la izquierda es un concepto que establece que los esfuerzos de seguridad de Kubernetes deberían pasar a las etapas anteriores del ciclo de vida del contenedor. Este es un desafío porque la seguridad de la izquierda por turnos requiere que los desarrolladores se conviertan en usuarios de seguridad, capacitados con el conocimiento y las herramientas para tomar decisiones de seguridad dentro de sus flujos de trabajo. Sin embargo, los beneficios comerciales de cambiar la seguridad a la izquierda son tremendos. Esta es la forma principal en que se deben implementar Kubernetes y Contenedores de seguridad. Cuantos más problemas de seguridad se aborden en la etapa de compilación, es probable que surjan menos problemas de tiempo de ejecución, lo que lleva a menos retrasos en los proyectos.

Detección y respuesta en tiempo de ejecución

El volumen de vectores de amenazas de tiempo de ejecución en aplicaciones contenedores que se ejecutan en un entorno de Kubernetes plantean un desafío para los equipos encargados de detectar y responder a tales problemas. Hay muchas maneras para que un mal actor obtenga acceso inicial a un entorno de Kubernetes, ejecute código malicioso, aumente el privilegio, logre la perseguencia, evite la detección y se mueva lateralmente, lo que resulta en la eliminación de datos o la exfiltración, la negación del servicio o el secuestro de recursos.

Seguridad de infraestructura de Kubernetes

Las muchas capas de Kubernetes, desde los componentes del controlplane, como el API Server, Kube-Scheduler, Kube-Controller-Manager, ETCD, hasta los componentes del worker node que ejecutan las cargas de trabajo contenidas, posponen sus propios desafíos de seguridad. Cada uno de estos servicios debe configurarse de forma segura para proporcionar un entorno de clúster endurecido para que las aplicaciones se ejecuten. Además de eso, ya sea que esté ejecutando Kubernetes como un servicio autogestionado o que utilice un servicio en la nube completamente administrado cambiará la forma en que debe asegurar los diversos componentes de Kubernetes. En entornos autogestionados, por ejemplo, la totalidad de los componentes del controlplane es a menudo su responsabilidad, además de los componentes del nodo. Cuando utiliza un servicio de Kubernetes administrado, la responsabilidad de seguridad se comparte entre el proveedor de servicios y usted, el cliente. Esto agrega otro desafío.