Seguridad

En este tema se proporciona una descripción general descriptiva de alto nivel de la seguridad de Tanzu Kubernetes Grid.

Introducción

Tanzu Kubernetes Grid (TKG) permite una experiencia coherente que es nativa de Kubernetes en cualquier nube. Por lo tanto, los controles de seguridad también se pueden aplicar de forma coherente en todos los entornos mediante el uso de varios componentes empaquetados previamente en TKG que ayudan a lograr una mayor seguridad para los clústeres de carga de trabajo y su entorno subyacente. El modelo de responsabilidad compartida también se aplica para proteger los entornos que ejecutan clústeres aprovisionados de Tanzu Kubernetes Grid para todas las capas de la pila nativa en la nube: Código (Code), Contenedor (Container) Clúster (Cluster) y Nube (Cloud).

Este documento es un intento de compartir el estado actual de la tecnología de la seguridad de TKG. Con cada versión, VMware se compromete a mejorar la seguridad de TKG y se centra en convertir la seguridad en parte intrínseca del producto y, al mismo tiempo, mantener una experiencia de desarrollador sin problemas. Todas las recomendaciones de este documento deben tenerse en cuenta en función de la postura de seguridad y la postura de riesgo de la organización.

Los detalles de seguridad difieren entre TKG implementado con un supervisor de vSphere with Tanzu y TKG implementado con un clúster de administración independiente. La historia de seguridad de las implementaciones basadas en supervisor se incluye en la documentación de vSphere with Tanzu vinculada a continuación. En el resto de este tema se describen las implementaciones de TKG con clústeres de administración independientes.

Seguridad de un supervisor de vSphere with Tanzu

Tanzu Kubernetes Grid v2.0 en vSphere 8 con Supervisor es un módulo complementario para vSphere. Aprovecha muchas funciones de vSphere incluida la seguridad de vSphere y el SSO de vCenter. Para obtener más información sobre la seguridad de Tanzu Kubernetes Grid v2.0, consulte Seguridad de vSphere with Tanzu en la documentación de vSphere 8.

Este documento solo pertenece a la oferta de varias nubes Tanzu Kubernetes Grid. Su documentación oficial del producto y sus diferencias con otras ofertas se describen aquí.

Para obtener instrucciones de seguridad sobre otras ofertas de VMware Tanzu, consulte:

Seguridad del clúster de administración independiente

En las siguientes secciones, se describe la seguridad en TKG y en torno a TKG implementado con un clúster de administración independiente. Esto incluye los controles de seguridad disponibles para su uso integrado en el producto y las prácticas recomendadas para implementar controles de seguridad complementarios que protejan los entornos en los que se implementan clústeres de Tanzu Kubernetes Grid.

Código

Tanzu Kubernetes Grid ejecuta el código escrito por los desarrolladores de aplicaciones, implementado como pods de Kubernetes. Tanzu Kubernetes Grid está formada por componentes diferentes, muchos de los cuales son de código abierto y algunos exclusivos de VMware. Si el código de todas estas aplicaciones y componentes es seguro, mejora la posición de seguridad del entorno que ejecuta clústeres aprovisionados de Tanzu Kubernetes Grid.

Tanzu Kubernetes Grid se desarrolla de acuerdo con el proceso de ciclo de vida de desarrollo de seguridad de VMware. En concreto, se implementan las siguientes prácticas recomendadas para garantizar la seguridad del producto Tanzu Kubernetes Grid:

  • Revise el modelo de amenazas para cada cambio de diseño importante del producto.

  • Realice correcciones de prioridad alta para los hallazgos que salgan del ejercicio de modelos de amenazas.

  • Compilaciones automatizadas para todos los componentes principales de Tanzu Kubernetes Grid para compilarlos desde el código fuente.

  • Participe en la fase inicial de las correcciones de seguridad, la administración de versiones y la determinación de vulnerabilidades.

  • Para obtener el código exclusivo de VMware antes de combinarlo con la rama main:

    • Implemente revisiones de código del mismo nivel para asegurar un segundo par de ojos.

    • Ejecute un escaneo de código estático automatizado con herramientas como golint, gosec, govet.

  • Firme archivos binarios como kubectl o tanzu-cli con claves de firma VMware.

