Treo Blog

En este espacio puedes explorar las últimas tendencias y noticias en tecnología, seguridad informática e infraestructura TI.

  • Jonathan Rodriguez Paipa

Arquitectura de Kubernetes y lo que significa para la seguridad

Por: Wei Lien Dang



Crédito: Pexels

Kubernetes es un sistema de infraestructura robusto pero complejo para la orquestación de contenedores, con múltiples componentes que deben protegerse adecuadamente. Para saber cómo proteger de forma más eficaz sus entornos de Kubernetes, es importante comprender la arquitectura de Kubernetes en sí, así como dónde y cómo centrar los esfuerzos en mitigaciones valiosas.














Cada clúster de Kubernetes consta de dos conjuntos de componentes:

  1. El plano de control, que se utiliza para gestionar las operaciones en todo el clúster, y

  2. Los nodos trabajadores del clúster, que ejecutan aplicaciones en contenedores en pods. Además, para lograr una alta disponibilidad y resistencia, especialmente para entornos de clústeres de producción, ambos conjuntos de componentes se pueden implementar en varias máquinas que forman un clúster.

Componentes del plano de control de Kubernetes


Teniendo en cuenta que el plano de control de Kubernetes está diseñado para tomar decisiones globales con respecto a las operaciones de un clúster, el compromiso de los componentes del plano de control podría fácilmente resultar en un compromiso completo de un clúster. Por lo tanto, un punto de partida fundamental para cualquier esfuerzo por proteger Kubernetes es centrarse inicialmente en proteger sus servicios de plano de control.


El plano de control de Kubernetes incluye los componentes que se enumeran a continuación, junto con los pasos recomendados que puede seguir para aumentar la seguridad de cada componente.


Servidor de API de Kubernetes (kube-apiserver)


Este es el componente del plano de control central que expone la API de Kubernetes y recibe y valida las solicitudes de la interfaz de programación de aplicaciones (API) para la creación y modificación de recursos. Sirve como la interfaz principal para las comunicaciones del clúster, ya que es el único componente del clúster con el que todos los componentes del trabajador y del plano de control pueden comunicarse directamente.


Se han revelado y se siguen divulgando varias vulnerabilidades que afectan al servidor de la API de Kubernetes. Además de tomar medidas para mitigar estas vulnerabilidades mediante la actualización de las versiones de Kubernetes o la aplicación de parches de seguridad, restringir el acceso a la API de Kubernetes es clave para proteger los clústeres. Esto se puede hacer mediante:


  • Configurar la autenticación para todos los clientes de la API de Kubernetes.

  • Configurar la autorización que determina los permisos sobre quién puede hacer qué, mediante el control de acceso basado en roles (RBAC) de Kubernetes.

  • Asegurarse de que todo el tráfico de la API esté cifrado con TLS.

El registro de auditoría en Kubernetes también debe estar habilitado para garantizar que los eventos de la API se registren para su posterior análisis o investigación, según se justifique.


etcd


Este componente del plano de control es el almacén de valor clave que Kubernetes usa para almacenar datos del clúster, incluidos los objetos y las configuraciones de la API.


Los datos almacenados en etcd deben protegerse adecuadamente mediante cifrado y control de acceso, ya que obtener visibilidad de estos datos puede revelar detalles importantes sobre su entorno, incluidas sus aplicaciones en contenedores.


Kubernetes admite el cifrado en el resto de datos confidenciales, como secretos, que deben estar habilitados. Además, se deben habilitar fuertes controles de autenticación y acceso para limitar el acceso de lectura y escritura al almacén de datos; el acceso de escritura a etcd otorga privilegios completos en todo el clúster.


ser un programador


Este es el componente del plano de control que maneja la programación de pods en los nodos trabajadores en función de la disponibilidad de recursos, los requisitos y la asignación, la afinidad / antiafinidad, las solicitudes de taints / toleraciones y otras restricciones de políticas.


Los permisos de archivo en la especificación del pod del programador kube y los archivos kubeconfig deben estar restringidos, y el servicio debe configurarse para que solo sirva HTTPS. Además, el servicio debe estar vinculado a una interfaz de host local, ya que expone información de salud y métricas que, de forma predeterminada, no requieren autenticación ni cifrado. La comunicación con el servidor API debe realizarse mediante el puerto seguro, además de requerir controles de autenticación y autorización.


administrador del controlador de cubo


Este componente del plano de control ejecuta procesos que regulan, mantienen y ajustan el estado de cosas como nodos, réplicas de pod, servicios y cuentas de servicios y tokens de acceso.


