¿Qué es la seguridad de Kubernetes?

La importancia de la seguridad de Kubernetes

Como plataforma principal para orquestar aplicaciones contenedorizadas tanto en entornos nube públicos como privados, Kubernetes se convirtió en un objetivo principal para los ciberdelincuentes. Kubernetes está en el corazón de los flujos de trabajo modernos de DevOps , permitiendo a los equipos automatizar y escalar la implementación de aplicaciones sin preocupar por la infraestructura subyacente ni por las complejidades de la gestión de recursos. 

Sin embargo, Kubernetescomplejidad también significa que es fácil introducir y pasar por alto vulnerabilidades o configuraciones erróneas que podrían exponer aplicaciones críticas para el negocio. Si Kubernetes no está debidamente cerciorado, los atacantes pueden comprometer cargas de trabajo críticas, exfiltrar datos sensibles o incluso derribar servicios esenciales.

Por lo tanto, las organizaciones necesitan prácticas de seguridad Kubernetes que protejan la plataforma y sus componentes fundamentales:

• Agrupación: El entorno general que contiene todos los componentes de Kubernetes. Consiste en un plano de control que gestiona el clúster y un conjunto de nodos trabajadores donde realmente se ejecuta la aplicación.
• Nodes: Máquinas, virtuales o físicas, que ejecutan cargas de trabajo contenedorizadas. Cada nodo incluye un kubelet que se comunica con el plano de control, un kube-proxy que gestiona las reglas de red y un tiempo de ejecución de contenedores.
• Cápsulas: Los nodos ejecutan las cargas de trabajo empaquetadas en pods, la unidad desplegable más pequeña en Kubernetes que encapsula uno o más contenedores compartiendo almacenamiento, espacio de nombres de red y configuración.
• Componentes del plano de control: Gestiona el estado y las operaciones del clúster. Sus componentes clave incluyen el servidor API y un planificador que asigna pods a los nodos.

También conocida como k8s Security, la seguridad de Kubernetes abarca una amplia gama de medidas de seguridad diseñadas para proteger estos componentes. Para lograrlo, las organizaciones deben adoptar una estrategia de seguridad proactiva y multinivel para monitorizar continuamente las amenazas Kubernetes , mitigar ataques y garantizar el cumplimiento de las normas regulatorias. Con Kubernetes convertir en la base de la mayoría de la infraestructura en la nube, garantizar su seguridad es una necesidad para la continuidad y el éxito del negocio.

Seguridad de Kubernetes para cada fase del ciclo de vida de la aplicación

Para garantizar una seguridad robusta en k8s, es fundamental abordar las preocupaciones de seguridad en cada fase del ciclo de vida de la aplicación. La seguridad no es solo una consideración posterior a la implementación; Debe integrar en cada etapa del proceso de desarrollo. 

A continuación, desglosamos las medidas de seguridad esenciales para cada fase:

#1. Fase de desarrollo

La fase de desarrollo y diseño es la primera línea de defensa en la seguridad de Kubernetes. En esta etapa, los desarrolladores deben centrar en crear aplicaciones y arquitectura seguras que puedan resistir posibles ataques. Esto implica proteger la integridad del entorno de desarrollo, diseñar aplicaciones pensando en la seguridad desde el principio e implementar prácticas de codificación segura. 

Las principales medidas de seguridad a considerar incluyen:

• Adoptar una arquitectura de confianza cero para validar cada solicitud de acceso.
• Desarrolla un proceso de revisión de código y cerciórate de que el código de la aplicación esté libre de vulnerabilidades.
• Hacer cumplir los procesos de gestión de secretos seguros para manejar adecuadamente datos sensibles (contraseñas, claves API, tokens OAuth, etc.).

#2. Fase de distribución

Durante la fase de distribución, debes revisar la cadena de suministro de la aplicación, cerciorándote de que las imágenes y otros componentes estén seguros y actualizados, libres de vulnerabilidades conocidas. 

To achieve this, you should:

