Vault Secrets Operator for Kubernetes now GA

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 Secrets management

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.

»The Vault Secrets Operator

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.

»Custom resources

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:

• Helm: Our Helm chart is available in the HashiCorp Helm repository, at https://helm.releases.hashicorp.com
• Kustomize: The Operator’s GitHub repo includes the artifacts necessary for deploying an instance of the Operator with Kustomize.

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:

• VaultConnection
• VaultAuth
• VaultDynamicSecret
• VaultPKISecret

Below are code samples to implement a dynamic secrets workflow with the Vault Secrets Operator leveraging the VaultConnection, VaultAuth, and VaultDynamicSecret CRs.

»VaultConnection

»VaultAuth

»VaultDynamicSecret

»Required permissions

The Vault Secrets Operator requires various Kubernetes permissions to function correctly. These include:

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.

»GA updates

The GA release of the Vault Secrets Operator also includes several updates that were not included in the beta:

»Authentication methods

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:

• Kubernetes
• JSON Web Token (JWT)
• AppRole
• AWS

»Cloud services validation

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:

• AKS
• GKE
• EKS
• OpenShift

»Revoke cached Vault client tokens upon Operator deletion

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.

»Related Vault and Kubernetes integrations

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:

»Please share your feedback

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.