Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News HashiCorp Vault Secrets Operator for Kubernetes Moves into General Availability

HashiCorp Vault Secrets Operator for Kubernetes Moves into General Availability

This item in japanese

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:

kind: VaultConnection
  namespace: vso-example
  name: example
  # 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 to create a new credential:

kind: VaultDynamicSecret
  namespace: vso-example
  name: example
  vaultAuthRef: example
  mount: db
  path: creds/my-postgresql-role
    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.

About the Author

Rate this Article