Configure Vault Using the Vault CLI¶

After Vault has been installed, you can configure Vault for use with StarlingX using the CLI. This section describes the minimum configuration requirements for server secrets for hosted Kubernetes applications.

About this task

You can configure Vault by logging into a Vault server pod and using Vault CLI.

Procedure

Get the root token for logging into Vault.

$ ROOT_TOKEN="$( kubectl get secrets -n vault cluster-key-root \
  -o jsonpath='{.data.strdata}' | base64 -d )"

$ kubectl exec -it -n vault sva-vault-0 -- sh

Log into Vault, and provide the root token when prompted. Refer to step 1 for the root token.
```
$ vault login -no-print
```
Enable the Kubernetes Auth method.
```
$ vault auth enable kubernetes
```

Configure the Kubernetes Auth method.

$ vault write auth/kubernetes/config kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443"

Verify the Kubernetes Auth method.

$ vault auth list

and

$ vault read auth/kubernetes/config

Enable a secrets engine at the path “secret”.

Vault supports a variety of secret engines, as an example, create a kv-v2 secrets engine. The kv-v2 secrets engine allows for storing arbitrary key-value pairs. Secrets engines are enabled at a “path” in Vault. When a request comes to Vault, the router automatically routes anything with the route prefix to the secrets engine. In this way, each secrets engine defines its own paths and properties. To the user, secrets engines behave similar to a virtual filesystem, supporting operations like read, write, and delete.
```
$ vault secrets enable -path=secret kv-v2
```
For more information, see:
- https://www.vaultproject.io/docs/secrets
- https://www.vaultproject.io/docs/secrets/kv/kv-v2
Create a sample policy and role for allowing access to the configured kv-v2 secrets engine.

A Vault policy specifies read and/or write capabilities for a particular secret engine path, and the Vault role binds a specific Kubernetes service account to a policy.
1. Create a policy.
```
$ vault policy write basic-secret-policy - <<EOF
path "secret/basic-secret/*" {
  capabilities = ["read"]
}
EOF
```
  For more information, see https://www.vaultproject.io/docs/concepts/policies.
2. Create the role mapped to the policy.
  Note
  
  The service account and namespace used for the values below must exist on the kubernetes cluster.
  - bound_service_account_names
  - bound_service_account_namespaces
```
$ vault write auth/kubernetes/role/basic-secret-role bound_service_account_names=basic-secret bound_service_account_namespaces=test policies=basic-secret-policy ttl=24h
```
3. Verify the policy.
```
$ vault policy read basic-secret-policy
```
4. Verify the role.
```
$ vault read auth/kubernetes/role/basic-secret-role
```

Create an initial example secret in the configured kv-v2 secrets engine.

Create a secret.

$ vault kv put secret/basic-secret/helloworld username="test" password="supersecret"

Verify the secret.

$ vault kv get secret/basic-secret/helloworld

(Optional) To enable audit logging, use the steps below:

Note

It is recommended to enable file logging and stdout.
1. Enable Vault logging to file for persistent log storage.
```
$ vault audit enable -path="/vault/audit/vault_audit.log" file file_path=/vault/audit/vault_audit.log
```
2. Enable Vault logging to stdout for easy log reading from the Vault container.
```
$ vault audit enable -path="stdout" file file_path=stdout
```
3. Verify the configuration.
```
$ vault audit list
```
Delete the cached credentials to log out of Vault.
```
$ rm ~/.vault-token
```
Exit the Vault container.
```
$ exit
```