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 Cloud accedan a los servidores de la API de Kubernetes que no están disponibles en el 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. Los servicios de Google Cloud que necesitan interactuar con el clúster de Kubernetes se conectan con el 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 con Google Cloud y espera solicitudes. Si los administradores habilitan los servicios de Google Cloud, estos 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 de 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 hace Google Cloud 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 los usuarios utilizan la consola de Google Cloud, pasan por el flujo 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 de Google Workspace para autenticarse en Google Cloud.
El acceso a un proyecto a través de la consola de Google Cloud o de otras API se controla mediante los permisos de IAM.
Autenticación entre servicios de Google Cloud
Google Cloud usa ALTS para la autenticación interna entre servicios. ALTS permite que los servicios de Google Cloud, como el proxy, creen una conexión autenticada que protege la integridad.
Los servicios de Google Cloud deben autorizarse de manera interna para conectarse mediante el proxy a una instancia remota de Connect porque el proxy usa una lista de identidades de servicio permitidas para limitar el acceso.
Autentica Google Cloud
El agente usa TLS para autenticar y encriptar cada conexión. El agente autentica los certificados TLS de Google Cloud mediante un conjunto de certificados raíz integrados en el objeto binario y, de ese modo, evita confiar de manera inadvertida en los certificados agregados al contenedor del agente. El agente solo ejecuta llamadas a las API contra los extremos autenticados correctamente. Este proceso ayuda a garantizar que Google Cloud enví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 con Google 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 mediante una cuenta de servicio de Google Cloud creada por ti. Cuando el administrador del clúster implementa el agente, proporciona una clave privada para esta cuenta de servicio y asume la responsabilidad de la privacidad de la clave. Cuando el agente se conecta a Google Cloud, se autentica con esta cuenta de servicio y solicita recibir solicitudes para el proyecto configurado.
Google Cloud autentica las credenciales de la cuenta de servicio y también verifica que la cuenta de servicio de Google Cloud tenga el permiso gkehub.endpoints.connect de IAM en el proyecto. Por lo general, este permiso se otorga a través del rol gkehub.connect. Sin este permiso, la solicitud del agente se rechaza y no puede recibir solicitudes de Google Cloud.
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 de Google 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 de Google Cloud que envió la solicitud, como se ilustra en el siguiente diagrama.
El token tiene la firma de una cuenta de servicio de Google Cloud asociada de manera exclusiva con dicho servicio. 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 mediante 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
Los servicios de Google Cloud 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 de Google 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 las flotas. 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 de usuario de Google Cloud o Google Workspace, 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, genera 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 de Google 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 de 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 servicios de Google Cloud. Sin embargo, un servidor de la API puede delegar privilegios de autenticación limitados a otro mediante concesión de datos de identidad, y el agente puede autenticar servicios de Google Cloud enviando solicitudes mediante 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 identidad reclaman un nombre de usuario de la cuenta de servicio de Google Cloud que autentica 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 usar la identidad suele controlarse mediante reglas de control de acceso basado en funciones (RBAC) y puede limitarse a identidades específicas, como las cuentas de servicio de Google Cloud.
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 de 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 de 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 de Google 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 de Google 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.