En este documento, se explican las medidas de seguridad integradas en Connect.
Esta plataforma híbrida eficaz de múltiples nubes ofrece administración central, visibilidad y acceso a los servicios en todos los entornos. GKE Enterprise proporciona una experiencia integral y uniforme en cuanto a esas funciones, sin importar el proveedor de Kubernetes que uses. Connect es un agente básico que proporciona lo siguiente en economías de escala y entre proveedores:
- Administración de varios clústeres y visibilidad de los clústeres
- Implementación de servicios de aplicaciones y administración del ciclo de vida
En este documento, se analizan los siguientes temas:
- Cómo el diseño de Connect prioriza la seguridad
- Prácticas recomendadas para la implementación del agente Connect
- Sugerencias para mejorar el enfoque de seguridad de la implementación de Kubernetes
Arquitectura de Connect
Connect permite que los usuarios finales y los servicios de Google Cloudaccedan a los servidores de la API de Kubernetes que no están disponibles en Internet pública. 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. El agente, a su vez, las reenvía al servidor de la API de Kubernetes como se muestra en el siguiente diagrama.
Cuando el agente está implementado, establece una conexión TLS 1.2 persistente conGoogle Cloud para esperar solicitudes. Google Cloud Los servicios, cuando los habilitan los administradores, pueden generar solicitudes para tus clústeres de Kubernetes. Estas solicitudes también pueden provenir de la interacción directa del usuario con la consola de Google Cloud , la puerta de enlace de Connect o algún otro servicio de Google.
El servicio Google Cloud envía la solicitud al proxy. Luego, el proxy reenvía la solicitud al agente implementado 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 reenvía a través del agente y del proxy al servicio de Google Cloud . En cada paso del proceso, los componentes realizan autenticación y 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 solicitudes hechas por medio de Connect. Este proceso te garantiza que siempre tienes el control del acceso a tu clúster.
Connect y la defensa en profundidad
La defensa en profundidad es intrínseca en todo lo que Google Cloud hace dentro de su infraestructura y prácticas de seguridad. Aplicamos un enfoque de capas a todos los aspectos relacionados con la seguridad de nuestra organización y de nuestros clientes, a fin de proteger los datos, la información y a nuestros usuarios valiosos. Este es el mismo principio mediante el cual diseñamos Connect.
Además del diseño y de la estrategia de la defensa en profundidad de Google, debes evaluar el contenido proporcionado aquí junto con tus estándares y tu enfoque en materia de seguridad. En esta sección, se indican medidas adicionales que puedes tomar para complementar las prácticas recomendadas de endurecimiento de Kubernetes.
Seguridad entre componentes
Cada componente de una solicitud de Connect autentica sus pares y solo comparte datos con pares que estén autenticados y autorizados para esos datos, como se ilustra en el siguiente diagrama.
Cada componente de una solicitud de Connect usa lo siguiente para autenticarse entre sí:
- Seguridad de la capa de transporte (TLS)
- Seguridad de transporte de la capa de la aplicación (ALTS)
- OAuth
Cada componente de una solicitud de Connect usa lo siguiente para autorizarse entre sí:
- Identity and Access Management (IAM)
- Listas de entidades permitidas
Cada conexión entre el clúster de Kubernetes y Google Cloud está encriptada, y al menos un par de cada conexión usa una autenticación basada en certificados. Este proceso ayuda a garantizar que todas las credenciales de token se encripten durante el envío y que solo las reciban los pares autenticados y autorizados.
Autenticación de usuarios en Google Cloud
Cuando se usa la consola de Google Cloud , los usuarios pasan por elflujo de acceso estándar de Google. Google Cloud proporciona un certificado TLS que el navegador del usuario autentica, y el usuario accede a una cuenta de Google Cloud o Google Workspace para autenticarse en Google Cloud.
El acceso a un proyecto a través de la consola de Google Cloud o de otras APIs se controla mediante los permisos de IAM.
Google Cloud Autenticación de servicio a servicio
Google Cloud Usa ALTS para la autenticación interna entre servicios. ALTS permite que los Google Cloud servicios, como el proxy, creen una conexión autenticada que protege la integridad.
Google Cloud Los servicios deben autorizarse de manera interna para usar el proxy y conectarse a una instancia remota de Connect, ya que el proxy usa una lista de identidades de servicio permitidas para limitar el acceso.
Autenticando Google Cloud
El agente usa TLS para autenticar y encriptar cada conexión. El agente autentica los certificados TLS con un conjunto de certificados raíz integrados en el objeto binario para evitar confiar de manera inadvertida en los certificados agregados al contenedor del agente. Google Cloud El agente solo ejecuta llamadas a las API contra los extremos autenticados correctamente. Este proceso ayuda a garantizar queGoogle Cloudenvíe los certificados de la cuenta de servicio y las solicitudes a la API de Kubernetes, y que las respuestas se envíen solo a Google Cloud.
Para obtener la lista de dominios con los que el agente se comunica durante el funcionamiento normal, consulta Garantiza la conectividad de red.
Puedes configurar el agente para que se conecte a Google Cloud a través de un proxy HTTP. En esta configuración, el agente usa HTTP/1.1
CONNECT en el proxy HTTP y establece una conexión TLS conGoogle Cloud. El proxy HTTP solo ve el tráfico encriptado entre el agente y Google Cloud. La integridad de extremo a extremo y la seguridad de la conexión entre el agente y Google Cloud no se ven afectadas.
Autentica el agente
El agente se autentica en Google Cloud con la Federación de Workload Identity de la flota. La federación de identidades para cargas de trabajo de la flota te permite autenticarte desde las cargas de trabajo de la flota en las APIs de Google Cloud con 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 API de Kubernetes
El agente usa la biblioteca cliente de Kubernetes para crear una conexión TLS con el servidor de la API de Kubernetes. El entorno de ejecución de Kubernetes valida al contenedor del agente como autoridad certificada (CA) de TLS. El agente utiliza este certificado 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.
Seguridad de las solicitudes
Cada solicitud enviada desde Google Cloud a través de Connect incluye credenciales que identifican al remitente de la solicitud: el servicio deGoogle Cloud que generó la solicitud y (si corresponde) el usuario final para el cual se envió la solicitud. Estas credenciales permiten que el servidor de la API de Kubernetes haga 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 servicio deGoogle Cloud que envió la solicitud, como se ilustra en el siguiente diagrama.
El token está firmado por una cuenta de servicio de Google Cloud asociada exclusivamente con el servicio de Google Cloud . El agente recupera 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 los certificados de Google Cloud con las raíces de CA incorporadas en el objeto binario. Este proceso ayuda a garantizar que solo lleguen solicitudes auténticas y sin cambios de Google Cloud.
Autenticación del usuario final
Google Cloud Los servicios que acceden a clústeres en nombre de un usuario requieren que las credenciales del usuario se autentiquen en el servidor de la API, como se ilustra en el siguiente diagrama.
Esta política ayuda a garantizar que se aplique el mismo conjunto de permisos al usuario cuando accede a través de Connect. Algunos servicios deGoogle Cloud se autentican en el servidor de la API en nombre de un usuario. Por ejemplo, un usuario puede acceder a la consola de Google Cloud para ver las cargas de trabajo en los clústeres inscritos en la flota. Cuando un usuario accede a estos servicios, proporciona las credenciales que el servidor de la API de Kubernetes reconoce: cualquiera de los tokens admitidos por el servidor de la API de Kubernetes.
La consola de Google Cloud almacena estas credenciales como parte del perfil de cada usuario. Estas credenciales se encriptan en reposo, solo se puede acceder a ellas con las credenciales deGoogle Cloud o Google Workspace del usuario y solo se usan para conexiones a través de Connect. Estas credenciales no se pueden volver a descargar. Las credenciales se borran cuando el usuario sale del clúster, cuando el registro del clúster se borra en Google Cloud, cuando se borra el proyecto o cuando se borra 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 de Google Cloud , se generan solicitudes para el servidor de la API de Kubernetes. El servicio envía las credenciales del usuario junto con la solicitud a través de Connect. Luego, 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, produce un evento de auditoría para la acción (si está configurado) y devuelve el resultado. Debido a que 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 para las solicitudes de Connect que para otras solicitudes.
Autenticación de servicio a Kubernetes
Los servicios deGoogle Cloud que acceden al servidor de la API de Kubernetes fuera del contexto del usuario usan los datos 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 ejecute comprobaciones de autorización por servicio y registros de auditoría, como se ilustra en el siguiente diagrama.
Los servicios en Google Cloud pueden usar Connect fuera del contexto del usuario. Por ejemplo, un servicio de entrada de varios clústeres puede sincronizar de manera automática los recursos de entrada en todos los 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 de los servicios. Google Cloud Sin embargo, un servidor de la API puede delegar privilegios de autenticación limitados a otro servicio a través de la concesión de identidad, y el agente puede autenticar los servicios de Google Cloud que envían solicitudes a través de Connect. En conjunto, permiten que las solicitudes que pasan a través del agente se autentiquen como cuentas de servicio de Google Cloud .
Cuando un servicio de Google Cloud envía una solicitud en nombre propio (en lugar de hacerlo desde el contexto de un usuario), el agente agrega a la solicitud sus propias credenciales de Kubernetes y encabezados de identidad de Kubernetes que identifican el servicio de Google Cloud . Los encabezados de suplantación de identidad reclaman un nombre de usuario de la cuenta de servicio Google Cloud autenticada por el agente.
El servidor de la API de Kubernetes autentica las credenciales del agente y también comprueba que el agente pueda usar la identidad de la cuenta de servicio de Google Cloud . La capacidad de suplantar la identidad suele controlarse mediante reglas de control de acceso basado en roles (RBAC) y puede limitarse a identidades específicas, como las Google Cloud cuentas de servicio.
Si el agente está autorizado para usar la identidad solicitada, el servidor de la API realiza verificaciones a fin de autorizar la cuenta de servicio Google Cloud y entrega la solicitud. El registro de auditoría de la solicitud incluye tanto la identidad del agente como la cuenta de servicio Google Cloud cuya identidad se empleó.
Seguridad en el clúster
En última instancia, el agente envía las solicitudes a la API de Kubernetes al servidor de esta API, como se ilustra en el siguiente diagrama.
El servidor de la API de Kubernetes autentica, autoriza y audita los registros de estas solicitudes, al igual que para todas las demás solicitudes a las que entrega servicios.
Como proxy para estas solicitudes, el agente tiene acceso a datos sensibles, como credenciales, solicitudes y respuestas. Kubernetes y su ecosistema proporcionan un conjunto de herramientas para evitar que otros actores obtengan ese acceso y 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 aplicar en la etapa de autorización. Como se describió antes, la solicitud incluye las credenciales de un usuario o incluye las credenciales de Kubernetes y los encabezados de identidad del agente.
Los administradores de clústeres tienen el control de los mecanismos de autenticación reconocidos por el servidor de la API de Kubernetes. Los administradores pueden tener permiso para revocar las credenciales de un usuario y revocar o reducir el privilegio de las credenciales del agente.
Autorización de Kubernetes
El servidor de la API de Kubernetes comprueba que la identidad autenticada tenga permiso para llevar a cabo 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 las reglas de autorización. Connect no realiza ninguna verificación de autorización en nombre del clúster.
Seguridad del agente
El agente tiene acceso a sus propias credenciales (de Kubernetes y Google Cloud), así como a las credenciales, las solicitudes y las respuestas que pasan por él. Como tal, el agente ocupa una posición de confianza en un clúster conectado.
El agente se diseñó con los siguientes conceptos básicos en cuanto a la seguridad:
- El agente se escribió en Go, que proporciona administración de recolección de memorias no utilizadas, y evita muchas operaciones de memoria poco seguras.
- El agente se implementa en una imagen de contenedor de Distroless. La imagen del agente no incluye un código 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 del código registrado. Solo este sistema de compilación puede implementar imágenes de agente en Container Registry. Los desarrolladores deGoogle Cloud no pueden implementar imágenes nuevas por sí mismos. Este proceso ayuda a garantizar que sea posible rastrear quién creó y revisó las ediciones de la fuente del agente a fin de evitar los repudios.
El agente se ejecuta como una implementación estándar en un clúster de Kubernetes, que se concreta en el momento en que se registra el clúster.
Como resultado, todas las opciones y prácticas recomendadas disponibles con el fin de supervisar y proteger las implementaciones, los ReplicaSets y los pods están disponibles para el agente.
Estos mecanismos están diseñados para evitar que el contenedor del agente se vea comprometido. Sin embargo, el acceso privilegiado al nodo del agente puede igualmente comprometer el entorno del agente. Por eso es importante que los administradores sigan las normas de seguridad establecidas de Kubernetes para proteger la infraestructura del clúster.
Seguridad de los datos con los Controles del servicio de VPC
Los Controles del servicio de VPC proporcionan una capa adicional de defensa de seguridad para los servicios deGoogle Cloud , que es independiente de Identity and Access Management (IAM). Si bien IAM habilita un control de acceso basado en la identidad detallado, los Controles del servicio de VPC permiten una seguridad perimetral basada en el contexto más amplia, que incluye el control de salida de datos en todo el perímetro. Por ejemplo, puedes especificar que solo ciertos proyectos puedan acceder a tus datos de BigQuery. Puedes encontrar más información sobre cómo funcionan los Controles del servicio de VPC para proteger tus datos en la descripción general de los Controles del servicio de VPC.
Puedes usar los Controles del servicio de VPC con Connect para obtener seguridad adicional 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 los Controles del 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 API correspondientes. Puedes obtener información para hacerlo en Configura una conectividad privada.