Para proteger el código de las aplicaciones en contenedor que se ejecutan en Tanzu Kubernetes Grid, los siguientes recursos pueden servir como referencia útil:

Contenedores

Se crea una instancia de los contenedores como procesos aislados de espacios de nombres de Linux, mediante el uso de imágenes empaquetadas previamente que son básicamente archivos tar de todas las dependencias de tiempo de ejecución y el binario de la aplicación para ejecutar la aplicación en contenedor. Tanzu Kubernetes Grid ejecuta estos contenedores como parte de los pods de Kubernetes. Muchos componentes de Tanzu Kubernetes Grid también se empaquetan como imágenes de contenedor y se configuran para ejecutarse como pods (a veces como daemonsets de Kubernetes o pods estáticos). Las siguientes prácticas recomendadas se implementan para proteger los contenedores de los componentes de Tanzu Kubernetes Grid:

  • Examine todas las imágenes de contenedor con el escáner de vulnerabilidades en busca de vulnerabilidades y exposiciones comunes (Common Vulnerability and Exposures, CVE) durante el push en el registro del contenedor provisional.

  • Limitar el acceso push al registro de contenedor externo al equipo de versiones de Tanzu Kubernetes Grid siguiendo el principio de privilegio mínimo.

  • Utilice un servicio administrado centralmente (LDAP) o una cuenta robot que automatice el push de imágenes de contenedor desde la plataforma provisional hasta la producción después de que se completen los criterios de versión y las pruebas correspondientes.

  • Realice una evaluación de impacto interno que documente las vulnerabilidades críticas no fijas en las imágenes del contenedor.

  • Solucione las vulnerabilidades con un impacto importante en el producto [1][2] sin esperar a la siguiente versión secundaria.

  • Actualice regularmente los componentes de Tanzu Kubernetes Grid a imágenes base más recientes para obtener correcciones de las vulnerabilidades recién identificadas.

  • Cuando sea posible, avance hacia imágenes mínimas para todos los componentes de Tanzu Kubernetes Grid y limite las distribuciones de imágenes base a un número pequeño para reducir el área de superficie de aplicación de revisiones para todas las imágenes.

Para compilar, ejecutar y consumir imágenes de contenedor de forma segura en general, los siguientes recursos son una guía útil:

Actualizaciones del SO y versiones de imagen de nodo

VMware empaqueta imágenes de sistema operativo de máquina base en versiones de Tanzu Kubernetes (TKrs), junto con versiones compatibles de Kubernetes y componentes de soporte. A continuación, Tanzu Kubernetes Grid utiliza estas versiones de sistema operativo, Kubernetes y componentes empaquetadas para crear nodos de clúster y plano de control. Consulte Versiones de Tanzu Kubernetes e imágenes de nodos personalizados para obtener más información.

Cada TKr publicado utiliza la última actualización estable y generalmente disponible de la versión del sistema operativo que empaqueta, que contiene todas las correcciones de CVE y USN actuales, desde el día en que se compila la imagen. VMware reconstruye estas imágenes de nodo (OVA de vSphere, AMI de AWS e imágenes de máquina virtual de Azure) con cada versión de Tanzu Kubernetes Grid, y posiblemente con más frecuencia. Los archivos de imagen están firmados por VMware y tienen nombres de archivo que contienen un identificador de código hash único.

Cuando se informa de una CVE crítica o de alta prioridad, VMware colabora en una solución y, cuando se publica la corrección, reconstruye todas las imágenes de nodo afectadas e imágenes base de contenedor para incluir la actualización.

Versiones compatibles con FIPS

Puede instalar y ejecutar versiones compatibles con FIPS de Tanzu Kubernetes Grid v2.1.0 y v2.1.1, en las que los componentes principales utilizan primitivos criptográficos proporcionados por una biblioteca compatible con FIPS basada en el módulo SSL BoringCrypto/Boring. Estos componentes principales incluyen componentes de Kubernetes, Containerd y CRI, complementos de CNI, CoreDNS y etcd.