• Escanea todas las imágenes del contenedor en busca de vulnerabilidades.
• Restringir el acceso a las imágenes del contenedor para evitar accesos y manipulaciones no autorizadas.
• Actualice todas las dependencias y desarrolle procesos de gestión de parches para obtener nuevas actualizaciones lo más rápido posible.

#3. Fase de implementación

La fase de implementación es cuando la aplicación se introduce en el clúster Kubernetes . Garantizar la seguridad durante esta fase implica configurar el entorno Kubernetes de forma segura y gestionar el proceso de implementación para minimizar el riesgo de exponer vulnerabilidades. 

Las prácticas de implementación segura a considerar incluyen:

• Restringir la implementación de aplicaciones a usuarios y entornos específicos.
• Escanear imágenes de contenedores para verificar la identidad criptográfica y comprobar que la firma es válida, de un editor de confianza y que el artefacto no fue alterado.
• Despliega la aplicación y el clúster en espacios de nombres separados.

#4. Fase de ejecución

Seguridad en tiempo de ejecución de Kubernetes se centra en la fase operativa, donde la aplicación se ejecuta dentro del clúster. La fase de ejecución requiere capacidades continuas de monitorización y respuesta a incidentes para limitar el impacto de los incidentes de seguridad, así como actualizaciones continuas para mantener el entorno seguro. 

Se puede dividir en tres áreas principales:

• Acceso: Proteger la API de Kubernetes con un control de acceso robusto, procesos de autenticación y cifrado de todo el tráfico de la API.
• Calcular: Elige un entorno de ejecución de contenedor que proporcione un alto nivel de seguridad y que encuentre un equilibrio entre aislar la aplicación mientras se ejecuta en el mismo host.
• Almacenamiento: Cifra clústeres y objetos API en reposo, autentica conexiones entre clústeres y almacenamiento, y emplea copias de seguridad para poder restaurarlas si es necesario.

Las 4C de Kubernetes Security

Para proteger eficazmente Kubernetes frente a amenazas, aborda la seguridad desde la perspectiva del modelo 4Cs. El modelo 4Cs es de código, contenedores, clústeres y seguridad en la nube , y es una hoja de ruta para abordar las preocupaciones de seguridad dentro de la arquitectura Kubernetes.

Seguridad del código

El código se refiere a la aplicación ejecutada por contenedores. El código presenta una superficie de ataque significativa en entornos Kubernetes , no solo por la introducción accidental de errores que resultan en vulnerabilidad, sino también por bibliotecas potencialmente vulnerables de terceros.

Para cerciorar el código que se ejecuta en la plataforma Kubernetes, comienza evitando el acceso no autorizado al código, teniendo como primera línea de defensa la seguridad básica de la red y los controles de acceso. Implementar prácticas de codificación seguras, realizar escaneos y pruebas regulares con herramientas dedicadas y cumplir con las directrices de codificación de OWASP .

Seguridad de contenedores

Los contenedores contienen imágenes, que a su vez consisten en la imagen base, el sistema operativo, la configuración del contenedor, las dependencias y el tiempo de ejecución necesarios para ejecutar el código de la aplicación.

Los contenedores que se ejecutan en pods deben usar imágenes base y entornos de ejecución fiables, cada uno de los cuales puede ser objetivo de actores maliciosos. Verificar que el repositorio de imágenes originado es seguro, minimizar la base de código para limitar el número de bibliotecas de terceros en uso, escanear imágenes del contenedor en busca de vulnerabilidades y proteger pods con controles de acceso y políticas rojas para restringir la comunicación entre pods.

Seguridad de clústeres

La arquitectura de Kubernetes está organizada en clústeres. Los clústeres Kubernetes consisten en pods, y cada pod contiene uno o más contenedores que operan en la misma red local. El diseño de la seguridad del clúster depende de un cuidadoso diseño de políticas de acceso y configuraciones de seguridad.

La seguridad del clúster implica cerciorar contenedores y aplicaciones que se ejecutan dentro, el plano de control (el API, el planificador, el almacén de datos y los controladores), y el rojo más amplio en el que se ejecuta el clúster.