Los permisos de archivo en la especificación del pod kube-controller-manager y los archivos kubeconfig deben estar restringidos, y el servicio debe configurarse para que solo sirva HTTPS. También debería estar vinculado a una interfaz localhost. También debe asegurarse de que se configure una credencial de cuenta de servicio individual por controlador junto con Kubernetes RBAC para garantizar que los lazos de control se ejecuten con los permisos mínimos requeridos. La comunicación con el servidor API debe realizarse mediante el puerto seguro, además de requerir controles de autenticación y autorización.


administrador-controlador-en-la-nube


Este componente del plano de control ejecuta procesos que administran las dependencias del clúster en entornos de proveedores de nube para funciones como la terminación de nodos, la configuración de rutas y el equilibrio de carga.


Los permisos de archivo en la especificación del pod kube-controller-manager y los archivos kubeconfig deben estar restringidos, y el servicio debe configurarse para que solo sirva HTTPS. También debe asegurarse de que se configure una credencial de cuenta de servicio individual por controlador junto con Kubernetes RBAC para garantizar que los bucles de control se ejecuten con los permisos mínimos requeridos. La comunicación con el servidor API debe implementarse utilizando el puerto seguro, además de requerir controles para la autenticación y autorización.


Componentes del nodo de Kubernetes


Cada nodo de Kubernetes ejecuta los siguientes componentes:


kubelet


Este componente de nodo es el agente de nodo principal que administra los contenedores individuales que se ejecutan en pods y su estado según las PodSpecs pasadas a través del servidor API de Kubernetes o como un archivo con la herramienta de línea de comandos kubectl.


Las vulnerabilidades relacionadas con kubelet se han revelado y se siguen divulgando; estas deben abordarse actualizando las versiones de kubelet, aplicando parches disponibles y / o tomando medidas para mitigar el vector de amenaza particular.


Es necesario limitar el acceso al kubelet con autenticación y autorización sólidas porque sus puntos finales HTTPS exponen API que otorgan ciertos privilegios en el nodo y los contenedores. De forma predeterminada, el acceso no está autenticado.


proxy de kube


Este componente de nodo es un proxy de red que maneja el reenvío de solicitudes según las reglas de la red y admite varios protocolos de red (TCP, UDP, etc.). Permite que los servicios de Kubernetes se expongan externamente.


Si kube-proxy está usando un archivo kubeconfig basado en archivos, entonces los permisos del archivo deben restringirse. Además, la comunicación con el servidor API debe realizarse usando el puerto seguro, además de requerir controles de autenticación y autorización.


Tiempo de ejecución del contenedor


Este componente habilita la funcionalidad necesaria para iniciar, ejecutar y administrar contenedores en un nodo determinado, como comunicarse con el kernel, configurar cgroups, etc. Algunos ejemplos de tiempos de ejecución admitidos por Kubernetes incluyen Docker, CRI-O y containerd.


El tiempo de ejecución del contenedor es lo que ejecuta los contenedores y, por lo tanto, se deben tomar los pasos adecuados y las mejores prácticas de seguridad para fortalecerlo. Consulte el blog de OpenShift para obtener recomendaciones sobre cómo reforzar los contenedores de Docker.


Cómo Red Hat Advanced Cluster Security para Kubernetes ayuda a proteger los componentes de Kubernetes


Si sigue las recomendaciones descritas anteriormente, puede ayudar a mitigar la mayoría de los problemas de seguridad que pueden surgir con Kubernetes. Sin embargo, también puede ser un desafío dada la cantidad de componentes clave de Kubernetes que existen y los diversos controles que deben implementarse.


Red Hat Advanced Cluster Security proporciona una serie de capacidades que automatizan DevSecOps para Kubernetes. Ofrece una visibilidad de red completa del plano de control y los componentes del nodo, incluidas las comunicaciones entre ellos y con servicios adicionales en todo el clúster. Identifica y prioriza las vulnerabilidades conocidas en el propio sistema Kubernetes para agilizar la corrección. Supervisa los permisos autorizados a través de Kubernetes RBAC y aplica políticas integradas para detectar infracciones relacionadas con las imágenes o las implementaciones de pod para estos componentes.


Finalmente, permite el monitoreo en tiempo de ejecución de la actividad a nivel del sistema para los pods que se ejecutan en el espacio de nombres del sistema kube para detectar eventos anómalos y maliciosos. Si está interesado en obtener más información, solicite una demostración.


Conclusión


Un aspecto fundamental para proteger sus aplicaciones de Kubernetes es centrarse en proteger los componentes que conforman la plataforma de infraestructura de Kubernetes en su conjunto. Esto se puede hacer al comprender esos componentes y tomar medidas para protegerlos de vulnerabilidades, configuraciones incorrectas y ataques en tiempo de ejecución. Al hacerlo, puede aumentar de inmediato la seguridad de sus clústeres de Kubernetes y permitir que su organización escale el uso de Kubernetes en producción con confianza.


Fuente: Blog Red Hat

2 vistas0 comentarios

Entradas Recientes

Ver todo