Introducción

Este artículo cubrirá cómo inyectar secretos en Pods usando Hashicorp Vault. En artículos anteriores, cubrimos cómo instalar Hashicorp Vault en Kubernetes, configurar y crear secretos en Hashicorp, y cómo herramientas como TIBCO BW pueden recuperarlos. Sin embargo, hoy vamos a dar un paso más allá.

La razón por la cual inyectar secretos en pods es muy importante es que permite que la aplicación dentro del pod sea transparente en torno a cualquier comunicación con Hashicorp. Después de todo, para las aplicaciones, el secreto será solo un archivo regular ubicado en una ruta específica dentro del contenedor. No necesita preocuparse si este archivo proviene de un Secreto de Hashicorp o de un recurso totalmente diferente.

Este enfoque de inyección facilita el enfoque poliglota del ecosistema de Kubernetes porque libera cualquier responsabilidad de la aplicación subyacente. Lo mismo ocurre con enfoques de inyección como Istio o mucho más.

Pero, expliquemos cómo funciona este enfoque para inyectar secretos en Pods usando Hashicorp Vault. Como parte de la instalación junto al servidor de vault que hemos instalado (o varios si has hecho una instalación distribuida), hemos visto otro pod bajo el nombre de value-agent-injector, como puedes ver en la imagen a continuación:

Este agente será responsable de escuchar los nuevos despliegues que realices y, basado en las anotaciones que tenga este despliegue, lanzará un sidecar junto a tu aplicación y enviará la configuración para poder conectarse al vault y descargar los secretos requeridos y montarlos como archivos dentro de tu pod como se muestra en la imagen a continuación:

Para hacer eso, necesitamos realizar varios pasos como parte de la configuración que vamos a incluir en las próximas secciones del artículo

Habilitando la Autenticación de Kubernetes en Hashicorp

Lo primero que necesitamos hacer en esta etapa es habilitar la Autenticación de Kubernetes en Hashicorp. Este método permite a los clientes autenticarse con un Token de Cuenta de Servicio de Kubernetes. Hacemos eso con el siguiente comando:

 Vault auth enable kubernetes

Vault acepta un token de servicio de cualquier cliente en el clúster de Kubernetes. Durante la autenticación, Vault verifica que el token de la cuenta de servicio sea válido consultando un endpoint de revisión de tokens de Kubernetes. Ahora, necesitamos configurar este método de autenticación proporcionando la ubicación de nuestra API de Kubernetes, y para hacer eso, necesitamos ejecutar el siguiente comando:

 vault write auth/kubernetes/config 
    kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443"

Definiendo una Cuenta de Servicio de Kubernetes y Definiendo una Política

Ahora, crearemos una Cuenta de Servicio de Kubernetes que ejecutará nuestros pods, y a esta cuenta de servicio se le permitirá recuperar el secreto que generamos en el artículo anterior.

Para hacer eso, comenzaremos con la creación de la cuenta de servicio ejecutando este comando desde fuera del pod:

kubectl create sa internal-app

Esto creará una nueva cuenta de servicio bajo el nombre de internal-app, y ahora vamos a generar una política dentro del servidor de Hashicorp Vault usando este comando dentro del pod del servidor de vault:

 vault policy write internal-app - <<EOF
path "internal/data/database/config" {
  capabilities = ["read"]
}
EOF

Y ahora, asociamos esta política con la cuenta de servicio ejecutando este comando también dentro del pod del servidor de vault:

  vault write auth/kubernetes/role/internal-app 
    bound_service_account_names=internal-app 
    bound_service_account_namespaces=default 
    policies=internal-app 
    ttl=24h

Y eso es prácticamente toda la configuración que necesitamos hacer en el lado de Vault para poder inyectar secretos en pods usando Hashicorp Vault. Ahora, necesitamos configurar nuestra aplicación en consecuencia haciendo las siguientes modificaciones:

• Especificar el ServiceAccountName en el despliegue para que sea el que creamos previamente: internal-app
• Especificar las anotaciones específicas para inyectar los secretos de vault y la configuración de esos secretos.
  

Comencemos con el primer punto. Necesitamos agregar el serviceAccountName a nuestro archivo YAML de Manifiesto de Kubernetes como se muestra a continuación:

Y con respecto al segundo punto, lo resolveríamos agregando varias anotaciones a nuestro despliegue, como se muestra a continuación:

Las anotaciones utilizadas para inyectar secretos en pods son las siguientes:

• vault.hashicorp.com/agent-inject: ‘true’: Esto le dice al inyector de vault que nos gustaría inyectar el agente sidecar en este despliegue y tener la configuración de Vault. Esto es necesario para hacer cualquier configuración adicional
• vault.hashicorp.com/role: internal-app: Este es el rol de vault que vamos a usar cuando solicitemos secretos e información al vault para asegurarnos de que solo accedemos a los secretos que hemos permitido según la política que creamos en la sección anterior
• vault.hashicorp.com/agent-inject-secret-secret-database-config.txt: internal/data/database/config: Esta será una anotación por cada secreto que planeamos agregar, y se compone de tres partes:
  
  • vault.hashicorp.com/agent-inject-secret- esta parte es fija
  • secret-database-config.txt esta parte será el nombre del archivo que se crea bajo /vault/secrets dentro de nuestro pod
  • internal/data/database/config Este es el camino dentro del vault de nuestro secreto para ser vinculado a ese archivo.
    

¡Y eso es todo! Si desplegamos ahora nuestro despliegue veremos las siguientes cosas:

