Streamlining Secret Injection in Pods with Hashicorp Vault
Written on
Chapter 1: Introduction to Secret Injection
In this article, we will explore the process of injecting secrets into Pods utilizing Hashicorp Vault. Previous discussions have focused on installing Hashicorp Vault within Kubernetes, setting up secrets, and detailing how tools like TIBCO BW can access them. Today, we will delve deeper into the injection process.
The significance of injecting secrets into Pods lies in the transparency it offers to applications within those Pods regarding their communication with Hashicorp Vault. For these applications, the secret appears as a standard file located in a predetermined path within the container, eliminating the need to differentiate between files sourced from Hashicorp or other resources.
This method enhances the polyglot nature of the Kubernetes ecosystem by removing the burden from the applications. Similar benefits are seen with other injection techniques, such as Istio.
To comprehend how secret injection works in Pods with Hashicorp Vault, we first need to understand the role of the value-agent-injector pod, which is installed alongside the Vault server (or multiple servers in a distributed setup). This agent monitors new deployments and, depending on the deployment's annotations, launches a sidecar with the application to facilitate the connection to the Vault and download necessary secrets, which are then mounted as files within the Pod.
Chapter 2: Configuring Hashicorp Vault for Kubernetes
Section 2.1: Enabling Kubernetes Authentication
To initiate the configuration, we must first enable Kubernetes Authentication within Hashicorp Vault. This method permits clients to authenticate using a Kubernetes Service Account Token. We can accomplish this with the following command:
vault auth enable kubernetes
Vault accepts service tokens from any client within the Kubernetes cluster. During the authentication phase, Vault verifies the token's validity by querying the token review endpoint in Kubernetes. Next, we configure this authentication method by specifying the location of our Kubernetes API with the following command:
vault write auth/kubernetes/config
Section 2.2: Creating a Kubernetes Service Account and Policy
Next, we will create a Kubernetes Service Account that will execute our Pods and be authorized to retrieve the secrets we defined earlier. This is achieved by running the following command outside the Pod:
kubectl create sa internal-app
This command generates a new service account named internal-app. We will then create a policy within the Hashicorp Vault server using the command below:
vault policy write internal-app - <
Now, we associate this policy with the service account by executing the following command within 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
This completes the configuration on the Vault side, allowing us to inject secrets into Pods using Hashicorp Vault. Now, we need to adjust our application settings accordingly.
Section 2.3: Modifying the Application Deployment
To begin, we will set the serviceAccountName in our Kubernetes Manifest YAML file to the previously created service account internal-app. Additionally, we will add the required annotations for injecting the Vault secrets.
The necessary annotations for secret injection in Pods include:
- vault.hashicorp.com/agent-inject: 'true': This instructs the Vault injector to inject the sidecar agent into this deployment.
- vault.hashicorp.com/role: internal-app: This specifies the Vault role to use when requesting secrets, ensuring access is limited based on the previously established policy.
- vault.hashicorp.com/agent-inject-secret-secret-database-config.txt: internal/data/database/config: Each secret requires a separate annotation, formatted as follows:
- vault.hashicorp.com/agent-inject-secret- (fixed prefix)
- secret-database-config.txt (the filename created under /vault/secrets in the Pod)
- internal/data/database/config (the path in Vault where the secret is stored)
With these configurations set, deploying our application will yield three containers instead of one, as the two additional containers are related to Hashicorp Vault.
- vault-agent-init: This container establishes the connection to the vault-server, initiating the secret download and injection process based on the provided configuration.
- vault-agent: This container functions as a watcher to detect any changes to the related secrets and update them accordingly.
Finally, we can verify that the secret has been injected as expected by checking the /vault/secrets directory in the main container.
In summary, this demonstrates how effortlessly we can inject secrets into Pods using Hashicorp Vault without requiring in-depth knowledge of the underlying application.