Despliegue Zero Trust con HashiCorp - HashiCorp Solutions Engineering Blog - Medium

El concepto Zero Trust (o su traducción “Cero Confianza”) debería considerarse parte esencial de cualquier despliegue multi-cloud, donde cualquier workload escala de manera continua. En este contexto completamente dinámico la “Identidad” juega un papel crucial para la autenticación y autorización.

Zero Trust se puede implementar en diferentes escenarios como el desarrollo de aplicaciones, el aprovisionamiento de infraestructura, conectividad de servicios, autenticación de personas, etc. Si atendemos a la definición de arquitecturas Zero Trust definidas por el NIST (National Institute of Standards of Technology), encontramos diferentes conceptos básicos, pudiendo agruparlos en tres principios aseguir:

• Menor privilegio. Todo debe estar gobernado por el principio del menor privilegio, por lo que cualquier sistema o persona debe acceder únicamente al recurso requerido o necesario.
• No confiar. Siempre se autenticará y autorizará cualquier tipoacceso.
• Asumir el fallo. Se deben tomar las acciones de defensa y prevención asumiendo que van a atacar nuestro entorno y van a acceder a nuestros datos sensibles, por lo que es necesario poder responder o revocar en tiempo cualquier amenaza.

En esta serie de artículos -o blog posts series- mostraremos cómo gran parte de las tecnologías de HashiCorp y su integración, como Vault, Consul y Waypoint, se basan de manera nativa en estos principios, ayudando a dar un soporte adecuado en el momento de desplegar y ejecutar nuestras aplicaciones y sus flujos de trabajo asociados.

Despliegue y ejecución

Pongamos el caso de una aplicación compuesta por diferentes microservicios que se van a desplegar en un cluster de Kubernetes.

Como ejemplo se utilizará nuestra famosa aplicación de demostración HashiCups (a la que personalmente me gusta llamar HashiCafé), que simulará un portal básico de pedidos de café online. Esta aplicación está compuesta por los siguientes microservicios:

• Servicio Payments, el cual gestiona los datos de pago y simula su procesamiento
• Una base de datos Redis, utilizada por Payments para gestionar los datos depago
• Un servicio API de producto, Product-API, el cual expone un API para gestionar los productos de café desde la aplicación
• Base de datos de producto, Product-DB (servicio postgres en nuestro ejemplo), la cual almacena y gestiona los productos de café disponibles y la información deusuario
• API público, Public-API, utilizado por el front-end para realizar las transacciones de usuario de selección y compra delproducto
• Un servicio Front-End, que expone la aplicación web al usuariofinal.

La pregunta a hacerse es: ¿Cómo se puede construir, desplegar y ejecutar esta aplicación en un cluster de Kubernetes con un foco Zero Trust, siguiendo sus principios?

Considerando el despliegue y ejecución, y posteriormente la conectividad de los servicios, a continuación tenemos un diagrama de alto nivel de un posible despliegue Zero Trust utilizando las herramientas de HashiCorp:

He creado un repositorio en GitHub, que replica este despliegue utilizando las herramientas de automatización de HashiCorp.

Resumiendo, estos serían los componentes clave de esta solución de despliegue considerando los principios ZeroTrust:

• HashiCorp Vault como almacén centralizado de secretos y encriptación como servicio. Cualquier credencial de nuestros microservicios se gestionará en Vault. Secretos como credenciales de base de datos se generarán de manera dinámica, y se inyectarán automáticamente en nuestros pods de Kubernetes. También, los datos sensibles de nuestro servicio Payments se cifran en la BBDD y descifran desde la misma (DB encryption/decryption) mediante Vault Transit Engine. Vault, en estos casos siempre utilizará la Identidad de Kubernetes para la autenticación y autorización del acceso a los secretos y las llaves de cifrado. Esto será posible mediante la gestión de las políticas de acceso (ACLs) que Vault por defecto utiliza con el principio de Menor Privilegio (Least Privilege).
• HashiCorp Waypoint para el despliegue de los microservicios y la inyección de variables sensibles. Utilizando la integración nativa con Vault como almacenamiento centralizado de secretos, Waypoint es capaz de inyectar estas variables de entorno en el despliegue de las aplicaciones, evitando cualquier definición en texto plano de nuestras plantillas (manifests) de los microservicios.
• HashiCorp Consul para reforzar la seguridad y autorización de la conectividad de los microservicios. Utilizando Consul Service Mesh se realizará la conexión “mutual TLS” (mTLS) cuando esté definido el permiso de conexión de un microservicio a otro. Será mediante las Consul Intentions la manera de gestionar fácilmente la conectividad de los microservicios, sólo permitiendo las conexiones específicas mediante la definición de “intenciones” de conexión para nuestra aplicación.