Seguridad en la nube

La capa de nube es el centro de datos físico o infraestructura en la nube que ejecuta Kubernetes, comúnmente plataformas de infraestructura como código (IaC) o servicios gestionados de Kubernetes.

Los proveedores de nube ofrecen directrices y mejores prácticas de seguridad para implementar controles de acceso adecuados. Reducir los riesgos para la infraestructura nube implementando procedimientos de privilegio mínimo en los recursos, escaneando vulnerabilidades o configuraciones erróneas de nube y controles de acceso para restringir con qué usuarios pueden interactuar Kubernetes.

Generalmente, los administradores pueden esperar implementar medidas de seguridad en todas las etapas del ciclo de vida de la aplicación: desde la codificación y pruebas iniciales, la implementación en producción y las operaciones continuas dentro del clúster.

Principios clave para la seguridad de Kubernetes

Los siguientes principios y contramedidas de seguridad pueden ayudar a garantizar la resiliencia de las aplicaciones contenedorizadas que se ejecutan en Kubernetes:

Role-Based Access Control (RBAC)

En Kubernetes, RBAC controla el acceso a los recursos dentro del clúster y define las acciones que un usuario o grupo puede o no puede realizar. RBAC se emplea para aislar el acceso del equipo, restringir operaciones, controlar el acceso de administrador y gestionar licencias de cuentas de servicio.

Los roles se emplean para conceder acceso a recursos dentro de un único espacio de nombres, mientras que los roles de clúster son más amplios y definen el acceso entre espacios de nombres. Está claro que no todos los usuarios deberían tener acceso completo e irrestricto a todos los recursos. Al evaluar los roles y licencias de Kubernetes, consulte el principio de menor privilegio (PoLP) como una guía general.

Al usar RBAC, los administradores deberían tender a preferir licencias específicas de espacio de nombres en lugar de licencias a nivel de clúster, especificando controles de acceso para cada objeto y espacio de nombres Kubernetes. Permite el acceso solo cuando sea necesario para tareas específicas, y nada más.

Aplicación de las políticas rojas

Los contenedores se comunican con servicios externos y entre sí a través de la red. Las aplicaciones contenedorizadas suelen usar ampliamente el rojo en clúster. Para comprender mejor cómo interactúan las aplicaciones con otros sistemas e identificar comunicaciones anómalas, implementa monitorización del tráfico rojo activo y compáralo con el tráfico permitido por Kubernetes política roja.

Para cerciorar la conectividad de red, las organizaciones deben aplicar políticas de red que limiten la comunicación a los servicios necesarios, prefiriendo el mínimo necesario para que las cargas de trabajo funcionen correctamente. Esta recomendación se aplica tanto al tráfico entrante como al saliente hacia el clúster, y al tráfico dentro del clúster.

Cifra el tráfico rojo usando red privado virtual (VPNs) y TLS. Para mejorar la seguridad de los contenedores, despliega firewall dentro del entorno para agregar otra capa protectora, e implementa segmentación de red y aislamiento de recursos para reducir la superficie de ataque y contener brechas.

Hacer cumplir la Entrada de Seguridad en Cápsulas (PSA)

PSA, sucesora de la Política de Seguridad de Pods (PSP), aplica políticas de seguridad conocidas como Estándares de Seguridad de Pods (PSS) dentro de Kubernetes. Como característica integrada, PSA elimina la necesidad de herramientas de terceros, simplificando la seguridad al definir y cumplir con un conjunto de estándares. Impone restricciones a configuraciones inseguras, reduciendo la superficie de ataque.

El PSS aplicado por Pod Security Admission define tres perfiles de seguridad para cargas de trabajo. El perfil Privilegiado no aplica restricciones y no debe usar salvo que sea absolutamente necesario. El perfil Baseline proporciona un nivel mínimo de seguridad para la aplicación, mientras que Restringido aplica las mejores prácticas de seguridad.

