SUSE Application Collection: Vault

Get started

Vault provides centralized, well-audited privileged access and secret management for mission-critical data whether you deploy systems on-premises, in the cloud, or in a hybrid environment. With a modular design based around a growing plugin ecosystem, Vault lets you integrate with your existing systems and customize your application workflow. This application builds the community edition of HashiCorp Vault.

Before exploring the chart characteristics, let’s start by deploying the default configuration:


helm install <release-name> oci://dp.apps.rancher.io/charts/vault \
    --set global.imagePullSecrets={application-collection}

Please check our authentication guide if you need to configure Application Collection OCI credentials in your Kubernetes cluster.

Chart overview

The Vault Helm chart distributed in Application Collection is based on the official Vault Helm chart and adapted to include our best practices. As such, any chart-related documentation provided by upstream will work out of the box with our chart. In addition to the upstream chart repository, you can check the official Vault documentation .

By default, the chart will deploy a single Vault server in standalone mode with a 10Gi volume for data storage and a Vault Agent Injector admission webhook controller .

Server modes

The Vault server can be deployed in 3 modes:

Development: this mode does not require initialization or unsealing setup and it is intended for experimentation only. Data is not persisted. The Helm parameters that control this mode are server.dev.*. Read more on this in the official documentation .
Standalone: this is the default mode. It deploys a single replica and persists the data in a volume by using the “file” backend. Vault needs to be initialized after Helm installation. The Helm parameters that control this mode are server.standalone.*.
High-Availability: in HA mode, multiple Vault servers are deployed. By default, Consul is configured as storage backend but others can be configured manually. The Helm parameters that control this mode are server.ha.*. More information can be found in the official documentation .

Chart configuration

To view the supported configuration options and documentation, run:


helm show values oci://dp.apps.rancher.io/charts/vault

Refer to the Vault Helm chart documentation to learn more about configuring the Helm chart.

Development mode

The simplest way to start experimenting with the Vault application is activating the development mode when installing the Helm chart. As an example, you would provide the Helm chart values below to activate this mode. A root token can be specified from the Helm chart values for ease of use:

dev.yaml


server:
  dev:
    enabled: true
    devRootToken: admin


helm install <release-name> oci://dp.apps.rancher.io/charts/vault \
    --set global.imagePullSecrets={application-collection} \
    --values dev.yaml

A single replica StatefulSet is deployed without requiring any further initialization steps:


$ kubectl get statefulset/<release-name>-vault
NAME                   READY   AGE
<release-name>-vault   1/1     21s

To confirm that the provided root token is being applied, run the command below:


$ kubectl exec statefulset/<release-name>-vault -- vault print token
admin

Secrets can be created and retrieved via CLI and API:


$ kubectl exec statefulset/<release-name>-vault -- vault kv put -mount=secret test foo=bar
== Secret Path ==
secret/data/test
...


$ kubectl port-forward svc/<release-name>-vault 8200
 
$ curl --header "X-Vault-Token: admin" http://localhost:8200/v1/secret/data/test
{"request_id":"d2410d29-2b13-0a83-2df4-a3b4e14592cc","lease_id":"","renewable":false,"lease_duration":0,"data":{"data":{"foo":"bar"},"metadata":{"created_time":"2025-12-16T11:12:39.796800666Z","custom_metadata":null,"deletion_time":"","destroyed":false,"version":1}},"wrap_info":null,"warnings":null,"auth":null,"mount_type":"kv"}

Standalone mode

If you install Vault using the default standalone setup, you’ll need to complete a few extra steps to finish setting it up:


helm install <release-name> oci://dp.apps.rancher.io/charts/vault \
    --set global.imagePullSecrets={application-collection}

The logs show that the server is pending to be initialized and unsealed:


$ kubectl logs statefulset/<release-name>-vault
...
2025-12-16T12:04:35.881Z [INFO]  core: security barrier not initialized
2025-12-16T12:04:35.881Z [INFO]  core: seal configuration missing, not initialized
...

Run operator init and operator unseal to finish the setup:


$ kubectl exec statefulset/<release-name>-vault -- vault operator init -key-shares=1 -key-threshold=1
Unseal Key 1: <generated_unseal_key>
...

Copy the unseal key (<generated_unseal_key>) and run the operator unseal command with it. The command shows that Vault is now initialized and unsealed:


$ kubectl exec statefulset/<release-name>-vault -- vault operator unseal <generated_unseal_key>
Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
...

The installation is now ready:


$ kubectl get statefulset/<release-name>-vault
NAME                   READY   AGE
<release-name>-vault   1/1     2m32s

High-Availability mode

The High-Availability (HA) mode deploys multiple Vault server replicas. To illustrate it with an example, the Raft storage backend will be used. You can configure this mode and storage backend via Helm chart parameters:

ha.yaml


server:
  # Uncomment this line if your cluster has a single node: this schedules all pods in the same node
  # affinity: ""
  ha:
    enabled: true
    replicas: 3
    raft:
      enabled: true


helm install <release-name> oci://dp.apps.rancher.io/charts/vault \
    --set global.imagePullSecrets={application-collection} \
    --values ha.yaml

Initialize the first replica and copy the credentials:


$ kubectl exec <release-name>-vault-0 -- vault operator init -key-shares=1 -key-threshold=1
Unseal Key 1: <generated_unseal_key>
 
Initial Root Token: <some_initial_root_token>
...

Run these commands to finish the initialization of the Vault cluster:


$ kubectl exec <release-name>-vault-0 -- vault operator unseal <generated_unseal_key>
 
$ kubectl exec <release-name>-vault-1 -- vault operator raft join http://<release-name>-vault-0.<release-name>-vault-internal:8200
Key       Value
---       -----
Joined    true
$ kubectl exec <release-name>-vault-1 -- vault operator unseal <generated_unseal_key>
 
