HashiCorp has moved the HashiCorp Vault Secrets Operator for Kubernetes into general availability. This Kubernetes Operator combines Vault's secret management tooling with the Kubernetes Secrets cache. The operator also handles secret rotation and has controllers for the various secret-specific custom resources.
The Vault Secrets Operators watches for changes to its set of Custom Resource Definitions (CRDs). Each CRD allows for the operator to synchronize a Vault Secret to a Kubernetes Secret. This operator writes the source Vault secret directly to the destination Kubernetes secret. This ensures that all changes made to the source are properly replications and uses Kubernetes custom resources to manage secrets used by services. Applications are able to consume the secrets in a Kubernetes-native manner from the destination.
The operator supports all of the supported Secret customer resources (CRs) including VaultConnection, VaultAuth, VaultDynamicSecret, and VaultPKISecret. This example shows leveraging the VaultConnection CR:
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultConnection
metadata:
namespace: vso-example
name: example
spec:
# address to the Vault server.
address: http://vault.vault.svc.cluster.local:8200
In this example, the VaultDynamicSecret CR is used with the database secret engine. The following example creates a request to http://127.0.0.1:8200/v1/db/creds/my-postgresql-role to create a new credential:
---
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultDynamicSecret
metadata:
namespace: vso-example
name: example
spec:
vaultAuthRef: example
mount: db
path: creds/my-postgresql-role
destination:
create: true
name: dynamic1
A number of new features were included in the GA release including the addition of a number of new authentication methods. Previously, only the Kubernetes authentication method was available. With the GA release, there is now support for JSON Web Token (JWT), AppRole, and AWS as authentication methods.
The GA release also includes validations for common Kubernetes cloud services such as AKS, GKE, EKS, and OpenShift. Another new enhancement has the Vault Secrets Operator attempt to revoke any cached Vault client tokens when the deployment is deleted.
All Vault secrets engines are supported as is TLS/mTLS communication with Vault. Secret rotation is supported for Deployment, ReplicaSet, and StatefulSet Kubernetes resource types. Rotating a static secret can be done using:
vault kv put kvv2/webapp/config username="static-user2" password="static-password2"
Deployment of the operator is supported via a Helm chart and through Kustomize. Once deployed, the operator does require a number of permissions. These include permissions on the Secret, ServiceAccount, and Deployment objects. Access can be restricted as needed to objects within specified namespaces.
Secrets stored directly in Kubernetes, using the Secrets API, are stored unencrypted in the API server's underlying data store. The Kubernetes documentation recommends setting up encryption at rest, enabling RBAC rules, limiting access to the secrets to only the necessary containers, or using an external Secret store provider. The Secrets Store CSI Driver, in addition to supporting Vault, also supports AWS, Azure, and GCP providers.
The beta release was first introduced in the HashiCorp Vault 1.13 release with the GA release aligning with the Vault 1.14 release. More details for the release can be found on the HashiCorp blog or in the GitHub repository.