Security and compliance
Keep secrets out of repositories
Put a reference in joomiz.yaml instead of a password. The provisioner stores the secret in a vault and reports its address. The control plane keeps only that address.
With Joomiz
-
Write a reference
In the file, name the output of the resource that owns the secret. The text
${{ ... }}is a reference. It is not a value.joomiz.yaml env: # A reference, not a password. ... DB_PASSWORD: "${{managed-resources.shop-db.outputs.password}}" -
Preview without a secret
The plan shows
(known after apply)for the value. The plan, and the apply after it, never print the password.$ joomiz plan --environment test shop-db (created): succeeded — Would create 'shop-db' ... shop-test-deployment (updated): succeeded — Would update ... env.DB_PASSWORD: (known after apply) -
Pass only an address
After apply, the application receives the address of the secret in the vault. It reads the secret from there. The file and the control plane never hold the secret.
-
Refuse a raw value
A sensitive output must be an absolute address. If a provisioner returns a value instead, the plan fails and says so.
$ joomiz plan --environment test managed-resource/postgres: failed — Planned 1 change ... shop-db (created): failed — the provisioner reported a value ...
What you get
- A
joomiz.yamlthat is safe to review, share and show to an assistant. - Plan and apply output that shows addresses, never passwords.
- Secrets that stay in the vault of your platform.
The rules that still hold
- A sensitive output must be an absolute address. A raw value fails the plan.
- A reference to a value the type does not declare fails
joomiz validate. - Your platform team decides which vault holds secrets and how an application reads them.
Read more in the docs
Related use cases
Talk to us
Tell us about your platform and the services your teams ship.