• Nuestra aplicación de despliegue se ha lanzado con tres contenedores en lugar de uno porque dos de ellos están relacionados con Hashicorp Vault, como puedes ver en la imagen a continuación:

• vault-agent-init será el contenedor que establece la conexión con el servidor de vault porque cualquier contenedor comienza y realiza la primera descarga e inyección de secretos en el pod según la configuración proporcionada.
• vault-agent será el contenedor que se ejecuta como un observador para detectar cualquier modificación en los secretos relacionados y actualizarlos.

Y ahora, si vamos al contenedor principal, veremos en la ruta /vault/secrets que el secreto ha sido finalmente inyectado como se esperaba:

Y así es como fácilmente y sin ningún conocimiento sobre la aplicación subyacente podemos inyectar secretos en pods usando Hashicorp Vault.

Introduction

This article will cover how to inject secrets in Pods using Hashicorp Vault. In previous articles, we covered how to install Hashicorp Vault in Kubernetes, configure and create secrets in Hashicorp, and how tools such as TIBCO BW can retrieve them. Still, today, we are going to go one step ahead.

The reason why Inject secrets in pods is very important is that it allows the application inside the pod to be transparent around any communication to Hashicorp. After all, for the applications, the secret will be just a regular file located in a specific path inside the container. It doesn’t need to worry if this file came from a Hashicorp Secret or a total of different resources.

This injection approach facilitates the Kubernetes ecosystem’s polyglot approach because it frees any responsibility for the underlying application. The same happens with injector approaches such as Istio or much more.

But, let’s explain how this approach works to inject secrets in Pods using Hashicorp Vault. As part of the installation alongside the vault server we have installed (or several ones if you have done a distributed installation), we have seen another pod under the name of value-agent-injector, as you can see in the picture below:

This agent will be responsible for listening to the new deployments you do and, based on the annotations this deployment has, will launch a sidecar alongside your application and send the configuration to be able to connect to the vault and download the secrets required and mount it as files inside your pod as shown in the picture below:

To do that, we need to do several steps as part of the configuration as we are going to include in the upcoming sections of the article

Enabling Kubernetes Authentication in Hashicorp

The first thing we need to do at this stage is to enable the Kubernetes Authentication in Hashicorp. This method allows clients to authenticate with a Kubernetes Service Account Token. We do that with the following command:

 Vault auth enable kubernetes

Vault accepts a service token from any client in the Kubernetes cluster. During authentication, Vault verifies that the service account token is valid by querying a token review Kubernetes endpoint. Now, we need to configure this authentication method providing the location our the Kubernetes API, and to do that, we need to run the following command:

 vault write auth/kubernetes/config \
    kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443"

Defining a Kubernetes Services Account and Defining a Policy

Now, we will create a Kubernetes Service Account that will run our pods, and this service account will be allowed to retrieve the secret we generated in the previous post.

To do that, we will start with the creation of the service account by running this command from outside the pod:

kubectl create sa internal-app

This will create a new service account under the name of internal-app, and now we are going to generate a policy inside the Hashicorp Vault server by using this command inside the vault server pod:

 vault policy write internal-app - <<EOF
path "internal/data/database/config" {
  capabilities = ["read"]
}
EOF

And now, we associated this policy with the service account by running this command also inside the vault server pod:

  vault write auth/kubernetes/role/internal-app \
    bound_service_account_names=internal-app \
    bound_service_account_namespaces=default \
    policies=internal-app \
    ttl=24h

And that’s pretty much all the configuration we need to do at the Vault side to be able to inject secrets in pods using Hashicorp Vault. Now, we need to configure our application accordingly by doing the following modifications:

• Specify the ServiceAccountName to the deployment to be the one we created previously: internal-app
• Specify the specific annotations to inject the vault secrets and the configuration of those secrets.
  

Let’s start with the first point. We need to add the serviceAccountName to our Kubernetes Manifest YAML file as shown below:

And regarding the second point, we would solve it by adding several annotations to our deployment, as shown below:

The annotations used to inject secrets in pods are the following ones:

• vault.hashicorp.com/agent-inject: ‘true’: This tells the vault injector that we would like to inject the sidecar agent in this deployment and have the Vault configuration. This is required to do any further configuration
• vault.hashicorp.com/role: internal-app: This is the vault role we are going to use when we’re asking for secrets and information to the vault to be sure that we only access the secrets we have allowed based on the policy we created in the previous section
• vault.hashicorp.com/agent-inject-secret-secret-database-config.txt: internal/data/database/config: This will be one annotation per secret we plan to add, and it is composed of three parts:
  
  • vault.hashicorp.com/agent-inject-secret- this part is fixed
  • secret-database-config.txt this part will be the filename that is created under /vault/secrets inside our pod
  • internal/data/database/config This is the path inside the vault of our secret to being linked to that file.
    

And that’s it! If we deploy now our deployment we will see the following things:

• Our deployment application has been launched with three containers instead of one because two of them are Hashicorp Vault related, as you can see in the picture below:

• vault-agent-init will be the container that establishes the connection to the vault-server because any container starts and does the first download and injecting secrets in the pod based on the configuration provided.
• vault-agent will be the container running as a watcher to detect any modification on the related secrets and update them.

And now, if we go to the main container, we will see in the /vault/secrets path the secret has been finally injected as expected:

And this is how easily and without any knowledge about the underlying app we can inject secrets in pods using Hashicorp Vault.