En este documento se describen las medidas de seguridad integradas en Connect.
Una plataforma híbrida y multinube eficaz ofrece gestión centralizada, observabilidad y acceso a los servicios en todos los entornos. GKE Enterprise ofrece una experiencia uniforme y completa en todas esas funciones, independientemente del proveedor de Kubernetes que utilices. Connect es un agente ligero que ofrece lo siguiente a escala y en todos los proveedores:
- Gestión de varios clústeres y visibilidad de los clústeres
- Despliegue y gestión del ciclo de vida de los servicios de aplicaciones
En este documento se trata lo siguiente:
- Cómo el diseño de Connect prioriza la seguridad
- Prácticas recomendadas para la implementación del agente Connect
- Cómo mejorar la posición de seguridad de tu implementación de Kubernetes
Arquitectura de Connect
Connect permite que los usuarios finales y los Google Cloud servicios accedan a servidores de la API de Kubernetes que no están en Internet público. El agente de Connect se ejecuta en el clúster de Kubernetes (un agente por clúster) y se conecta a un proxy de Connect. Google Cloud Los servicios que necesitan interactuar con el clúster de Kubernetes se conectan al proxy, que reenvía las solicitudes al agente. A su vez, el agente las reenvía al servidor de la API de Kubernetes, como se muestra en el siguiente diagrama.
Cuando se implementa el agente, establece una conexión TLS 1.2+ persistente con los servicios deGoogle Cloud para esperar solicitudes. Google Cloud Cuando los administradores habilitan los servicios, estos pueden generar solicitudes para tus clústeres de Kubernetes. Estas solicitudes también pueden proceder de la interacción directa de los usuarios con la Google Cloud consola, Connect Gateway u otros servicios de Google.
El Google Cloud servicio envía la solicitud al proxy. A continuación, el proxy reenvía la solicitud al agente desplegado responsable de un clúster y, por último, el agente reenvía la solicitud al servidor de la API de Kubernetes. El servidor de la API de Kubernetes aplica las políticas de autenticación, autorización y registro de auditoría de Kubernetes, y devuelve una respuesta. La respuesta se devuelve a través del agente y del proxy al servicio Google Cloud . En cada paso del proceso, los componentes realizan la autenticación y la autorización por conexión y por solicitud.
El servidor de la API de Kubernetes aplica las mismas políticas de autenticación, autorización y registro de auditoría a todas las solicitudes, incluidas las que se realizan a través de Connect. Este proceso asegura que siempre tengas el control del acceso a tu clúster.
Conexión y defensa en profundidad
La protección reforzada es intrínseca a todo lo que hace Google Cloud en su infraestructura y en sus prácticas de seguridad. Aplicamos un enfoque por capas a todos los aspectos de la seguridad de nuestra organización y de nuestros clientes para proteger datos, información y usuarios valiosos. Este es el mismo principio por el que hemos diseñado Connect.
Además de la estrategia y el diseño de defensa en profundidad de Google, debes evaluar el contenido que se proporciona aquí junto con tu postura y tus estándares de seguridad. En esta sección se describen medidas adicionales que puedes tomar para complementar las prácticas recomendadas de protección de Kubernetes.
Seguridad de componente a componente
Cada componente de una solicitud de Connect autentica a sus iguales y solo comparte datos con los iguales que están autenticados y autorizados para acceder a esos datos, tal como se muestra en el siguiente diagrama.
Cada componente de una solicitud de conexión usa lo siguiente para autenticarse entre sí:
- Seguridad en la capa de transporte (TLS)
- Seguridad de transporte en la capa de la aplicación (ALTS)
- OAuth
Cada componente de una solicitud de conexión usa lo siguiente para autorizarse entre sí:
- Gestión de identidades y accesos (IAM)
- Listas de permitidos
Cada conexión entre el clúster de Kubernetes y Google Cloud está cifrada y, en cada conexión, al menos un peer usa la autenticación basada en certificados. Este proceso ayuda a asegurar que todas las credenciales de token se cifren en tránsito y que solo las reciban los peers autenticados y autorizados.
Autenticación de usuarios en Google Cloud
Cuando se usa la consola, los usuarios siguen el flujo de inicio de sesión estándar de Google. Google Cloud proporciona un certificado TLS que autentica el navegador del usuario, y el usuario inicia sesión en una cuenta de Google Cloud o de Google Workspace para autenticarse en Google Cloud. Google Cloud
El acceso a un proyecto a través de la Google Cloud consola u otras APIs se controla mediante permisos de gestión de identidades y accesos.
Autenticación entre serviciosGoogle Cloud
Google Cloud usa ALTS para la autenticación interna de servicio a servicio. ALTS permite que los Google Cloud servicios, como el proxy, creen una conexión autenticada y protegida contra manipulaciones.
Los servicios deGoogle Cloud deben tener autorización interna para usar el proxy y conectarse a una instancia de Connect remota, ya que el proxy usa una lista de permitidos de identidades de servicio para limitar el acceso.
Autenticando Google Cloud
El agente usa TLS para autenticar y cifrar cada conexión. El agente autentica los certificados TLS de Google Cloud mediante un conjunto de certificados raíz integrados en el archivo binario para evitar que se confíe por error en los certificados añadidos al contenedor del agente. El agente solo ejecuta llamadas a la API en endpoints autenticados correctamente. Este proceso ayuda a asegurar que los certificados de la cuenta de servicio y las solicitudes a la API de Kubernetes se envíen desdeGoogle Cloudy que las respuestas se envíen solo a Google Cloud.
Para ver la lista de dominios con los que se comunica el agente durante el funcionamiento normal, consulta Asegurar la conectividad de red.
Puedes configurar el agente para que se conecte Google Cloud
a través de un proxy HTTP. En esta configuración, el agente usa HTTP/1.1
CONNECT con el proxy HTTP y establece una conexión TLS conGoogle Cloud. El proxy HTTP solo ve el tráfico cifrado entre el agente y Google Cloud. La integridad y la seguridad de extremo a extremo de la conexión entre el agente y Google Cloud no se ven afectadas.
Autenticar al agente
El agente se autentica en Google Cloud mediante Federación de identidades de cargas de trabajo de flotas. La federación de identidades de cargas de trabajo de flotas te permite autenticarte desde cargas de trabajo de flotas en las APIs de Google Cloud mediante mecanismos de autenticación integrados Google Cloud y de Kubernetes. Cuando el agente quiere autenticarse en Google Cloud, intercambia su token de cuenta de servicio de Kubernetes por un token de acceso que representa su identidad de carga de trabajo.
Servidor de la API de Kubernetes
El agente usa la biblioteca de cliente de Kubernetes para crear una conexión TLS con el servidor de la API de Kubernetes. El tiempo de ejecución de Kubernetes proporciona al contenedor del agente un certificado de autoridad de certificación (CA) TLS que el agente usa para autenticar el servidor de la API.
El servidor de la API autentica cada solicitud por separado, como se describe en la siguiente sección.
Solicitar seguridad
Cada solicitud enviada desde Google Cloud a través de Connect incluye credenciales que identifican al remitente de la solicitud: tanto el servicioGoogle Cloud que generó la solicitud como (si procede) el usuario final en cuyo nombre se envía la solicitud. Estas credenciales permiten que el servidor de la API de Kubernetes proporcione controles de autorización y auditoría para cada solicitud.
Autenticación de servicio a agente
Cada solicitud enviada al agente incluye un token de corta duración que identifica el servicioGoogle Cloud que ha enviado la solicitud, como se muestra en el siguiente diagrama.
El token está firmado por una cuenta de servicio de Google Cloud asociada exclusivamente al servicio de Google Cloud . El agente obtiene las claves públicas de la cuenta de servicio para validar el token. Este token no se reenvía al servidor de la API.
El agente valida Google Cloud los certificados mediante raíces de AC insertadas en el archivo binario. Este proceso ayuda a asegurar que recibe solicitudes auténticas e inalteradas de Google Cloud.
Autenticación de usuarios finales
LosGoogle Cloud servicios que acceden a clústeres en nombre de un usuario requieren las credenciales de ese usuario para autenticarse en el servidor de la API, tal como se muestra en el siguiente diagrama.
Esta política ayuda a garantizar que se aplique el mismo conjunto de permisos al usuario cuando acceda a través de Connect. Algunos Google Cloud servicios se autentican en el servidor de la API en nombre de un usuario. Por ejemplo, un usuario puede acceder a la consola para ver las cargas de trabajo de los clústeres registrados en la flota. Google Cloud Cuando un usuario accede a estos servicios, proporciona credenciales que el servidor de la API de Kubernetes reconoce: cualquiera de los tokens que admite el servidor de la API de Kubernetes.
La Google Cloud consola almacena estas credenciales como parte del perfil de un usuario. Estas credenciales se encriptan en reposo, solo se puede acceder a ellas con las credenciales deGoogle Cloud o de Google Workspace del usuario y solo se usan para las conexiones a través de Connect. Estas credenciales no se pueden volver a descargar. Las credenciales se eliminan cuando el usuario cierra sesión en el clúster, cuando se elimina el registro del clúster en Google Cloud, cuando se elimina el proyecto o cuando se elimina la cuenta de usuario. Para obtener más información, consulta Eliminación de datos en Google Cloud.
Cuando un usuario interactúa con la consola, se generan solicitudes para el servidor de la API de Kubernetes. Google Cloud El servicio envía las credenciales del usuario junto con la solicitud a través de Connect. A continuación, el agente presenta la solicitud y las credenciales al servidor de la API de Kubernetes.
El servidor de la API de Kubernetes autentica las credenciales del usuario, autoriza la identidad del usuario, genera un evento de auditoría para la acción (si está configurado) y devuelve el resultado. Como las credenciales proporcionadas por el usuario se usan para autenticar la solicitud, el servidor de la API de Kubernetes aplica la misma política de autorización y auditoría a las solicitudes de conexión que a otras solicitudes.
Autenticación de servicio a Kubernetes
LosGoogle Cloud servicios que acceden al servidor de la API de Kubernetes fuera del contexto de un usuario utilizan la suplantación de identidad de Kubernetes para autenticarse en el servidor de la API de Kubernetes. Este método permite que el servidor de la API de Kubernetes proporcione comprobaciones de autorización y registros de auditoría por servicio, tal como se muestra en el siguiente diagrama.
Los servicios de Google Cloud pueden usar Connect fuera del contexto de un usuario. Por ejemplo, un servicio de entrada multiclúster puede sincronizar automáticamente los recursos de entrada entre clústeres. Estos servicios no tienen credenciales que el servidor de la API de Kubernetes pueda autenticar: la mayoría de los servidores de la API no están configurados para autenticar las credenciales del servicio. Google Cloud Sin embargo, un servidor de la API puede delegar privilegios de autenticación limitados en otro servicio mediante la suplantación de identidad, y el agente puede autenticar servicios Google Cloud enviando solicitudes a través de Connect. En conjunto, permiten que las solicitudes a través del agente se autentiquen como cuentas de servicio. Google Cloud
Cuando un servicio de Google Cloud envía una solicitud por su cuenta (en lugar de hacerlo en el contexto de un usuario), el agente añade sus propias credenciales de Kubernetes y encabezados de suplantación de identidad de Kubernetes a la solicitud, que identifican el servicio de Google Cloud . Google Cloud Los encabezados de suplantación afirman que el nombre de usuario es el de la cuenta de servicio Google Cloud autenticada por el agente.
El servidor de la API de Kubernetes autentica las credenciales del agente y comprueba que el agente pueda suplantar la identidad de la Google Cloud cuenta de servicio. La capacidad de suplantar la identidad se suele controlar mediante reglas de control de acceso basado en roles (RBAC) y se puede limitar a identidades específicas, como las cuentas de servicio. Google Cloud
Si el agente tiene autorización para suplantar la identidad solicitada, el servidor de la API realiza comprobaciones de autorización para la cuenta de servicio Google Cloud y responde a la solicitud. El registro de auditoría de la solicitud incluye tanto la identidad del agente como la Google Cloud cuenta de servicio suplantada.
Seguridad en el clúster
En última instancia, el agente envía solicitudes a la API de Kubernetes al servidor de la API de Kubernetes, como se ilustra en el siguiente diagrama.
El servidor de la API de Kubernetes autentica, autoriza y registra en auditorías estas solicitudes, al igual que hace con todas las demás solicitudes que sirve.
Como proxy de estas solicitudes, el agente tiene acceso a datos sensibles, como credenciales, solicitudes y respuestas. Kubernetes y el ecosistema de Kubernetes proporcionan un conjunto de herramientas para evitar que otros agentes obtengan ese acceso y para ayudar a garantizar que el agente solo acceda a lo que se supone que debe acceder.
Autenticación de Kubernetes
El servidor de la API de Kubernetes autentica al remitente de cada solicitud entrante para determinar qué permisos se deben aplicar en la fase de autorización. Como se ha descrito anteriormente, la solicitud incluye las credenciales de un usuario o las credenciales de Kubernetes del agente y los encabezados de suplantación de identidad.
Los administradores de clústeres siguen controlando los mecanismos de autenticación reconocidos por el servidor de la API de Kubernetes. Los administradores pueden revocar las credenciales de un usuario y revocar o reducir los privilegios de las credenciales del agente.
Autorización de Kubernetes
El servidor de la API de Kubernetes comprueba que la identidad autenticada tiene permiso para realizar la acción solicitada en el recurso solicitado.
El administrador del clúster puede usar cualquiera de los mecanismos de autorización de Kubernetes para configurar reglas de autorización. Connect no realiza ninguna comprobación de autorización en nombre del clúster.
Seguridad de los agentes
El agente tiene acceso a sus propias credenciales (Kubernetes y Google Cloud), así como a las credenciales, las solicitudes y las respuestas que pasan por él. Por lo tanto, el agente ocupa una posición de confianza en un clúster conectado.
El agente se ha diseñado con los siguientes principios de seguridad:
- El agente está escrito en Go, que proporciona gestión de memoria con recolección de elementos no utilizados e impide muchas operaciones de memoria no seguras.
- El agente se despliega en una imagen de contenedor sin distribución. La imagen del agente no incluye un shell, libc ni otro código ajeno a la ruta de ejecución del agente.
- La imagen del agente se crea con la infraestructura de compilación compartida de Google a partir de código registrado. Solo este sistema de compilación puede desplegar imágenes de agente en Container Registry. LosGoogle Cloud desarrolladores no pueden desplegar nuevas imágenes por su cuenta. Este proceso ayuda a asegurar que todas las modificaciones del origen del agente se puedan rastrear hasta un autor y un revisor para evitar el repudio.
El agente se ejecuta como un despliegue estándar en un clúster de Kubernetes que se despliega en el momento en que registras el clúster.
Por lo tanto, el agente puede usar todas las opciones y prácticas recomendadas disponibles para monitorizar y proteger las implementaciones, ReplicaSets y pods.
Estos mecanismos se han diseñado para que sea difícil poner en peligro el contenedor del agente. Sin embargo, el acceso privilegiado al nodo del agente puede seguir poniendo en peligro el entorno del agente. Por lo tanto, es importante que los administradores sigan las directrices de seguridad estándar de Kubernetes para proteger la infraestructura del clúster.
Seguridad de los datos con Controles de Servicio de VPC
Controles de Servicio de VPC proporciona una capa adicional de defensa de seguridad para los Google Cloud servicios que es independiente de Gestión de Identidades y Accesos (IAM). Mientras que Gestión de Identidades y Accesos permite un control de acceso granular basado en la identidad, Controles de Servicio de VPC ofrece una seguridad de perímetro basada en el contexto más amplia, incluido el control de la salida de datos a través del perímetro. Por ejemplo, puedes especificar que solo determinados proyectos puedan acceder a tus datos de BigQuery. Para obtener más información sobre cómo funciona Controles de Servicio de VPC para proteger tus datos, consulta la descripción general de Controles de Servicio de VPC.
Puedes usar Controles de Servicio de VPC con Connect para aumentar la seguridad de los datos una vez que te asegures de que se puede acceder a los servicios necesarios para usar Connect desde el perímetro de servicio especificado.
Si quieres usar Controles de Servicio de VPC, debes habilitar las siguientes APIs:
cloudresourcemanager.googleapis.comgkeconnect.googleapis.comgkehub.googleapis.com
También debes configurar la conectividad privada para acceder a las APIs correspondientes. Consulta cómo hacerlo en Configurar la conectividad privada.