Plano de seguridad de Anthos: administra secretos

En este documento, se describe cómo implementar un sistema de administración de secretos que puedes usar para administrar secretos de Kubernetes en todos tus clústeres de Anthos y se describen los controles que usas para esta tarea.

El documento es parte de una serie de planos de seguridad que proporcionan orientación prescriptiva para trabajar con Anthos.

Introducción

Por lo general, trabajar con aplicaciones requiere que administres los Secrets. Un Secret es un objeto que contiene una pequeña cantidad de datos sensibles, como una contraseña, un token o una clave.

Cuando trabajas con clústeres de Anthos, necesitas administrar los Secrets de Kubernetes. En Anthos, los Secrets de Kubernetes se usan para acceder a la API de Kubernetes. También se usan en la capa de la aplicación, por ejemplo, para permitir que tus servicios se comuniquen con una base de datos de backend.

Para evitar el acceso no autorizado a tus aplicaciones y a los datos sensibles, puedes usar un sistema de administración de Secrets. Un sistema de administración de Secrets almacena secretos para que tus aplicaciones los usen y administra los permisos de acceso a ellos.

Para administrar claves y secretos, debes considerar lo siguiente:

  • Si administras un entorno híbrido que ejecuta clústeres en alguna combinación de Google Cloud, de forma local y otra nube.
  • Si ejecutas Anthos solo en Google Cloud
  • ¿Cuál es tu modelo de amenazas y cuáles son los requisitos de encriptación en función de ese modelo de amenaza? Por ejemplo, ¿necesitas dos capas de encriptación, como la encriptación en el disco completo y la encriptación en la capa de aplicación?
  • Cómo rotar claves de forma regular para limitar el impacto en el caso de que se vulnere una clave.
  • Cómo separar la administración de claves de la administración de Secrets y mantener una raíz de confianza.
  • Cómo auditar el uso de una clave.
  • Lo que tiene repercusiones si tu sistema de administración de Secrets o sistema de administración de claves no está disponible y si necesitas implementar un sistema de administración de secretos con alta disponibilidad.

El repositorio de GitHub asociado con este plano contiene un directorio de administración de secretos. El contenido de ese directorio proporciona instrucciones sobre cómo configurar un clúster de HashiCorp Vault con alta disponibilidad en GKE como un sistema de administración de secretos que puedes usar con clústeres de Anthos.

Información sobre los controles de seguridad que necesitas

En esta sección, se analizan los controles que necesitas para implementar un sistema de administración de Secrets. En el enfoque analizado en este documento, se usa HashiCorp Vault para la administración de secretos y Cloud Key Management Service (Cloud KMS) para la administración de claves. El enfoque contempla las consideraciones enumeradas en la sección anterior. En esta sección, también se analizan los controles que puedes usar para administrar cuentas de servicio con el motor de Secrets hash de Google Cloud. Un motor de Secrets es un componente que puede almacenar y leer datos, generar credenciales y encriptar datos.

En el siguiente diagrama, se ilustra cómo interactúan Vault y Cloud KMS para proporcionar una administración de secretos y administración de claves.

Arquitectura de la administración de Secrets y la administración de claves

En el diagrama, se muestra cómo Cloud KMS y Vault trabajan juntos para hacer lo siguiente:

  1. Actúa como el proveedor de servicios de administración de claves para administrar una clave de encriptación de claves (KEK).
  2. Actúa como un motor de Secrets para claves y encriptación.
  3. Actuar como proveedor de servicios de administración de claves para administrar una KEK
  4. Actúa como un motor de secretos para la administración de cuentas de servicio (Vault).
  5. Integra Secrets directamente en HashiCorp Vault.

HashiCorp Vault

Administra Secrets de manera centralizada

Vault de HashiCorp es un administrador de Secrets de código abierto que puede funcionar con Kubernetes para administrar los Secrets de Kubernetes. Vault viene con varios motores secretos, incluidos los motores Secrets para Google Cloud y Cloud KMS.

Vault funciona en un modelo de cliente-servidor en el que un clúster central de servidores de Vault almacena y mantiene Secrets, y los clientes acceden a los datos a través de una API, una interfaz de línea de comandos o una interfaz web. Vault encripta todos los datos en tránsito con TLS 1.2 o versiones posteriores y encripta todos los datos en reposo mediante la encriptación CBC de 256 bits. Si tienes una licencia empresarial, Vault también se puede actualizar para que una organización cumpla con el estándar FIPS 140-2 del Gobierno de EE.UU.

Te recomendamos que ejecutes Vault en su propio clúster de GKE dedicado en un proyecto dedicado.

