Install Vault-CRD

The following part describes how to install Vault-CRD inside a Cluster with enabled RBAC.

First you have to specify which authentication method you would like to use for Vault-CRD to access Vault. There are two supported methods:

Static Vault Token

Create a file called policy.hcl with the following content:

path "testpki/issue/testrole" {
  capabilities = ["create", "read", "update"]
}

path "secret/*" {
  capabilities = ["read"]
}

This defines a new policy that has access to issue new Certificates in a testpki with role testrole and has read access to all secrets in the secret-mountpoint. To write this policy to HashiCorp Vault please run the following command:

$ vault write sys/policy/testpolicy [email protected]

The policy is now available in Vault and has the name testpolicy.

Now you can generate the Vault Token, that has this new testpolicy assigned:

$ vault token create -policy=testpolicy -display-name=testtoken
Key                Value
---                -----
token              7b021d51-c4e8-5b28-e944-5dceb1ec5191
token_accessor     540957b0-0340-2c06-1546-7c28e682983f
token_duration     768h
token_renewable    true
token_policies     [default testpolicy]

Now the value of the token-key is the token, that is required to deploy Vault-CRD.

Deploy Vault-CRD

At the end of the deploy/rbac.yaml-file is the Deployment of Vault-CRD with two environment variables. Please change the values of them to your personal settings. e.g:

Now you can deploy the rbac file with the following command:

Kubernetes Service Account authentication

First please create a Service Account and a ClusterRoleBinding to the Service Account to generate a reviewer JWToken. Therefore please apply the following Kubernetes changes:

Now you can enable the Kubernetes authentication method and use the generated Service Account to configure the reviewer handling. This allows Vault to verify the JWToken used by Vault-CRD to authenticate.

If you work with a Mac please replace base64 -d with base64 -D

The last step is to generate a policy (please see the Static Vault Token example) and generate a vault role that binds the secret for the Service Account to the policy:

Deploy Vault-CRD

At the end of the deploy/rbac.yaml-file is the Deployment of Vault-CRD with two environment variables. By default Vault-CRD is configured to use Static Vault Tokens. Please replace the values with the following information:

Now you can deploy the rbac file with the following command:

Configuration of Vault-CRD

The following environment variables can be changed to configure Vault-CRD

Variable

Description

Default Value

KUBERNETES_VAULT_URL

Please specify here the URL to your Vault installation. Don't forget to set the /v1/ path

KUBERNETES_VAULT_TOKEN

Token with access to the resources that Vault-CRD shares from Vault to Kubernetes.

KUBERNETES_VAULT_ROLE

If you use the Service Account approach for Vault authentication please specify here the Vault role. In the example above it's vault-auth.

KUBERNETES_VAULT_AUTH

Specifies the used authentication method the following values are allowed: token | serviceAccount

token

KUBERNETES_VAULT_PATH

Please specify here the Vault auth path to be used.

kubernetes

KUBERNETES_INTERVAL

Specifies the refresh interval in seconds. In this interval Vault-CRD will check if something has changed in Vault that must be updated in Kubernetes.

60

KUBERNETES_JKS_DEFAULT_ALIAS

Specifies the default alias, where the certificate will be placed in a Java Key Store. Can be overwritten by specifying one in the JKS Configuration.

main

KUBERNETES_JKS_DEFAULT_PASSWORD

Default Password that encrypts the Java Key Store. Can be overwritten by specifying one in the JKS Configuration.

changeit

KUBERNETES_JKS_DEFAULT_SECRET_KEY_NAME

Specifies the default key name inside the generated secret where the keystore is placed. Can be overwritten by specifying one in the JKS Configuration.

key.jks

Last updated