The Vault Secrets Operator implements a first-class Kubernetes Operator for Vault, along with CRDs responsible for synchronizing Vault secrets to Kubernetes Secrets.
In March, we introduced the beta version of the HashiCorp Vault Secrets Operator for Kubernetes. Today, the Operator has reached general availability. We received a great deal of feedback from our user community that helped us identify and prioritize features for the Vault Secrets Operator GA. This post covers the functionality of the Vault Operator and reviews the new features released along with GA.
Kubernetes natively supports the management and distribution of secrets within a cluster. Applications running on Kubernetes can consume secrets natively from the Secrets API. Kubernetes Secrets can be consumed directly from files in a volume mounted by a container, container environment variables, or directly from the API by an application. However, Kubernetes does not support dynamic secrets or rotation, leaving that responsibility to users.
Kubernetes Secrets were conceived as a static configuration object containing confidential information. Secrets were typically created during the deployment of an application and remained unchanged throughout the lifecycle of the application’s container.
Vault fills the gaps in Kubernetes by providing a complete solution for modern secrets management. It consolidates identity brokering, secrets management (including dynamic secrets), rotation, and security policy compliance in one platform. By coupling Vault’s secret management feature set with a Kubernetes Secrets cache, developers have to consume the secret natively only from Kubernetes.
Prior approaches to Vault/Kubernetes integration required some level of application modification in order to read from a file. Applications also needed to be aware of when credentials have been modified so that they can be re-read from the file. In response to user interest in a new, Operator-based method of Vault/Kubernetes integration, earlier this year HashiCorp introduced the Vault Secrets Operator, which allows users to natively sync secrets from Vault to Kubernetes clusters.
The Vault Secrets Operator also helps create an operational boundary between SecOps and engineering teams. SecOps is now positioned to define, enforce, and control security policies independent from development, which means they can establish best practices for secrets rotation and dynamic secrets. The Vault Secrets Operator for Kubernetes also allows SecOps Teams to leverage Vault’s audit capabilities and monitor for access and permissions.
Kubernetes Operators allow the customization of automatable tasks within a Kubernetes cluster. This operator pattern removes service management burdens from human operators, such as managing secrets for the services orchestrated by Kubernetes.
The Vault Secrets Operator implements a controller that uses Kubernetes custom resources defined by the Vault Secrets Operator’s custom resource definitions (CRDs) to manage the secrets used by the services. The secrets are then managed by Vault, orchestrated in Kubernetes using custom resources, and consumed by the applications in a Kubernetes-native manner, cleanly separating concerns. Using standard Kubernetes declarative patterns, the Vault Secrets Operator reconciles the current state to the desired state specified in the CRDs.
To check out the code, visit the Kubernetes Vault Secrets Operator GitHub repo. The project SDK is based on the Operator SDK for Go and provides the tools necessary for building, testing, and deploying a Kubernetes Operator.
The Vault Secrets Operator for Kubernetes is dependent on custom resources. In order to set up a secret sync, users first deploy the Operator through one of two supported methods:
Once that is done, the Operator will be able to handle any of the supported Secret CRs. The Vault Secrets Operator supports a variety of CRs, including:
Below are code samples to implement a dynamic secrets workflow with the Vault Secrets Operator leveraging the VaultConnection, VaultAuth, and VaultDynamicSecret CRs.
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
apiVersion: secrets.hashicorp.com/v1beta1 kind: VaultAuth metadata: namespace: vso-example name: example spec: vaultConnectionRef: example # Method to use when authenticating to Vault. method: kubernetes # Mount to use when authenticating to auth method. mount: kubernetes kubernetes: role: demo serviceAccount: default
apiVersion: secrets.hashicorp.com/v1beta1 kind: VaultDynamicSecret metadata: namespace: vso-example name: example spec: vaultAuthRef: example mount: db path: creds/postgres destination: create: true name: dynamic1
The Vault Secrets Operator requires various Kubernetes permissions to function correctly. These include:
|Secret||create, read, update, delete, watch||Sync operations, Vault auth|
|ServiceAccount||read token creation||Vault auth|
|Deployment||read, update, watch||Post secret rotation actions|
If granting these permissions for the entire cluster is problematic for your team from a security management or compliance standpoint, consider restricting the Vault Secrets Operator’s access to objects in specific namespaces.
The GA release of the Vault Secrets Operator also includes several updates that were not included in the beta:
We substantially increased the number of authentication methods available for the Vault Secrets Operator. Only the Kubernetes authentication method was available when we released the beta version. Today, we’re pleased to announce that the following authentication methods are supported by the Vault Secrets Operator:
Validations are key enablers that help assure organizations that their architecture will satisfy their stakeholders’ requirements. The GA release of Vault Secrets Operator includes validations for several common Kubernetes cloud services used by IT and platform teams to validate the Vault Secrets Operator solution. These platforms include:
As an extra security mechanism, when the Vault Secrets Operator deployment is deleted, it will attempt to revoke any cached Vault client tokens. Additionally, any cached storage entries will be purged as well. Enabling this functionality can be invoked from the CLI.
To learn more about all of our Vault/Kubernetes integration methods, read our blog post on Kubernetes Vault integration via Sidecar Agent Injector vs. Vault Secrets Operator vs. CSI provider and visit each method’s GitHub repository:
Vault Secrets Operator: Syncs Vault secrets and Kubernetes Secrets.
Vault Sidecar Agent Injector: Provides access to Vault secrets by deploying a vault-agent sidecar into a Kubernetes pod.
Vault CSI provider: Fetches secrets stored in Vault and uses the Secrets Store Container Storage Interface (CSI) driver interface to mount them into Kubernetes pods.
Watch this video for a demonstration of Vault Secrets Operator for Kubernetes:
As you pursue your Kubernetes secrets management journey with Vault Secrets Operator, we’re interested in any feedback and recommendations you may have. To provide feedback, please submit a GitHub issue in the project repository.
You can learn more about the Vault Secrets Operator by visiting the vault-secrets-operator GitHub repository. Further documentation on using Vault with Kubernetes can be found in our HashiCorp Developer guide to Kubernetes and Vault. To learn more about HashiCorp Vault please visit the Vault product page.
A recap of HashiCorp infrastructure and security news and developments on AWS from the past year, from self-service provisioning to fighting secrets sprawl and more.
Vault benchmark is an open source tool that tests the performance of HashiCorp Vault auth methods and secrets engines.
If you’re attending AWS re:Invent in Las Vegas, Nov. 27 - Dec. 1, visit us for breakout sessions, expert talks, and product demos to learn how to accelerate your adoption of a cloud operating model.