Introducing KubeVault v2022.06.16

by Sakib Alamin

We are very excited to announce the release of KubeVault v2022.06.16 Edition. The KubeVault v2022.06.16 contains VaultServer latest api version v1alpha2, update to authentication method with addition of JWT/OIDC auth method. A new SecretEngine for MariaDB has been added, KubeVault CLI has been updated along with various fixes on KubeVault resource sync. We’re going to discuss some of them in details below.

KubeVault is a Kubernetes operator for HashiCorp Vault. The Vault is a tool for secrets management, encryption as a service, and privileged access management. The KubeVault operator makes it easy to deploy, maintain and manage Vault servers in Kubernetes. It also supports various secret engines management, policy management in the Kubernetes native way.

In this post, we are going to highlight the major changes. You can find the complete commit by commit changelog here.

What’s new in this release?

  • JWT/OIDC Authentication Method

    The JWT auth method can be used to authenticate with Vault using OIDC or by providing a JWT. The OIDC method allows authentication via a configured OIDC Provider using the user’s web browser. This method may be initiated from the Vault UI or the command line. Alternatively, a JWT can be provided directly.

    While deploying the VaultServer it’s possible to define the list of auth methods users want to enable with it.

    A VaultServer yaml may look like this:

      apiVersion: kubevault.com/v1alpha2
      kind: VaultServer
        name: vault
        namespace: demo
        version: 1.10.3
        replicas: 3
          - type: jwt
            path: jwt
              defaultLeaseTTL: 1h
              defaultRole: k8s.kubevault.com.demo.reader-writer-role
              oidcClientID: aFSrk3w06WsQqyjA30HvhbbJIR1VBidU
              oidcDiscoveryURL: https://dev-tob49v6v.us.auth0.com/
                name: jwt-cred
              storageClassName: "standard"
                  storage: 1Gi
          secretShares: 3
          secretThreshold: 2
              secretName: vault-keys
    • .spec.authMethods.type is a required field, the type of authentication method we want to enable.

    • .spec.authMethods.path is a required field, the path where we want to enable this authentication method.

    • .spec.authMethods.jwtConfig / .spec.authMethods.oidcConfig contains various configuration for this authentication method. Some of the parameters are: defaultLeaseTTL, maxLeaseTTL, pluginName, credentialSecretRef, tlsSecretRef, oidcDiscoveryURL, oidcClientID, oidcResponseMode, defaultRole, providerConfig, etc. Check out this for more details. After an authentication method is successfully enabled, KubeVault operator will configure it with the provided configuration.

      After successfully enabling & configuring authentication methods, a VaultServer .status.authMethodStatus may look like this:

        - path: jwt
          status: EnableSucceeded
          type: jwt
        - path: kubernetes
          status: EnableSucceeded
          type: kubernetes

      We can verify it using the Vault CLI:

      $ vault auth list
      Path           Type          Accessor                    Description
      ----           ----          --------                    -----------
      jwt/           jwt           auth_jwt_ba23cc30           n/a
      kubernetes/    kubernetes    auth_kubernetes_40fd86fd    n/a
      token/         token         auth_token_950c8b80         token based credentials
  • MariaDB SecretEngine

    Now, MariaDB SecretEngine can be enabled, configured & MariaDBRole can also be created with KubeVault. Here’s a sample yaml for MariDB SecretEngine & MariaDBRole:

    apiVersion: engine.kubevault.com/v1alpha1
    kind: SecretEngine
      name: mariadb-engine
      namespace: demo
        name: vault
        namespace: demo
          name: mariadb
          namespace: db
        pluginName: "mysql-database-plugin"
    apiVersion: engine.kubevault.com/v1alpha1
    kind: MariaDBRole
      name: mariadb-role
      namespace: dev
        name: mariadb-engine
        - "CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}';"
        - "GRANT CREATE, SELECT, INSERT ON *.* TO '{{name}}'@'%';"
        - "DROP USER '{{name}}'@'%';" 
      defaultTTL: 3h
      maxTTL: 24h
  • Merge secrets using KubeVault CLI

    Now, you can merge two Kubernetes Secrets using KubeVault CLI.

    # merge two secret name1 & name2 from ns1 & ns2 namespaces respectively
    $ kubectl vault merge-secrets --src=<ns1>/<name1> --dst=<ns2>/<name2>
    # --overwrite-keys flag will overwrite keys in destination if set to true.
    $ kubectl vault merge-secrets --src=<ns1>/<name1> --dst=<ns2>/<name2> --overwrite-keys=true
    $ kubectl vault merge-secrets --src=demo/src-secret --dst=demo/dest-cred

What’s Next?

Please try the latest release and give us your valuable feedback.

  • If you want to install KubeVault, please follow the installation instruction from here.


To speak with us, please leave a message on our website.

To receive product announcements, follow us on Twitter.

If you have found a bug with KubeVault or want to request new features, please file an issue.

Get Up and Running Quickly

Deploy, manage, upgrade Kubernetes on any cloud and automate deployment, scaling, and management of containerized applications.