PSA verifica que los pods estén configurados según estos perfiles, haciendo cumplir el cumplimiento. En general, los administradores deberían establecer la política de Línea Base o Restringida para los pods para garantizar la seguridad del clúster.

Cerciorar el plano de control

El plano de control Kubernetes es responsable de controlar el clúster. Gestiona el estado del clúster, la salud y los datos de configuración, cerciorando que los contenedores funcionen con todos los recursos necesarios. Debido a su importancia y complejidad, el plano de control se considera algo difícil de configurar y, en consecuencia, se convirtió en un objetivo principal para los atacantes.

El plano de control consta de los siguientes componentes:

• etcd: La base de datos clave-valor etcd almacena información de configuración y datos del estado del clúster. Cerciórate de que etcd tenga el cifrado activado, que la comunicación esté restringida al servidor API salvo que sea absolutamente necesario, y que los clientes empleen autenticación basada en certificados.
• kube-controller-manager: El daemon del Gestor de Controladores ejecuta clústeres y controla sus funciones. Cerciorar el Gestor de Controladores implica restringir el acceso a la red, implementar TLS para todo el tráfico de la API, limitar el uso de recursos en el clúster y minimizar los privilegios empleados por los contenedores.
• Planificador de Kube: El Planificador gestiona y aprovisiona nuevos contenedores. Los pasos de seguridad incluyen desactivar su capacidad de perfilado para reducir su superficie de ataque y verificar que la dirección IP del Scheduler no esté vinculada a una IP insegura.
• kube-apiserver: El API Server actúa como frontend, gestionando solicitudes internas y externas. En resumen, cerciorar el servidor API restringiendo el acceso mediante IPs externos, aplicando mecanismos de autenticación fuertes y aplicando TLS cifrado. Consulte la sección "Cerciorar la API de Kubernetes" más abajo para más detalles.

Cerciorar el servidor API de Kubernetes

Los usuarios externos acceden al plano de control de Kubernetes a través de la API, por lo que garantizar su seguridad y limitar el acceso a usuarios no autorizados es extremadamente importante.

Para proteger el Kubernetes API, comienza regulando las solicitudes dirigidas al servidor para cerciorarte de que las solicitudes API no autorizadas no accedan con éxito al clúster. Considera usar proveedores de autenticación de terceros, que habilitarán la autenticación de múltiples factores (MFA). Emplea conectores OAuth 2.0 o proveedores OpenID Connect (OIDC) para cerciorar el acceso al clúster.

Limitar el acceso a red público e implementar un cifrado de Seguridad de Capa de Transporte (TLS) para los datos en tránsito a través del servidor API . También confirma que el almacén de datos de Kubernetes, etcd, que se comunica directamente con el servidor API, está debidamente protegido.

Escaneo de seguridad de imágenes

Las imágenes forman la base de los grupos y cápsulas creadas. Estas imágenes deben ser escaneadas de manera regular para detectar vulnerabilidades de seguridad, cerciorando que los contenedores creados a partir de ellas no hereden las vulnerabilidades de seguridad de la imagen.

Las herramientas de escaneo de imágenes pueden emplear para identificar vulnerabilidades en la imagen base sobre la que se construyen los contenedores y para aplicaciones para bibliotecas incluidas dentro de las imágenes de contenedores. Esto se hace escaneando la imagen base y todos los paquetes frente a una base de datos de vulnerabilidad.

Cerciorar de que el acceso a los registros de imágenes esté restringido para evitar manipulaciones y escanee todas las imágenes durante las etapas de integración continua/implementación continua (CI/CD ). Agregar escaneo en la tubería CI/CD ayuda a garantizar que los contenedores estén correctamente configurados, actualizados y libres de malware.

Cifrar secretos y comunicación

Los secretos son una forma de información sensible. En Kubernetes, los secretos más comunes suelen ser contraseñas, tokens OAuth, claves SSH u otras credenciales. Los secretos almacenados en texto claro —en archivos de configuración YAML, imágenes de contenedores o dentro de documentos en contenedores— representan un riesgo crítico y ponen en peligro la seguridad de todo el clúster.

