HashiCorp Vault provides secure access to secrets and manages sensitive information. In an earlier post, we described how HashiCorp Vault can be used to manage secrets in Kubernetes using Nirmata. Since then Vault’s support for Kubernetes has evolved. HashiCorp has released the Vault Agent Injector which automates the process of fetching the relevant secrets from Vault using a sidecar container that is added to a pod. Nirmata fully supports this capability. However, the process of bootstrapping newly created clusters for Vault remained a manual process with multiple steps that had to be coordinated across Vault and the new cluster. In this post, I will describe how Nirmata now fully automates the configuration of Vault for new Kubernetes clusters.

In an enterprise, usually multiple Kubernetes clusters are used and secrets management is required for all these clusters. Typically, a central Vault application service is deployed, either in one of the management / shared Kubernetes clusters. Before you can start using Vault in your Kubernetes cluster, a Kubernetes Auth method for your cluster needs to be configured in Vault, with cluster specific information such as the JWT token for a role that Vault can use to securely access the cluster. The steps for this process are described in the Vault documentation. Once the Kubernetes auth method is set up in Vault, the path information then needs to be configured in the new cluster so that workloads can connect to the right authentication path.

If you have development teams deploying clusters on-demand, it is cumbersome to manually configure the Kubernetes auth method for each cluster. This requires automation so that as soon as new clusters are provisioned, the Kubernetes auth path is configured in Vault.

Nirmata automates the creation of Kubernetes auth path in Vault whenever a new cluster is created. Nirmata has added native integration with Vault to enable this capability. You can add information about your Vault installation in the Integration -> Vault panel in Nirmata. 

Next, when creating a cluster type (a reusable policy with common cluster configuration), you can provide the configuration for your Kubernetes auth path along with default roles that you would like to configure for the cluster. In the auth path, you can use variable ${cluster.name} to include the cluster name in the auth path. This ensures that a unique auth path is created for each cluster.

You can also add the vault agent injector as an add-on in your cluster type so that it is deployed automatically on each cluster. Now, whenever a new cluster is created using this cluster type, Nirmata will automatically configure the auth path in Vault along with the specified roles. Nirmata will also deploy the vault agent injector so that you can immediately start using Vault for secrets management.

As a result of the automatic configuration of Vault, it is now possible to deliver secrets management capabilities for every cluster that is deployed using Nirmata or registered with Nirmata. This also allows automating the deployment of other add-on services such as agents for security, monitoring, and logging, that require credentials to authenticate with their service endpoints. Now, with Nirmata and HashiCorp Vault you can deliver fully configured clusters on-demand or facilitate self-service provisioning of Kubernetes clusters.