En base a estos principios, desarrolladores y operadores sólo tendrán que preocuparse de desplegar y ejecutar las aplicaciones según la identidad específica de los microservicios. En este caso, cuentas de servicio de Kubernetes en el namespace determinado. No tendrán que preocuparse de cómo definir variables sensibles en el código o plantillas YAML (manifests). Sólo tendrán que conocer la dirección de Vault y el “endpoint” específico de la referencia del secreto enVault.

Cómo se implementa

En siguientes episodios o posts de esta serie de varios artículos entraremos de manera detallada en la implementación de nuestro repositorio de ejemplo. Y también cómo proponer algunas mejoras o cambios para implementar la aproximación ZeroTrust.

Pero veamos un avance de algunos ejemplos de esta implementación. Por ejemplo, pensemos en nuestro microservicio “product-api” (API de producto), que necesitará acceder con un usuario y una contraseña mediante la definición de un “string” o cadena de conexión a la base de datos PostgreSQL, donde se almacena el catálogo de productos decafé.

En Kubernetes, se podría definir un objeto ConfigMap para montarlo en el Pod del servicio. Sería algo como lo siguiente sin tener en cuenta el concepto ZeroTrust:

apiVersion: v1
kind: ConfigMap
metadata:
 name: db-configmap-template
 namespace: {{ .Values.namespace }}
 labels:
 app: productapi
data:
 config: |
 {
 “db_connection”: “host=postgres port=5432 user=postgres password=password dbname=products sslmode=disable”,
 “bind_address”: “:9090”,
 “metrics_address”: “:9103”
 }

Es evidente que esto es completamente inseguro (no tengamos en cuenta el password utilizado, ya que es sólo a nivel de demostración). Esta definición YAML del ConfigMap tiene los valores del usuario y contraseña de la base de datos en texto plano (hard coded), lo que puede llevar a serias implicaciones de seguridad y consecuencias. No sería la primera vez que acaba en un repositorio de código público, por ejemplo. También otros datos de conexión como el puerto y el host están definidos de manera estática, por lo que si la configuración del servicio postgres de base de datos cambia, nuestro ConfigMap de product-api tiene que desplegarse de nuevo, o modificarse en “producción”.

Pongamos a continuación entonces el ejemplo dinámico y con foco Zero Trust del ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
 name: db-configmap-template
 namespace: {{ .Values.namespace }}
 labels:
 app: productapi
data:
 config: |
 {{ “{{“ }} range service “postgres” {{ “}}” }}
 {
 “db_connection”: “host={{ “{{“ }} .Name {{ “}}” }} port={{ “{{“ }} .Port {{ “}}” }} {{ “{{“ }} with secret “database/creds/hashicups-db” {{ “}}” }}user={{ “{{“ }} .Data.username {{ “}}” }} password={{ “{{“ }} .Data.password {{ “}}” }}{{ “{{“ }}end{{ “}}” }} dbname=products sslmode=disable”,
 “bind_address”: “:9090”,
 “metrics_address”: “:9103”
 }
 {{ “{{“ }} end {{ “}}” }}

En este caso se puede observar que no hay definición ni valores estáticos de nuestras credenciales y parámetros de conexión para desplegar el servicio. Hay dos puntos importantes a considerar en esteejemplo:

• Vault gestiona el usuario y contraseña de manera dinámica, por lo que nuestro ConfigMap sólo necesita el path del secreto en Vault database/creds/hashicups-db y la definición de los campos.Data.username y.Data.password, que Vault va a devolver cuando genera automáticamente las credenciales de la base de datos con los permisos adecuados. La credencial dinámica es posible gracias a la utilización del motor de secretos Dynamic Database Secret Engine enVault.
• Nuestros microservicios son parte del catálogo de servicios de Consul y del Service Mesh, monitorizando la salud de los mismos. Se puede obtener por tanto automáticamente y de manera dinámica el puerto y host del servicio requerido, desde el registro de servicios de Consul, mediante la referencia.Name y.Port.

Se utiliza Consul Template como sidecar para configurar dinámicamente los datos del ConfigMap, obteniendo los valores desde Consul y Vault. Y la manera de autenticar se realiza mediante la identidad de la cuenta de servicio de Kubernetes, a través de la inyección del Vault Agent para la obtención y renovación del token de autenticación de Vault. Todo esto se configura mediante anotaciones de Kubernetes en el objeto Deployment, como se muestra a continuación:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: product-api
 namespace: {{ .Values.namespace }}
 labels:
 app: productapi
spec:
 …