Cuando usas Vault con las aplicaciones de clústeres de Anthos, tus aplicaciones pueden usar el método de autenticación de Kubernetes de la siguiente manera:

  1. Los pods envían su token de cuenta de servicio de Kubernetes.
  2. Vault verifica el token en función del plano de control de Kubernetes.
  3. Vault asigna la identidad a una política y a permisos.
  4. Vault muestra un token de Vault a la aplicación.

La aplicación puede usar el token para autenticarse con los permisos adecuados.

En el siguiente diagrama, se ilustra el proceso descrito en la lista anterior.

Usa Vault para obtener credenciales

Administra credenciales de corta duración para tus aplicaciones y desarrollo local

Cuando habilitas lasMotor de Secrets de HashiCorp de Google Cloud como motor de secretos para tus clústeres, puedes generar de forma dinámica claves de cuenta de servicio de Google Cloud y tokens OAuth basados en políticas de administración de identidades y accesos (IAM). Las aplicaciones que se implementan en tus clústeres de Anthos pueden usar estas claves o tokens como credenciales a corto plazo.

Además, puedes usar el motor de secretos de Google Cloud de HashiCorp para administrar de forma automática las cuentas de servicio de Google Cloud y las claves de cuenta de servicio asociadas que tus desarrolladores pueden usar cuando trabajan en sus estaciones de trabajo locales. Debes otorgar a los desarrolladores acceso a los archivos JSON de la cuenta de servicio para que puedan escribir y depurar aplicaciones que usen los recursos de Google Cloud. (Cuando las personas se autentican en los servicios de Google Cloud, siempre deben usar sus propias cuentas en lugar de usar cuentas de servicio, que están diseñadas para aplicaciones).

El uso del motor de secretos de Google Cloud de HashiCorp para administrar cuentas de servicio y tokens OAuth proporciona los siguientes beneficios:

  • Debido a que cada cuenta de servicio está asociada con una asignación de tiempo de Vault, la clave de la cuenta de servicio se revoca automáticamente cuando vence la asignación.
  • Los usuarios no necesitan crear cuentas de servicio para las credenciales de acceso a corto plazo. Vault se encarga de crear tokens de OAuth y la cuenta de servicio asociada.
  • En las configuraciones híbridas, los usuarios pueden autenticarse en Vault mediante su proveedor de identidad. El proveedor de identidad puede generar credenciales de Google Cloud para el usuario sin necesidad de crear o administrar una cuenta de servicio nueva para ese usuario.

Cloud KMS

Administra claves para los servicios en la nube

Cloud Key Management Service (Cloud KMS) es un servicio de administración de claves alojado en la nube que te permite administrar las claves criptográficas de tus servicios de nube de la misma manera que lo haces en tus instalaciones locales. Puedes generar, usar y rotar claves criptográficas que usan algoritmos de claves populares. Cloud KMS está integrado en IAM y Cloud Audit Logging para que puedas administrar permisos en claves individuales y supervisar cómo se usan. Puedes implementar una jerarquía de claves mediante una clave de encriptación de datos local (DEK) protegida a su vez por una clave de encriptación de claves (KEK) en Cloud KMS.

Cuando configuras HashiCorp Vault por primera vez, debes especificar el almacenamiento físico de los datos (Secrets), pero el software no estará configurado para desencriptarlos. En este estado, Vault se denomina sellado. A fin de desencriptar los datos, Vault necesita la clave de encriptación principal de modo que esta se pueda usar para desencriptar la clave de encriptación que, a su vez, se usa con el fin de desencriptar los datos almacenados en Vault. El proceso para acceder a esta clave de encriptación de la instancia principal se conoce comoanulación de sellos , En este plano, las claves para anulación de sellos se encriptan con Cloud KMS y se almacenan en Cloud Storage.

Kubernetes usa el almacén de pares clave-valor etcd como almacén de respaldo para los datos de configuración, los datos de estado y los metadatos de un clúster. Después de seguir las pautas de endurecimiento para configurar el clúster de Anthos, se habilita la encriptación de la capa de almacenamiento. Sin embargo, de forma predeterminada, los datos de etcd no se encriptan a nivel de la aplicación. Si un usuario pudiera obtener acceso no autorizado a una copia sin conexión del almacén etcd, se podría acceder a los datos sin encriptar. Por lo tanto, una práctica recomendada para protegerte contra este vector de ataque es agregar una capa de seguridad a la capa de la aplicación. Para hacerlo, debes encriptar los secretos mediante un servicio de administración de claves externo.