Para obtener información sobre cómo instalar Tanzu Kubernetes Grid v2.1 compatible con FIPS, consulte Versiones compatibles con FIPS en la documentación de TKG v2.1.

Clústeres

Un clúster de Kubernetes está compuesto por varios componentes que actúan como un plano de control del clúster y un conjunto de componentes de soporte y nodos de trabajo que realmente ayudan a ejecutar cargas de trabajo implementadas. Hay dos tipos de clústeres en la configuración de Tanzu Kubernetes Grid: el clúster de administración y el clúster de carga de trabajo. El clúster de administración de Tanzu Kubernetes Grid aloja todos los componentes de Tanzu Kubernetes Grid que se utilizan para administrar clústeres de carga de trabajo. A continuación, los clústeres de carga de trabajo que utilizan los administradores de Tanzu Kubernetes Grid se utilizan para ejecutar realmente las aplicaciones en contenedor. La seguridad de clústeres es una responsabilidad compartida entre los administradores, los desarrolladores y los operadores del clúster de Tanzu Kubernetes Grid que ejecutan aplicaciones en clústeres aprovisionados de Tanzu Kubernetes Grid. En esta sección se enumeran los componentes incluidos con Tanzu Kubernetes Grid de forma predeterminada, lo que puede ayudar a implementar prácticas recomendadas seguras para los clústeres de carga de trabajo y de administración.

Administración de identidades y acceso

Tanzu Kubernetes Grid tiene un paquete Pinniped que permite el acceso seguro a los clústeres de Kubernetes, como se describe en Administración de identidades y acceso.

Los operadores de Tanzu Kubernetes Grid siguen siendo responsables de conceder acceso a los recursos del clúster a otros usuarios de Kubernetes a través del control de acceso integrado basado en roles. Las prácticas recomendadas para administrar identidades en clústeres aprovisionados de Tanzu Kubernetes Grid son las siguientes:

  • Limite el acceso a los recursos del clúster siguiendo el principio de privilegios mínimos.

  • Limite el acceso a los clústeres de administración al conjunto adecuado de usuarios. Por ejemplo, proporcione acceso solo a los usuarios responsables de administrar la infraestructura y los recursos de nube, pero no a los desarrolladores de aplicaciones. Esto es especialmente importante, ya que el acceso al clúster de administración inherentemente proporciona acceso a todos los clústeres de carga de trabajo.

  • Limite el acceso de administrador de clústeres para los clústeres de carga de trabajo al conjunto adecuado de usuarios. Por ejemplo, los usuarios responsables de administrar los recursos de infraestructura y plataforma de la organización, pero no de los desarrolladores de aplicaciones.

  • Con Pinniped, conéctese a un proveedor de identidad centralizado para administrar las identidades de usuario con permiso para acceder a los recursos del clúster en lugar de confiar en los archivos kubeconfig generados por el administrador.

Varios tenants

Una de las ventajas principales de Tanzu Kubernetes Grid es la capacidad de administrar todo el ciclo de vida de varios clústeres a través de un único plano de administración. Esto es importante, ya que, desde un punto de vista de varios tenants, la forma más alta de aislamiento entre cargas de trabajo que no son de confianza es posible cuando se ejecutan en clústeres de Kubernetes distintos. Estos son algunos de los valores predeterminados configurados para admitir cargas de trabajo de varios tenants en Tanzu Kubernetes Grid:

  • Los nodos no se comparten entre clústeres.

  • Los nodos se configuran para alojar solo cargas de trabajo de contenedor.

  • El plano de administración se ejecuta en su propio clúster dedicado para permitir la separación de inquietudes con los clústeres de carga de trabajo.

  • Los componentes de administración de Kubernetes, como api-server, scheduler, controller-manager, etc., se ejecutan en nodos dedicados. Además, considere la posibilidad de aplicar una regla de auditoría para detectar la implementación de pods de carga de trabajo en los nodos del plano de control.

  • La programación de pods de aplicaciones en nodos dedicados para componentes de administración (mencionados anteriormente) está desactivada a través de las manchas de nodos y las reglas de afinidad.