…
 template:
 metadata:
   labels:
     app: productapi
   annotations:
     prometheus.io/scrape: “true”
     prometheus.io/port: “9102”
     vault.hashicorp.com/agent-inject: “true”
     vault.hashicorp.com/agent-inject-token: “true”
     vault.hashicorp.com/role: “hashicups”
     vault.hashicorp.com/agent-init-first: “true”
     consul.hashicorp.com/connect-inject: “true”
 spec:
   serviceAccountName: product-api

…

…

Este es un ejemplo, entre otros, de nuestra aplicación de “demo”. También, se utiliza Waypoint para configurar las variables de entorno de los contenedores durante el despliegue. Se configuran dinámicamente desde los valores almacenados y securizados enVault.

Por qué este ejemplo es ZeroTrust

El ejemplo de aplicación anteriormente propuesto pretende mostrar la aproximación del despliegue “no-confiable” mediante la adopción de los tres principios básicos explicados al inicio de este artículo:

• Vault es la pieza angular de la gestión de datos sensibles. Se encarga de la autorización de acceso a cualquier información sensible utilizada por los microservicios de la aplicación, como credenciales de la base de datos o acceso a las llaves de cifrado para cifrar o descifrar en tránsito los datos de pago. Las políticas ACL restringen el acceso para el token determinado (perteneciente a la identidad autenticada) a sólo la ruta específica y necesaria del secreto a utilizar. Aplica entonces el principio de menor privilegio.
• Todo se autentica mediante la identidad de Kubernetes y sus cuentas de servicio, autorizando el acceso a través de las políticas de Vault para los secretos y las “Intentions” de Consul en el caso de conectividad entre servicios. También Waypoint delega a Vault la autenticación y autorización del acceso a los valores que van a ser inyectados en variables de entorno que pueden ser sensibles durante el despliegue y ejecución.
• Si cualquier credencial se ve comprometida, se puede gestionar la revocación de secretos o sesiones desde Vault. También se puede restringir la conectividad entre los microservicios denegando la “intención” de conexión gestionada por Consul. Esto significa que se asume cualquier fallo o acceso no requerido ofreciendo un mecanismo rápido y centralizado de revocación para la gestión de secretos y conectividad del servicemesh.

Como se puede observar, se están adoptando los principios Zero Trust mediante la utilización e integración nativa de Vault, Consul y Waypoint para el despliegue de la aplicación.

A continuación se muestra un ejemplo de la política de Vault utilizada para restringir el acceso únicamente a los secretos y llaves necesarias para nuestros microservicios:

Y como ejemplo de la conectividad de microservicios sólo permitidas y autorizadas se puede ver en la siguiente configuración las “intenciones” deConsul:

Extendiendo el caso deuso

En este artículo hemos cubierto la fase de despliegue y ejecución de los microservicios con una adopción Zero Trust. Pero se puede extender el caso de uso considerando el aprovisionamiento previo de la infraestructura, donde el cluster de Kubernetes y la infraestructura Cloud es desplegada. También posteriormente, en una fase de operación, se puede gestionar la actualización, por ejemplo, del catálogo de la base de datos, requiriendo un acceso de los administradores u operadores. Tendríamos un diagrama de alto nivel como el siguiente:

Encontramos nuevas piezas en estafoto:

• Un motor de CI/CD, encargado de la orquestación del ciclo de vida completo de despliegue/entrega. Aquí se utiliza Jenkins como ejemplo, pero podría ser cualquier otro como GitLab CI, GitHub Actions, Tekton, etc. En este caso Jenkins delega la gestión de credenciales de los “pipelines” a Vault, ya que es necesario utilizar los tokens de acceso para Terraform Cloud y Waypoint.
• HashiCorp Terraform para el aprovisionamiento de infraestructura. Utilizará la integración con Vault para gestionar las credenciales necesarias del aprovisionamiento de infraestructura Cloud, y lo hará con credenciales dinámicas y efímeras. Usando, por ejemplo, el motor de secretos del Cloud determinado (GCP, Azure, AWS,etc)
• HashiCorp Boundary para la gestión de acceso de los usuarios para operaciones de los sistemas de backend. Boundary gestionará la autenticación y autorización “persona-a-sistema”, integrado con Vault para proveer de credenciales de vida corta que sean renovadas automáticamente cuando sea necesario

En siguientes episodios de esta serie cubriremos algunos de los detalles de la configuración de nuestro “Zero TrustDemo”:

• Inyección de secretos y datos de servicio con Vault yConsul
• Seguridad del despliegue con Waypoint yVault
• Despliegue “Zero Trust service mesh” con Consul yWaypoint

Despliegue Zero Trust con HashiCorp was originally published in HashiCorp Solutions Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

本文章由 flowerss 抓取自RSS，版权归源站点所有。

查看原文：Despliegue Zero Trust con HashiCorp - HashiCorp Solutions Engineering Blog - Medium