El motor de secretos KMS de Google KMS proporciona encriptación y administración de claves que usa Cloud KMS. El motor de secrets es compatible con la administración de claves, incluidas la creación, la rotación y la revocación. También admite la encriptación y desencriptación de datos mediante claves administradas. El motor de secretos de Google KMS te permite administrar claves de KMS mediante políticas de Vault y IAM.

Cloud KMS está integrado a Cloud Logging. Cloud KMS escribe registros de auditoría de actividad del administrador, en los que se asientan las operaciones que modifican la configuración o los metadatos de un recurso. Por ejemplo, los registros de auditoría de actividad del administrador registran cuando se crea o se destruye un llavero de claves, o cuando se establece la política de control de acceso IAM para un proyecto. Los registros de auditoría de actividad del administrador siempre están habilitados; no puedes inhabilitarlos.

Cloud KMS también puede escribir registros de auditoría de acceso a los datos. Las auditorías de acceso a los datos graban las llamadas a la API que leen la configuración o los metadatos de los recursos, así como llamadas a la API que controla el usuario y que crean, modifican o leen los datos de los recursos que proporciona el usuario. Por ejemplo, registran cuándo se desencripta una clave, cuando se realiza una llamada para desencriptar una clave o cuando se realiza una llamada para leer la política de IAM de un proyecto. Los registros de auditoría de acceso a los datos están inhabilitados de forma predeterminada y no se escriben, a menos que los habilites explícitamente.

Para obtener más información sobre las operaciones que se pueden auditar en Cloud KMS, consulta operaciones auditadas en la documentación de Cloud KMS.

Almacena secretos en el backend

Vault de HashiCorp tiene un sistema de almacenamiento conectable que te permite especificar dónde deseas que los datos se conserven en reposo. Para el backend de Vault, recomendamos Cloud Storage, el servicio de almacenamiento de objetos escalable y de alta durabilidad de Google, debido a su alto rendimiento, bajo costo y compatibilidad con una alta disponibilidad.

Cloud Spanner es la base de datos de Google distribuida en conformidad con el ACID que administra de forma automática las réplicas, la fragmentación y el procesamiento de transacciones. Para requisitos de carga de trabajo intensos, recomendamos Cloud Spanner como backend de almacenamiento alternativo de Cloud Storage en tu configuración de Vault.

Encriptación en el nivel de almacenamiento

Encriptación en reposo para los clústeres

Tus clústeres de Anthos se implementan en VM. Las VM están configuradas para proporcionar encriptación de la capa de almacenamiento. Las VM de GKE están encriptadas en la capa de almacenamiento de forma predeterminada, lo que incluye el contenido del almacén de pares clave-valor etcd.

Para los clústeres de Anthos en VMware, te recomendamos que configures los clústeres a fin de usar la encriptación de vSphere. Esto proporciona protección de encriptación en reposo para los secretos.

De forma predeterminada, los secretos no están encriptados aún más. Debes usar un administrador de secretos para obtener encriptación a nivel de aplicación.

Revisión general

Puedes integrar los controles descritos anteriormente para lograr un sistema con alta disponibilidad que realice las siguientes acciones:

  • Separar la administración de claves de la administración de secretos.
  • Mantener una raíz de confianza.
  • Proporcionar una forma de rotar las claves con regularidad para limitar el impacto en el caso de que una clave se vulnere.
  • Proporcionar una manera de encriptar datos en la capa de aplicación.

En el siguiente diagrama, se muestra la arquitectura del sistema.

Arquitectura del sistema de administración de secretos.

En esta arquitectura, los servidores de Vault se implementan en un clúster de GKE dedicado. Se usa un bucket de Cloud Storage para almacenar las claves. Cloud KMS ofrece administración de claves para las claves que se usan para encriptar los secretos en la capa de la aplicación y también administrar las claves para encriptar la clave que se usa con el fin de sellar o separar los Vault.

Para implementar esta arquitectura, debes hacer lo siguiente:

  1. Crea un proyecto de Google Cloud en el que configures Vault. Este proyecto es independiente del proyecto para tus aplicaciones.
  2. Crea un Cloud KMS llavero de claves y clave criptográfica adecuado para encriptar y desencriptar Vault claves maestras y tokens de raíz.
  3. Crea un clúster de GKE para implementar Vault en la guía de endurecimiento del clúster aplicable (GKE o clústeres de Anthos alojados en VMware).
  4. Implementa Vault en el clúster de GKE
  5. Habilita el motor de secretos HashiCorp de Google Cloud para administrar las credenciales de corta duración.
  6. Habilita el motor de secretos KMS de Google de HashiCorp a fin de proporcionar un sistema que pueda habilitar la encriptación de sobre para la encriptación de la capa de la aplicación de los secretos de tu clúster de Kubernetes.