Secrets

Secrets store sensitive values (API tokens, license keys, bootstrap passwords) in HashiCorp Vault. Reference them in cloud-init templates with {{ secret.API_TOKEN }}: never paste raw secrets into template YAML.

Manage secrets at /configuration/secrets under Orchestration → Secrets.

Create a secret

Open Secrets

Go to /configuration/secrets.

Add key and value

The value is shown once at creation. Copy it to a password manager if needed: list and get operations return metadata only, not the plaintext value.

Use in cloud-init

#cloud-config
write_files:
  - path: /etc/nrings/token
    content: {{ secret.API_TOKEN | tojson }}
    permissions: '0600'

Security practices

Never echo secret values in support tickets, chat logs, or template comments. NodeRings does not return decrypted values on GET or LIST.

Use environment variables for non-sensitive config.
Rotate secrets by creating a new Vault version via Update (see below).

Reserved key rules match environment variables: keys cannot use vm, secret, password, and other built-in namespaces.

Secret rotation

When you update a secret's value in NodeRings:

Vault stores a new version of the secret path.
Running VMs are unchanged: cloud-init runs at first boot only; injected files are not updated in place.
New VMs created after the update receive the latest value at compile time.

Rotation runbook

Step	Action
1	Update the secret value in `/configuration/secrets`.
2	Confirm templates still reference `{{ secret.KEY }}` (no hard-coded values).
3	For existing VMs that need the new credential, rebuild or reprovision (delete + create, or your internal rebuild process).
4	Optionally revoke the old credential at the upstream service after new VMs are live.

There is no background job that re-compiles cloud-init for the fleet when secrets change. Plan rotation around VM lifecycle or maintenance windows.