Seguridad

En esta página, se describen las funciones de seguridad incluidas en Google Distributed Cloud, incluida cada capa de su infraestructura, y cómo puedes configurarlas para que se adapten a tus necesidades.

Descripción general

GKE en VMware ofrece varias funciones para ayudar a proteger tus cargas de trabajo, incluidos el contenido de la imagen del contenedor, el entorno de ejecución del contenedor, la red del clúster y el acceso al servidor de 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 al nivel de acceso que proporcionas a los usuarios y las cargas de trabajo. Es posible que debas realizar compensaciones para permitir el nivel adecuado de flexibilidad y seguridad.

Autenticación y autorización

Puedes autenticarte en los clústeres de GKE alojados en VMware mediante OpenID Connect (OIDC) o un token de cuenta de servicio de Kubernetes a través de la consola de Cloud.

Para configurar un acceso más detallado a los recursos de Kubernetes a nivel del clúster o en los espacios de nombres de Kubernetes, usa el Control de acceso basado en funciones (RBAC) de Kubernetes. El RBAC te permite crear políticas detalladas que definan a qué operaciones y recursos pueden acceder los usuarios y las cuentas de servicio. Con el 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 en VMware inhabilita el control de acceso basado en atributos heredados (ABAC).

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 la 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 alojado en VMware.

En GKE alojado en VMware, los componentes del plano de control se ejecutan dentro de tu red corporativa. Puedes proteger el servidor de la API de GKE alojado en VMware con 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 en VMware se realiza a través de canales de TLS, que están regidos por tres autoridades certificadoras (AC): etcd, clúster y organización:

  • La CA de 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 de 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 de clústeres en GKE alojada en VMware se controla mediante certificados y tokens del portador de la cuenta de servicio. Como administrador, debes autenticar en el plano de control mediante OIDC o con el certificado administrativo (el que usas para la creación inicial de la 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 en VMware implementa tus cargas de trabajo en instancias de VMware, que se conectan a tus clústeres como nodos. En las siguientes secciones, se muestra cómo aprovechar las funciones de seguridad a nivel de nodo disponibles en GKE alojado en VMware.

Ubuntu

GKE en VMware 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 amplio conjunto de funciones de seguridad modernas, y GKE en VMware implementa varias funciones para mejorar la seguridad de los clústeres, incluidas las siguientes:

  • Las imágenes están preconfiguradas para cumplir con los estándares PCI DSS, NIST Baseline High y DoD Cloud Computing SRG Level 2.
  • Conjunto de paquetes optimizado.
  • Kernel de Linux adaptado a Google Cloud.
  • Actualizaciones de seguridad del SO opcionales.
  • Cuentas de usuario restringido y acceso raíz inhabilitado

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 frecuencia. Cuando actualizas el clúster, el software de cada nodo se actualiza a la última versión.

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 en el clúster, los hosts en los que se ejecutan y los servicios de Google Cloud habilitados en el 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 los procesos:

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

Ubuntu, el sistema operativo de nodo de GKE alojado en VMware predeterminado, aplica las políticas de seguridad de AppArmor de Docker predeterminadas a todos los contenedores que inicia 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

Registros de auditoría

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 tus entornos de GKE alojados en VMware. Los administradores pueden usar la información registrada a fin de realizar análisis forenses, crear alertas en tiempo real o catalogar cómo y quién usa una flota de clústeres de Kubernetes Engine.

De forma predeterminada, GKE en VMware 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.

Encriptación

Si tus clústeres y cargas de trabajo de GKE alojados en VMware se conectan de forma segura a los servicios de Google Cloud a través de Cloud VPN, puedes usar Cloud Key Management Service (Cloud KMS) para la administración de claves. 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 a Identity and Access Management (IAM) y Cloud Audit Logging de modo 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. De lo contrario, puedes usar una de las siguientes alternativas:

  • Secretos de Kubernetes
  • HashiCorp Vault
  • HSM de la red de Thales Luna
  • Módulo de seguridad de hardware (HSM) de Google Cloud

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 objetos 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