$ kubectl exec <release-name>-vault-2 -- vault operator raft join http://<release-name>-vault-0.<release-name>-vault-internal:8200
Key       Value
---       -----
Joined    true
$ kubectl exec <release-name>-vault-2 -- vault operator unseal <generated_unseal_key>

Now all the Vault cluster replicas should be ready:


$ kubectl exec statefulset/<release-name>-vault -- vault login <some_initial_root_token>
$ kubectl exec statefulset/<release-name>-vault -- vault operator raft list-peers
Node                                    Address                                                      State       Voter
----                                    -------                                                      -----       -----
5e5e39d9-fa24-849d-c876-6ae44ca566a6    <release-name>-vault-0.<release-name>-vault-internal:8201    leader      true
f400dca4-5805-2c39-6efa-4491ee07289c    <release-name>-vault-1.<release-name>-vault-internal:8201    follower    true
02d451a7-09e6-8c8e-b4b7-1a57f28ed5f9    <release-name>-vault-2.<release-name>-vault-internal:8201    follower    true
 
$ kubectl exec <release-name>-vault-0 -- vault status
Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
...
Storage Type            raft
...
HA Enabled              true
HA Cluster              https://<release-name>-vault-0.<release-name>-vault-internal:8201
HA Mode                 active
...
$ kubectl exec <release-name>-vault-1 -- vault status
Key                     Value
---                     -----
Seal Type               shamir
Initialized             true
Sealed                  false
...
Storage Type            raft
...
HA Enabled              true
HA Cluster              https://<release-name>-vault-0.<release-name>-vault-internal:8201
HA Mode                 standby
$ kubectl exec <release-name>-vault-2 - vault status
Key                     Value
---                     -----
Seal Type               shamir
Initialized             true
Sealed                  false
...
Storage Type            raft
...
HA Enabled              true
HA Cluster              https://<release-name>-vault-0.<release-name>-vault-internal:8201
HA Mode                 standby
 
$ kubectl get statefulset/<release-name>-vault
NAME                   READY   AGE
<release-name>-vault   3/3     4m56s

Access the UI

The Vault Helm chart can expose the web UI as an independent service that allows you to easily manage its configurations. To create this UI service simply enable it with the Helm chart parameter below:

ui.yaml


# Vault UI
ui:
  # True if you want to create a Service entry for the Vault UI.
  enabled: true


helm install <release-name> oci://dp.apps.rancher.io/charts/vault \
    --set global.imagePullSecrets={application-collection} \
    --values ui.yaml

Vault Agent Injector

The Vault Agent Injector is a Kubernetes admission webhook controller that intercepts pod events and updates their specification based on certain annotations. Thanks to this controller, Vault secrets can be injected into pods by mounting them as volumes. This functionality can be controlled by Helm chart parameters (injector.*). Read more on this feature in the official documentation . As an example, you would provide the Helm chart values below to make sure this mode is activated. For simplicity, the development mode is used:

injector.yaml


injector:
  enabled: true


helm install <release-name> oci://dp.apps.rancher.io/charts/vault \
    --set global.imagePullSecrets={application-collection} \
    --values injector.yaml \
    --set server.dev.enabled=true

Once the Helm installation finishes, create a new Vault secret:


kubectl exec statefulset/<release-name>-vault -- vault kv put -mount=secret test-injector foo=bar

Then, configure Kubernetes authentication and Vault policies to interact with that secret:


kubectl exec statefulset/<release-name>-vault -- vault auth enable kubernetes
kubectl exec statefulset/<release-name>-vault -- bash -c 'vault write auth/kubernetes/config kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443"'
kubectl exec -i statefulset/<release-name>-vault -- vault policy write test-injector - <<EOF
path "secret/data/test-injector" {
   capabilities = ["read"]
}
EOF
kubectl exec statefulset/<release-name>-vault -- vault write auth/kubernetes/role/test-injector bound_service_account_names=test-injector bound_service_account_namespaces=default policies=test-injector
kubectl create serviceaccount test-injector

To finish, confirm that the secret is automatically mounted into the pods with proper metadata annotations:


kubectl run test-injector --image dp.apps.rancher.io/containers/nginx:1.29 \
    --overrides='{"spec": {"serviceAccount": "test-injector", "imagePullSecrets":[{"name": "application-collection"}]}}' \
    --annotations=vault.hashicorp.com/agent-inject=true \
    --annotations=vault.hashicorp.com/role=test-injector \
    --annotations=vault.hashicorp.com/agent-inject-secret-test.txt=secret/data/test-injector


$ kubectl exec test-injector -c test-injector -- cat /vault/secrets/test.txt
data: map[foo:bar]
...

Operations

Upgrade the chart

When upgrading the Vault Helm chart, there are certain considerations to take into account. Please refer to the official documentation for a detailed explanation of the upgrade process.


helm upgrade <release-name> oci://dp.apps.rancher.io/charts/opentelemetry-operator --dry-run

Be aware that changes from version to version may include breaking changes in Vault itself or in the Helm chart templates. The upgrade process may require additional steps to be performed. Refer to the official release notes and always check the Important changes notes before proceeding with an upgrade.

Uninstall the chart

Removing an installed Vault is simple:


helm uninstall <release-name>

Depending on the installation mode and configurations provided, data could be stored into Persistent Volume Claims. These PVCs are not directly controlled by Helm and they are not removed when uninstalling the related chart.

When you are ready to remove the PVCs and your data, you will need to explicitly delete them:


kubectl delete pvc --selector app.kubernetes.io/instance=<release-name>

Remember to remove any other resources you deployed during this guide:


kubectl delete pod test-injector
kubectl delete serviceaccount test-injector