Debido a la velocidad de desarrollo de Kubernetes, a menudo hay nuevas funciones de seguridad que puedes usar. En este documento se describe cómo proteger tus clústeres de Google Distributed Cloud.
En este documento se priorizan las mitigaciones de seguridad de gran valor que requieren tu intervención durante la creación del clúster. Las funciones menos importantes, los ajustes seguros de forma predeterminada y los que se pueden habilitar después de crear el clúster se mencionan más adelante en el documento. Para obtener una descripción general de los temas de seguridad, consulta Seguridad.
Lista de comprobación
En la siguiente lista de comprobación de despliegue se destacan las prácticas recomendadas para reforzar el despliegue de la plataforma de tus clústeres de GKE. Para obtener más información sobre cada práctica, consulta las secciones de este documento.
| Lista de comprobación de la implementación | Descripción |
|---|---|
| Control de identidades y accesos | Usar privilegios de cuenta de vSphere: Protege Google Cloud las cuentas de servicio: Configurar OpenID Connect (OIDC): Usa espacios de nombres de Kubernetes y RBAC para restringir el acceso: |
| Protección de datos | Cifrar máquinas virtuales de vSphere: Gestionar secretos: |
| Protección de la red | Restringe el acceso a la red del plano de control y los nodos: Usa políticas de red para restringir el tráfico: |
| Seguridad declarativa | Usa Policy Controller: |
| Mantenimiento | Actualizaciones: Monitoriza los boletines de seguridad: |
| Monitorización y registros | Configura las opciones de registro: |
Control de identidades y accesos
En esta sección se proporciona información sobre cómo controlar el acceso a los clústeres.
Usar privilegios de cuenta de vSphere
La cuenta de usuario de vCenter que utilices para instalar Google Distributed Cloud debe tener los privilegios suficientes. Por ejemplo, una cuenta de usuario a la que se le ha asignado el rol de administrador de vCenter tiene privilegios para acceder por completo a todos los objetos de vCenter y proporciona acceso completo a un administrador de clúster de Google Distributed Cloud.
Se recomienda aplicar el principio de mínimos accesos, concediendo solo los privilegios necesarios para instalar {product_name} correctamente. Hemos predefinido el conjunto mínimo de privilegios necesarios para realizar la instalación, así como los comandos necesarios para conceder estos permisos.
Proteger las cuentas de servicio de Google Cloud
Google Distributed Cloud requiere varias Google Cloud cuentas de servicio. Durante la instalación, debes enlazar roles de Gestión de Identidades y Accesos con estas cuentas de servicio. Estos roles conceden a las cuentas de servicio privilegios específicos en tu proyecto. Algunas de las cuentas de servicio se pueden generar durante la instalación.
Configurar la autenticación de los usuarios del clúster
Para configurar la autenticación de usuarios en tu clúster, puedes usar OpenID Connect (OIDC) o Lightweight Directory Access Protocol (LDAP).
Para obtener más información, consulta Servicio de identidad de GKE.
Usar espacios de nombres de Kubernetes y RBAC para restringir el acceso
Para dar a los equipos acceso con los mínimos privilegios a Kubernetes, crea espacios de nombres de Kubernetes o clústeres específicos del entorno. Asigna centros de costes y etiquetas adecuadas a cada espacio de nombres para rendir cuentas y hacer devoluciones de cargos. Solo debes dar a los desarrolladores el nivel de acceso a sus espacios de nombres que necesiten para desplegar y gestionar sus aplicaciones, sobre todo en producción.
Asigna las tareas que deben completar los usuarios en el clúster y define los permisos necesarios para completar cada tarea. Para conceder permisos a nivel de clúster y de espacio de nombres, usa el RBAC de Kubernetes.
Además de los permisos de las Google Cloud cuentas de servicio que se usan para instalar Google Distributed Cloud, IAM no se aplica a los clústeres de Google Distributed Cloud.
Para obtener más información, consulta la siguiente documentación:
- Cuentas de servicio y claves
- Descripción general de la instalación
- Privilegios de la cuenta de usuario de vCenter
Protección de datos
En esta sección se ofrece información sobre cómo proteger tus datos.
Cifrar máquinas virtuales de vSphere
Los nodos de clúster de Google Distributed Cloud se ejecutan en máquinas virtuales (VMs) de tu clúster de vSphere. Google recomienda encarecidamente que cifre todos los datos en reposo. Para hacerlo en vSphere, sigue la guía de configuración y protección de seguridad de VMware vSphere 7 y las prácticas recomendadas para cifrar máquinas virtuales.
Esto debe hacerse antes de instalar Google Distributed Cloud.
Gestionar secretos
Para proporcionar una capa adicional de protección a los datos sensibles, como los secretos de Kubernetes almacenados en etcd, configura un gestor de secretos integrado con los clústeres de Google Distributed Cloud.
Si ejecutas cargas de trabajo en varios entornos, puede que prefieras una solución que funcione tanto en Google Kubernetes Engine como en Google Distributed Cloud. Si decides usar un gestor de secretos externo, como HashiCorp Vault, configúralo antes de integrar tus clústeres de Google Distributed Cloud.
Tienes varias opciones para gestionar los secretos:
- Puedes usar los secretos de Kubernetes de forma nativa en Google Distributed Cloud. Esperamos que los clústeres usen el cifrado de vSphere para las VMs, tal como se ha descrito anteriormente, lo que proporciona una protección básica de cifrado en reposo para los secretos. Los secretos no se cifran más de forma predeterminada.
- Puedes usar un gestor de secretos externo, como HashiCorp Vault. Puedes autenticarte en HashiCorp mediante una cuenta de servicio de Kubernetes o una Google Cloud cuenta de servicio.
Protección de la red
En esta sección se proporciona información sobre cómo proteger tu red.
Restringir el acceso a la red del plano de control y los nodos
Limita la exposición a Internet del plano de control y los nodos de tu clúster. Estas opciones no se pueden cambiar después de crear el clúster. De forma predeterminada, los nodos de clúster de Google Distributed Cloud se crean con direcciones RFC 1918, y es una práctica recomendada no cambiarlo. Implementa reglas de cortafuegos en tu red local para restringir el acceso al plano de control.
Usar políticas de red para restringir el tráfico
De forma predeterminada, todos los servicios de un clúster de Google Distributed Cloud pueden comunicarse entre sí. Para obtener información sobre cómo controlar la comunicación entre servicios según las necesidades de tus cargas de trabajo, consulta las siguientes secciones.
Restringir el acceso de red a los servicios dificulta mucho que los atacantes se muevan lateralmente dentro de tu clúster y ofrece a los servicios cierta protección contra la denegación de servicio accidental o deliberada. Hay dos formas recomendadas de controlar el tráfico:
- Para controlar el tráfico de capa 7 a los endpoints de tus aplicaciones, usa Istio. Elige esta opción si te interesan el balanceo de carga, la autorización de servicios, la limitación, la cuota y las métricas.
- Para controlar el tráfico de nivel 4 entre pods, usa las políticas de red de Kubernetes. Elige esta opción si buscas las funciones básicas de control de acceso gestionadas por Kubernetes.
Puedes habilitar las políticas de red de Istio y Kubernetes después de crear tus clústeres de Google Distributed Cloud. Puedes usarlos juntos si lo necesitas.
Para obtener más información, consulta la siguiente documentación:
Seguridad declarativa
En esta sección se ofrecen recomendaciones para proteger tus clústeres.
Usar Policy Controller
Los controladores de admisión de Kubernetes son complementos que rigen y aplican cómo se usa un clúster de Kubernetes. Los controladores de admisión son una parte importante del enfoque de defensa en profundidad para proteger tu clúster.
La práctica recomendada es usar Policy Controller. Policy Controller usa el framework de restricciones de OPA para describir e implementar políticas como CRDs. Las restricciones que apliques a tu clúster se definen en plantillas de restricciones, que se implementan en tus clústeres.
Para obtener información sobre cómo usar las restricciones de Policy Controller para conseguir muchas de las mismas protecciones que PodSecurityPolicies, con la ventaja añadida de poder probar tus políticas antes de aplicarlas, consulta el artículo Usar restricciones para reforzar la seguridad de los pods.
Para obtener más información, consulta la siguiente documentación:
Restringir la capacidad de las cargas de trabajo para modificarse a sí mismas
Algunas cargas de trabajo de Kubernetes, especialmente las del sistema, tienen permiso para modificarse a sí mismas. Por ejemplo, algunas cargas de trabajo se escalan verticalmente de forma automática. Aunque es una opción cómoda, puede permitir que un atacante que ya haya vulnerado un nodo siga escalando en el clúster. Por ejemplo, un atacante podría hacer que una carga de trabajo de un nodo se ejecute como una cuenta de servicio con más privilegios que exista en el mismo espacio de nombres.
Lo ideal es que las cargas de trabajo no tengan permiso para modificarse a sí mismas. Cuando sea necesario modificar el sistema, puedes limitar los permisos aplicando restricciones de Gatekeeper o Policy Controller, como NoUpdateServiceAccount de la biblioteca de código abierto de Gatekeeper, que proporciona varias políticas de seguridad útiles.
Cuando implementas políticas, suele ser necesario permitir que los controladores que gestionan el ciclo de vida del clúster omitan las políticas y las canalizaciones de registro y monitorización. Esto es necesario para que los controladores puedan hacer cambios en el clúster, como aplicar actualizaciones. Por ejemplo, si implementas la política NoUpdateServiceAccount en Google Distributed Cloud, debes definir los siguientes parámetros en Constraint:
parameters:
allowedGroups:
- system:masters
allowedUsers:
- system:serviceaccount:kube-system:monitoring-operator
- system:serviceaccount:kube-system:stackdriver-operator
- system:serviceaccount:kube-system:metrics-server-operator
- system:serviceaccount:kube-system:logmon-operator
Mantenimiento
En esta sección se proporciona información sobre el mantenimiento de los clústeres.
Actualizar Google Distributed Cloud
Kubernetes incorpora periódicamente nuevas funciones de seguridad y proporciona parches de seguridad.
Es tu responsabilidad mantener actualizados tus clústeres de Google Distributed Cloud. En cada lanzamiento, consulta las notas de la versión. Además, te recomendamos que actualices a las nuevas versiones de parche cada mes y a las versiones secundarias cada tres meses. Consulta cómo actualizar tus clústeres.
También eres responsable de actualizar y proteger la infraestructura de vSphere:
- Establece un proceso para aplicar parches y actualizaciones a tiempo de tus VMs
- Mantente al día de los avisos de seguridad de VMware
- Sigue las directrices sobre aplicación de parches a hosts.
Monitorizar los boletines de seguridad
El equipo de seguridad de GKE publica boletines de seguridad sobre vulnerabilidades de gravedad alta y crítica.
Estos boletines siguen un Google Cloud esquema de numeración de vulnerabilidades común y están vinculados a la página principal de los Google Cloud boletines y a las notas de la versión de Google Distributed Cloud. Cada página de boletín de seguridad tiene un feed RSS al que los usuarios pueden suscribirse para recibir novedades.
Cuando se requiere la intervención del cliente para solucionar estas vulnerabilidades de alta y crítica gravedad, Google se pone en contacto con él por correo electrónico. Además, Google también puede ponerse en contacto con los clientes que tengan contratos de asistencia a través de los canales de asistencia.
Para obtener más información, consulta la siguiente documentación:
Monitorizar y almacenar registros
Google Distributed Cloud incluye varias opciones para el registro y la monitorización de clústeres, como servicios gestionados basados en la nube, herramientas de código abierto y compatibilidad validada con soluciones comerciales de terceros:
- Cloud Logging y Cloud Monitoring, habilitados por agentes en el clúster desplegados con Google Distributed Cloud
- Configuraciones validadas con soluciones de terceros
Independientemente de la solución de registro que elijas en función de los requisitos de tu empresa, te recomendamos que registres los eventos y las alertas relevantes en un servicio de gestión de información y eventos de seguridad (SIEM) centralizado para gestionar los incidentes de seguridad.
Para obtener más información, consulta la siguiente documentación:
- Registro y monitorización
- Usar el almacenamiento de registros y la monitorización
- Almacenamiento de registros y monitorización de aplicaciones
- Monitorizar Google Distributed Cloud con Elastic Stack
- Transmitir registros de Google Cloud a Splunk