27-Sep-2021

Introducing KubeVault v2021.09.27

by Sakib Alamin

We are very excited to announce the release of KubeVault v2021.09.27 Edition. The KubeVault v2021.09.27 contains major rework of the CRDs for self-service mode usage with KubeDB or GitOps use-cases. It makes managing user privileges extremely easy for KubeDB managed databases or any other databases as long as users provide necessary connection information.

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?

  • A more generic SecretAccessRequest

    The support for a more generic way to make secret access requests has been added in this release. Now, only the SecretAccessRequest CRD will be used to make request for all the supported SecretEngines and roles created in them e.g: GCPRole, AWSRole, ElasticsearchRole, MongoDBRole, etc. instead of separate CRDs e.g: GCPAccessRequest, AWSAccessRequest, DatabaseAccessRequest, etc. Making access request has never been this easy before using KubeVault.

      kind: SecretAccessRequest
      metadata:
        name: aws-cred-req
        namespace: dev
      spec:
        roleRef:
          kind: AWSRole
          name: aws-role
        subjects:
          - kind: ServiceAccount
            name: test-user-account
            namespace: test
    

SecretAccessRequest Flowchart

SecretAccessRequest has three different phases e.g: WaitingForApproval, Approved, Denied. A credential secret will only be issued if the phase is Approved. An approved SecretAccessRequest.status may look like this:

status:
  conditions:
  - lastTransitionTime: "2021-09-28T09:36:45Z"
    message: 'This was approved by: kubectl vault approve secretaccessrequest'
    observedGeneration: 1
    reason: KubectlApprove
    status: "True"
    type: Approved
  - lastTransitionTime: "2021-09-28T09:36:49Z"
    message: The requested credentials successfully issued.
    observedGeneration: 1
    reason: SuccessfullyIssuedCredential
    status: "True"
    type: Available
  observedGeneration: 1
  phase: Approved
  secret:
    name: aws-cred-req-92m0n9
    namespace: dev
  • Managing user privilege using SecretRoleBinding

    Managing user privilege has been made simpler with the newly introduced SecretRoleBinding CRD. Now Admin can bind a set of roles to a set of users to grant them specific privilege using SecretRoleBinding, and on success of which the KubeVautl operator will create the necessary VaultPolicy and VaultPolicyBinding.

      kind: SecretRoleBinding
      metadata:
        name: secret-r-binding
        namespace: dev
      spec:
        roles:
          - kind: AWSRole
            name: aws-role
          subjects:
            - kind: ServiceAccount
              name: test-user-account
              namespace: test
    

SecretRoleBinding Flowchart

A Successful SecretAccessRequest.status with created policyRef and policyBindingRef may look like this:

status:
  phase: Success
  policyRef:
    name: srb-dev-secret-r-binding
    namespace: demo
  policyBindingRef:
    name: srb-dev-secret-r-binding
    namespace: demo
  observedGeneration: 1
  conditions:
  - lastTransitionTime: "2021-09-28T12:56:35Z"
      message: VaultPolicy phase is Successful
      observedGeneration: 1
      reason: VaultPolicySucceeded
      status: "True"
      type: VaultPolicySuccess
  - lastTransitionTime: "2021-09-28T12:56:35Z"
      message: VaultPolicyBinding is Successful
      observedGeneration: 1
      reason: VaultPolicyBindingSucceeded
      status: "True"
      type: VaultPolicyBindingSuccess
  - lastTransitionTime: "2021-09-28T12:56:35Z"
      message: SecretRoleBinding is Successful
      observedGeneration: 1
      reason: SecretRoleBindingSucceeded
      status: "True"
      type: SecretRoleBindingSuccess

VaultPolicy created by a successful SecretRoleBinding will create the necessary policy documents which is shown below:

spec:
  policyDocument: |

      path "/k8s.-.aws.dev.aws-secret-engine/creds/k8s.-.dev.aws-role" {
          capabilities = ["read"]
      }

      path "/k8s.-.aws.dev.aws-secret-engine/sts/k8s.-.dev.aws-role" {
          capabilities = ["create", "update"]
      }

  vaultRef:
    name: vault

VaultPolicyBinding created by a successful SecretRoleBinding will contain the references to the policies and subjects which is shown below:

spec:
  policies:
    - ref: srb-dev-secret-r-binding
  subjectRef:
    kubernetes:
      name: k8s.-.demo.srb-dev-secret-r-binding
      path: kubernetes
      serviceAccountNames:
        - test-user-account
      serviceAccountNamespaces:
        - test
  vaultRef:
    name: vault
  vaultRoleName: k8s.-.demo.srb-dev-secret-r-binding

VaultPolicyBinding.spec.vaultRoleName is the role name which will be bound to the policies. This role may be used during the creation of SecretProviderClass for using the Secrets-store CSI Driver. This defaults to following format: k8s.${cluster or -}.${metadata.namespace}.${metadata.name}

What 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.

We are going to demo these features in our upcoming webinar on Oct 13, 2021 9:30 AM PST. Please register here to attend!

Support

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.