Kubernetes ofrece un objeto integrado, el Kubernetes Secret, para almacenar estos datos de forma segura. Empleando objetos secretos, los administradores pueden separar información confidencial del código de la aplicación.

Como Kubernetes Secrets gestiona información privilegiada, suelen ser objetivo de hackers. Los secretos deben cifrar en reposo, y el acceso a ellos debe restringir solo a los componentes y usuarios que los requieran. Implementar prácticas o sistemas de escaneo secreto para identificar y remediar la exposición secreta accidental.

Exposición límite del nodo

Los nodos Kubernetes se dividen en dos tipos principales: nodos maestros y nodos trabajadores. Los nodos maestros ejecutan los servicios básicos del clúster, incluyendo el servidor API, el planificador, el controlador y el almacén de datos etcd. Los nodos de trabajo ejecutan la aplicación dentro del clúster.

Kubernetes clústeres están compuestos por nodos que ejecutan sistemas operativos Linux o Windows (SO). Muchas técnicas de endurecimiento que generalmente se aplican a estos SO son válidas en el contexto de Kubernetes nodos:

• Instala solo la aplicación y las librerías necesarias para que el clúster funcione correctamente, y nada más.
• Restringir el acceso a cuentas administrativas o root, usándolas solo cuando sea necesario.
• Despliega herramientas de monitorización en tiempo real para detectar brechas de seguridad en curso.
• Los nodos Linux pueden reforzar con herramientas como SELinux o AppArmor.

Además, el Centro de Seguridad de Internet (CIS) proporciona un conjunto de puntos de referencia de seguridad tanto para los nodos maestros como para los trabajadores. Al emplear una herramienta como Kube-bench, los administradores pueden escanear sus clústeres y evaluarlos en comparación con los puntos de referencia de CIS. Estos análisis suelen proporcionar recomendaciones para corregir configuraciones que no se ajustan a las mejores prácticas de CIS.

Habilitar registros de auditoría

Los registros de auditoría son importantes para mantener tanto las operaciones como la seguridad. Estos registros ofrecen información útil sobre la actividad del clúster y permiten la detección rápida de actividad anómala. Aunque Kubernetes incluye capacidades de registro de auditoría como función integrada, no están activadas por defecto. Al activar, todas las acciones se registran dentro del clúster.

Los administradores de clúster deben configurar una política de auditoría que defina los eventos a registrar y herramientas externas para el almacenamiento, gestión y análisis de esos registros. Esto garantiza que los problemas de seguridad se detecten rápidamente, al tiempo que proporciona la información necesaria para que los equipos de respuesta a incidentes (IR) investiguen cualquier brecha que ocurra.

Ejecutar cargas de trabajo con privilegios mínimos

Las cargas de trabajo de Kubernetes pueden ser complejas y difíciles de cerciorar adecuadamente. Las cargas de trabajo son dinámicas, transitando entre entornos locales y en la nube, cada uno con sus propios controles de seguridad de red. Además, los procesos automatizados CI/CD suelen desplegar nuevos servicios o nuevas versiones en nodos del clúster, intensificando la complejidad.

En general, los administradores nunca deberían confiar en las cargas de trabajo. Aplicar políticas de seguridad detalladas para restringir la comunicación entre cargas de trabajo y aplicaciones de terceros. Esto reduce la probabilidad de movimiento lateral de las amenazas y ayuda a mantener el cumplimiento.

Las definiciones de seguridad RED deberían integrar en las cargas de trabajo, cerciorando que sean portátiles entre distribuciones Kubernetes y Centro de Datos. De este modo, dondequiera que se ejecute la carga de trabajo, lleva consigo las definiciones de seguridad.

Por último, configura herramientas de seguridad perimetral para monitorizar continuamente las direcciones IP y puertos empleados por las cargas de trabajo, permitiendo la identificación en tiempo real de comportamientos sospechosos.