Estás viendo la documentación de una versión anterior de GKE On-Prem. Consulta la documentación más reciente.

Security

En esta página, se describen las funciones de seguridad que se incluyen en GKE On-Prem, además de cada capa de su infraestructura y cómo puedes configurarlas según tus necesidades.

Resumen

GKE On-Prem ofrece varias características que ayudan a proteger las cargas de trabajo, incluido el contenido de tu imagen de contenedor, el entorno de ejecución del contenedor, la red del clúster y el acceso al servidor de la API del clúster.

Es mejor adoptar un enfoque por capas para proteger los clústeres y las cargas de trabajo. Puedes aplicar el principio de privilegio mínimo a nivel de acceso que proporcionas a tus usuarios y cargas de trabajo. Es posible que debas realizar compensaciones para permitir el nivel adecuado de flexibilidad y seguridad.

Autenticación y autorización

Debes autenticarte en los clústeres de GKE On-Prem mediante OpenID Connect (OIDC) (a través de kubectl) o un token de cuenta de servicio de Kubernetes a través de Cloud Console.

Para configurar un acceso más detallado a los recursos de Kubernetes en el nivel del clúster o en los espacios de nombres de Kubernetes, usa el Control de acceso según la función (RBAC) de Kubernetes. Este te permite crear políticas detalladas que definan a qué operaciones y recursos pueden acceder los usuarios y las cuentas de servicio. Con RBAC, puedes controlar el acceso para cualquier identidad proporcionada que se validó.

A fin de simplificar y optimizar aún más tu estrategia de autenticación y autorización para Kubernetes Engine, GKE On-Prem inhabilita el control de acceso basado en atributos heredados (ABAC).

Si deseas obtener más información, consulta la página Prepara un entorno de Kubernetes Engine para la producción.

Seguridad del plano de control

Los componentes del plano de control incluyen el servidor de la API de Kubernetes, el programador, los controladores y la base de datos de etcd en la que se conserva tu configuración de Kubernetes. Mientras que en Kubernetes Engine, Google administra y mantiene los componentes del plano de control de Kubernetes, los administradores locales administran los componentes del plano de control en GKE On-Prem.

En GKE On-Prem, los componentes del plano de control se ejecutan dentro de tu red corporativa. Para proteger el servidor de la API de GKE On-Prem, puedes usar tus políticas de red corporativas y firewalls existentes. También puedes asignar una dirección IP privada al servidor de la API y limitar el acceso a la dirección privada.

Toda la comunicación en GKE On-Prem se realiza a través de canales TLS regidos por tres autoridades certificadas (CA): etcd, clúster y organización:

  • La CA etcd protege la comunicación del servidor de la API a las réplicas de etcd y también el tráfico entre réplicas de etcd. Esta CA está autofirmada.
  • La CA del clúster protege la comunicación entre el servidor de la API y todos los clientes internos de la API de Kubernetes (kubelets, controladores, programadores). Esta CA está autofirmada.
  • La CA de la organización es una CA externa que se usa para entregar la API de Kubernetes a usuarios externos. Tú administras esta CA.

Para los planos de control de administrador, las claves se almacenan en el nodo del plano de control. Para los clústeres de usuarios, las claves se almacenan como secretos de Kubernetes en el plano de control del administrador. El servidor de la API se configura con un certificado proporcionado por el usuario firmado por la CA de la organización. El servidor de la API usa la Indicación del nombre del servidor (SNI) para determinar si debe usar la clave firmada por la CA del clúster o la clave firmada por la CA de la organización.

La autenticación del clúster en GKE On-Prem se controla mediante certificados y tokens del portador de la cuenta de servicio. Como administrador, autenticarás en el plano de control mediante OIDC o con el certificado administrativo (que usas para la creación inicial de vinculación de función o con fines de emergencia).

La rotación de certificados se controla de las siguientes maneras:

  • Para el servidor de la API, los planos de control y los nodos, los certificados se crean o rotan en cada actualización.
  • Las CA se pueden rotar con poca frecuencia o a pedido.

Seguridad de nodos

GKE On-Prem implementa tus cargas de trabajo en instancias de VMware, que se adjuntan a tus clústeres como nodos. En las secciones siguientes, se muestra cómo aprovechar las características de seguridad a nivel de nodo disponibles en GKE On-Prem.

Ubuntu

GKE On-Prem usa una versión optimizada de Ubuntu como sistema operativo en el que se ejecutan el plano de control y los nodos de Kubernetes. Ubuntu incluye un conjunto completo de características de seguridad modernas, y GKE On-Prem implementa varias características de mejora de seguridad para clústeres, incluidas las siguientes:

