Skip to main content
Two years and a text file. Every engineer who has ever cloned Tidepool’s repository had that database password on their laptop — including the contractor who worked there for only six weeks in the spring. Rotating that secret meant changing it in the database, updating the file, committing that change, and redeploying every service that reads it, which
A presentation slide titled "Two Years in a Text File" showing a .env file left in a repo — "every laptop has it" and "two years old," including the contractor's. The slide uses icons (file, briefcase, padlock, Docker whales and server boxes) and labels box-1 through box-4.
is why it has never been rotated. What would have to be true for that password to not be in the repository at all?
  • Someone has to provide the credential to the application at startup (or when needed).
  • The application must be able to prove its identity without holding a long‑lived secret on disk.
  • The proof must be short‑lived and scoped so that rotating credentials becomes a back‑end operation rather than a deploy.
Nomad solves this using workload identities and Vault integration. When a task starts, Nomad creates a small, signed document describing the task — which job and group it belongs to, and which cluster it’s running on. Nomad signs that document with a key only the Nomad servers hold. The task receives this signed document and cannot forge or edit it because any change breaks the signature. This signed description is the task’s workload identity. Vault is configured to trust Nomad’s signatures. The task presents its workload identity to Vault; Vault validates the signature, inspects which job the task belongs to, and looks up the permissions for that job. If the configured role allows the job to read database credentials, Vault issues a short‑lived token scoped to those credentials. If the same identity asks for payroll secrets, Vault refuses because the job name in the signed document doesn’t match the policy. What does that cost Maya in the job file? One block: a vault block that specifies the role (the name of the rule set in Vault) that applies to this job. There is no static Vault token in the job file, in the agent config, or on any machine.
A presentation slide titled "One Block, One Role" showing a vault icon, a key and an hourglass to represent a scoped, expiring token, and rows of Docker/container and server icons labeled box-1 through box-4. Large text on the right reads "A token scoped to that job, and it expires."
Be aware that many older tutorials and blog posts show a Vault token written into the Nomad agent configuration or passed in when the job is submitted. That was the old approach: it was deprecated in Nomad 1.7 and removed completely in 1.10. If you follow one of those guides today, it will fail, and the error won’t tell you the guide is four years old.
Do not put a static Vault token in the agent config or job submission. Use workload identity — it’s the supported, secure mechanism since Nomad 1.10.
How does the secret actually reach the application? Through a template block. A template is a small file Nomad renders for the task: it contains placeholders that Nomad fills before the task starts. In practice, you render a template whose data source pulls the password from Vault at a configured path and set destination to a file inside the task’s secrets directory. That directory is private to the task; no other task can read it, and Nomad prevents normal file-system introspection into it. Where possible, Nomad backs that directory with an in‑memory filesystem so the secret never touches disk. Note the words “where possible.” Treat in‑memory storage as the normal case, but not an absolute guarantee you’d stake a security review on.
A slide titled "The Template and the Secrets Directory" showing icons for a template file, a secrets folder, and a lock with the caption "Private to the task, in memory." Below are Docker whale and server icons labeled box-1 through box-4, illustrating per-container secret handling.
What if the secret changes while the application is running? Nomad’s change_mode controls that behavior: Maya picks restart because Tidepool’s API reads its configuration only at startup.
A slide titled "change_mode" showing three mode icons—restart (gear), signal (antenna), and noop (hourglass)—above a row of four boxes labeled box-1 to box-4 with container and server icons. On the right is the caption "Private to the task, in memory."
Example: a minimal job fragment showing a vault block and a template that renders a Vault secret into the task’s private secrets directory.
After Maya submits this job, the password comes out of the repository and out of the container image. Rotation becomes a Vault operation on a schedule — no deploy required. Maya no longer knows Tidepool’s database password, and neither does anyone else at Tidepool. It feels wrong for about a day, then it becomes the norm.
A presentation slide that reads "Nobody Knows the Password" and "Rotation is a Vault operation now," illustrated with a yellow repo icon, a green shield checkmark, and Docker/server icons labeled box-1 through box-4.
Although, two minutes after she submitted that file, one of the three API copies started, stopped, and started again, and again. References and further reading

Watch Video

Practice Lab