Para mejorar la seguridad en un entorno de varios tenants de AWS, implemente los clústeres de carga de trabajo en una cuenta de AWS que sea diferente de la utilizada para implementar el clúster de administración. Para implementar clústeres de carga de trabajo en varias cuentas de AWS, consulte Clústeres en diferentes cuentas de AWS.

Para obtener información más detallada sobre las consideraciones de diseño al implementar entornos de varios tenants, consulte Tenant de carga de trabajo.

Aislamiento de cargas de trabajo

Los requisitos de aislamiento de cargas de trabajo son únicos para cada cliente. Por lo tanto, para aislar razonablemente las cargas de trabajo entre sí con tolerancia a riesgos aceptables, se requiere un esfuerzo adicional en línea con el modelo de responsabilidad compartida. Esto incluye limitar la cantidad de contenedores que necesitan ejecutarse con privilegios más altos a una serie de espacios de nombres e implementar mecanismos de defensa en profundidad, como AppArmor y SELinux en el nivel de tiempo de ejecución, pod y nodo. En Tanzu Kubernetes Grid 1.6 y versiones posteriores, AppArmor está habilitado de forma predeterminada en las imágenes de Ubuntu 20.04.

Estas configuraciones se pueden aplicar de forma centralizada en los pods a través de Controladores de admisión de seguridad de pods.

Para los casos de uso avanzados y la administración de directivas personalizadas, en general, los siguientes recursos actúan como un buen punto de partida: OPA, control de admisión y estándares de seguridad de Pod

Protección de la comunicación entre servicios

Uno de los aspectos fundamentales de una arquitectura de microservicios es crear servicios que solo hacen una cosa. Esto permite separar las preocupaciones y permitir que los equipos se muevan más rápido. Sin embargo, esto también aumenta la necesidad de comunicarse con varios microservicios diferentes que a menudo se ejecutan en el mismo clúster en sus propios pods. Por lo tanto, deben tenerse en cuenta las siguientes prácticas recomendadas para proteger estas comunicaciones en tiempo de ejecución:

  • Directivas de red con privilegios mínimos: Antrea es el complemento CNI predeterminado que está habilitado en Tanzu Kubernetes Grid. Para obtener más información sobre cómo utilizarlo para implementar directivas de red que se puedan aplicar en función de la posición de riesgo, consulte la documentación oficial de Antrea. Para utilizar otro complemento CNI de su elección, siga esta guía: Redes de contenedor y pod

  • TLS mutuo de forma predeterminada: La implementación de esta es responsabilidad de los clientes de Tanzu Kubernetes Grid. Esto se puede implementar como parte del manifiesto de la aplicación o mediante una malla de servicio que permite que un contenedor sidecar controle la comunicación TLS para el contenedor de aplicaciones.

  • Proteger secretos: Existen varias opciones diferentes para elegir al administrar secretos en un clúster de Kubernetes. Para ver una serie rápida de opciones, consulte Administración de secretos.

Auditoría, registro y supervisión

Para garantizar la observación y el rechazo de los recursos del clúster, incluidos los pods de aplicaciones, es importante habilitar la auditoría y la supervisión de los clústeres aprovisionados de Tanzu Kubernetes Grid. Tanzu Kubernetes Grid se empaqueta con un conjunto de extensiones que permiten a los administradores habilitar esto de forma nativa. Las siguientes guías explican esto en profundidad:

  1. Registro de auditoría del sistema y servidor de API: Cómo habilitar el registro de auditoría del servidor de API, así como la auditoría de nivel del sistema (nodo) para evitar el rechazo del uso del clúster. Tanzu Kubernetes Grid incluye una directiva predeterminada para la auditoría de servidores de API. Se recomienda establecer una directiva adecuada para el daemon de auditoría a nivel de nodo a fin de garantizar que se pueda detectar la manipulación de los archivos binarios y la configuración del tiempo de ejecución del contenedor.

  2. Reenvío de registros con Fluent Bit: Cómo habilitar la recopilación centralizada de registros que puede evitar la pérdida de rechazo debido a la alteración local de los registros.

  3. Supervisión con Prometheus y Grafana: Cómo habilitar la observación de las métricas del clúster y del sistema para alertas y visualización que pueden detectar picos repentinos en el consumo de recursos debido a ataques de denegación de servicio.