Las guías de seguridad adicionales están disponibles para Ubuntu, como las que se mencionan a continuación:

Actualizaciones de nodos

Debes actualizar los nodos de forma periódica. Es posible que, de vez en cuando, los problemas de seguridad en el entorno de ejecución del contenedor, Kubernetes, o el sistema operativo del nodo requieran que actualices los nodos con mayor urgencia. Cuando actualizas el clúster, el software de cada nodo se actualiza a las últimas versiones.

Asegura las cargas de trabajo

Kubernetes permite a los usuarios aprovisionar, escalar y actualizar con rapidez las cargas de trabajo basadas en contenedores. En esta sección, se describen tácticas que los administradores y los usuarios pueden usar para limitar la capacidad de los contenedores en ejecución de afectar a otros contenedores del clúster, los hosts en los que se ejecutan y los servicios de GCP habilitados en su proyecto.

Limita los privilegios del proceso de contenedor del pod

Es importante limitar los privilegios de los procesos en contenedores para la seguridad general del clúster. Kubernetes Engine te permite configurar opciones relacionadas con la seguridad mediante el contexto de seguridad en los Pods y los contenedores. Esta configuración te permite cambiar la configuración de seguridad de tus procesos, por ejemplo:

  • El usuario y el grupo que se ejecutarán
  • Funciones de Linux disponibles
  • Elevación de privilegios

Para cambiar esta configuración a nivel de clúster en lugar de a nivel de pod o contenedor, debes crear un recurso PodSecurityPolicy. PodSecurityPolicies garantiza que todos los pods de un clúster cumplan con una política de referencia mínima que debes definir.

Ubuntu, el sistema operativo de nodo de GKE On-Prem predeterminado, aplica las políticas de seguridad de AppArmor de Docker predeterminadas a todos los contenedores que se inician con Kubernetes. Puedes ver la plantilla del perfil en GitHub. Entre otros aspectos, el perfil les niega las siguientes capacidades a los contenedores:

  • Escribir en archivos directamente en un directorio de ID de proceso (/proc/).
  • Escribir en archivos que no están en /proc/
  • Escribir en archivos en /proc/sys que no sean /proc/sys/kernel/shm*
  • Activar sistemas de archivos

Audit Logging

El registro de auditoría de Kubernetes proporciona una forma para que los administradores retengan, consulten, procesen y generen alertas sobre los eventos que ocurren en los entornos GKE On-Prem. Los administradores pueden usar la información registrada a fin de realizar análisis forenses, alertas en tiempo real o para catalogar cómo y quién usa una flota de clústeres de Kubernetes Engine.

De forma predeterminada, GKE On-Prem registra la actividad del administrador. Como alternativa, puedes registrar eventos de acceso a los datos según los tipos de operaciones que desees inspeccionar.

El agente de Connect solo se comunica con el servidor de API que se ejecuta en las instalaciones locales, y cada clúster debe tener su propio conjunto de registros de auditoría. El clúster registra todas las acciones que los usuarios realizan desde la IU a través de Connect.

Encryption

Google Cloud Key Management Service (Cloud KMS) es un servicio de administración de claves alojado en la nube que te permite administrar claves criptográficas para tus servicios. Puedes generar, usar, rotar y destruir claves criptográficas AES256, RSA 2048, RSA 3072, RSA 4096, EC P256 y EC P384. Cloud KMS está integrado en Cloud IAM y Cloud Audit Logging para que puedas administrar permisos en claves individuales y supervisar cómo se usan. Usa Cloud KMS para proteger secretos y otros datos sensibles que necesites almacenar.

Si tus clústeres y cargas de trabajo de GKE On-Prem se conectan de forma segura a los servicios de Google Cloud a través de Cloud VPN, puedes usar Cloud KMS para la administración de claves. De lo contrario, puedes usar una de las siguientes alternativas:

  • Secretos de Kubernetes
  • Hashicorp Vault
  • Módulo de seguridad de hardware (HSM)

Secretos de Kubernetes

Los recursos de secretos de Kubernetes almacenan datos sensibles, como contraseñas, tokens de OAuth y claves SSH, en tus clústeres. Almacenar datos sensibles en secretos es más seguro que almacenarlos en ConfigMaps de texto simple o en especificaciones de pod. El uso de secretos te permite controlar la manera en que se usan los datos sensibles, y reduce el riesgo de exposición de datos a usuarios no autorizados.

Hashicorp Vault

Módulo de seguridad de hardware