Según la amenaza relevante que se describe, cualquiera de los controles anteriores o todos ellos se pueden aplicar a un clúster de Tanzu Kubernetes Grid.

Proveedores de nube

Los proveedores de nube actúan como un recurso subyacente para todos los clústeres de Kubernetes aprovisionados por Tanzu Kubernetes Grid, independientemente de si se trata de una implementación local (por ejemplo, vSphere) o una nube pública (p. ej., AWS, Azure o Google Cloud). Por lo general, proteger la infraestructura subyacente es una responsabilidad compartida entre los clientes de Tanzu Kubernetes Grid y los proveedores de nube. Estas son algunas recomendaciones para mejorar la seguridad de la nube subyacente a los clústeres aprovisionados de Tanzu Kubernetes Grid:

  • Rote o actualice las credenciales de nube con regularidad mediante esta guía (solo vSphere): Secretos del clúster de Tanzu (si automatiza la rotación, considere probarla en entornos que no sean de producción para observar y planificar cualquier interrupción que pueda causar).

  • Aplique los permisos con menos privilegios para las credenciales de nube, tal como se describe en la documentación de los proveedores AWS, Azure y vSphere. Siempre que sea posible, ejecute clústeres de carga de trabajo y administración en zonas de firewall y (VPC) independientes. Este es el ajuste predeterminado para los clústeres aprovisionados de Tanzu Kubernetes Grid.

  • El acceso a los nodos SSH, especialmente a los nodos del plano de control, debe restringirse a un pequeño conjunto de usuarios que cumplen la función de administrador de infraestructura.

  • Rara vez se debe utilizar el acceso SSH, principalmente como un procedimiento break glass como la pérdida de credenciales del clúster de administración.

  • Valide que los usuarios sin autenticar en Internet no puedan acceder a los recursos del clúster. Los clientes con tolerancia a riesgos bajos deben implementar clústeres sin exponer el puerto del servidor de API a Internet con la configuración adecuada del equilibrador de carga.

  • Aísle el entorno de Tanzu Kubernetes Grid (clústeres de administración y carga de trabajo) en VPC dedicadas o detrás de un firewall de otras cargas de trabajo de nube que no sean de Tanzu para limitar el movimiento lateral y reducir el área de superficie de ataque en caso de que un clúster se vea comprometido.

  • Aplique, pruebe y valide escenarios de recuperación ante desastres para la redundancia y la disponibilidad de varias regiones en los clústeres.

  • Implemente un plan para recuperarse de la pérdida de datos provocada por daños en los datos, ataques de ransomware o fallos naturales que provocan daños en el hardware físico.

  • Considere la posibilidad de usar la copia de seguridad y la restauración nativas de los recursos del clúster con Velero para ayudar en la planificación de la recuperación ante desastres y los escenarios de recuperación de pérdida de datos.

Estas recomendaciones se suman a las instrucciones generales sobre seguridad para cualquier proveedor de nube. Para obtener instrucciones generales sobre la seguridad de nube, consulte la documentación de seguridad oficial del proveedor de nube correspondiente.

Como conclusión, este documento proporciona una visión general sobre el estado actual de la ilustración y los controles de seguridad recomendados que se pueden aplicar a Tanzu Kubernetes Grid. Nos comprometemos a enviar Tanzu Kubernetes Grid de forma más intrínsecamente segura con cada lanzamiento, teniendo en cuenta el deseo de tener una experiencia de desarrollador sin fricciones.

Si tiene comentarios en el documento o tiene solicitudes de funciones relacionadas con la seguridad, póngase en contacto con su representante de VMware.

Referencias

Recursos dirigidos por comunidades ascendentes

Estos son algunos recursos ascendentes centrados en la seguridad basados en la comunidad (CNCF/Kubernetes):

Estándares y directrices de terceros

A continuación se muestra una lista de documentos publicados sin ningún orden de preferencia en particular de los cuerpos gubernamentales y de estándares:

check-circle-line exclamation-circle-line close-line
Scroll to top icon