The Scribe Who Wrote Too Much
Spashta the scribe was thorough. She wrote down everything the builders told her: the blueprint, the materials list, the team roster, and, because the builders gave it to her without thinking, the password to the treasury. The blueprint was stored in the guild archive where any apprentice could read it. The treasury password was now in the archive with the blueprint. No one noticed for three years. Then Chhaya the shadow, hired by a rival guild, searched the archive for secrets hidden in plain sight. She found eleven passwords, three API keys, and a private signing key — all written in blueprints by scribes who did not know any better.
“A secret written in plaintext in any record is no longer a secret. Its age makes it no safer.”
The Vault and the Reference
Koshagar the vault keeper proposed a new rule: secrets would live in the vault. Blueprints would carry only references to vault locations, not the secrets themselves. Nirman the builder's blueprint would say: "treasury password: vault/keys/treasury-password" — not the password itself. When the builder ran the blueprint, the forge would fetch the secret from the vault at construction time, use it to configure the building, and never write it to any archive. The blueprint file could be read by anyone. It contained only references. The vault controlled who could resolve the references. Spashta could write as thoroughly as she liked — she could only write addresses, not values.
“Store the address, not the secret. Let access control live at the vault, not the blueprint.”
The Identity That Did Not Need a Password
Nirman came to Koshagar with a question: "To fetch the secret, the forge needs to authenticate to the vault. But to authenticate, it needs a credential. That credential must be stored somewhere. Has the problem simply moved?" Koshagar showed him managed identities: when the forge ran inside the trusted kingdom's network, it carried an identity issued by the kingdom itself — not a password, but a proof of belonging. The vault checked the identity, not a password. No credential was stored anywhere. The forge was trusted because of where it ran and who had authorized it, not because it knew a password. The circular problem dissolved.
“A managed identity replaces the circular problem of storing the credential to access credentials.”
The Rotation
Three months after the new system was in place, Koshagar rotated the treasury password. She generated a new value, stored it in the vault, and marked the old value expired. No blueprint changed. The reference was the same: "vault/keys/treasury-password." The next time the forge ran, it fetched the new value. No builder knew the password changed. No blueprint needed to be updated. No builder carried a stale password in their memory. The rotation was invisible to the builders. The vault knew the current value. The builders knew only the address. When a builder left the guild, Koshagar revoked their vault access. Their departure did not compromise any secret.
“A secret that can be rotated without changing any blueprint is a secret that has been correctly abstracted.”
The Audit That Never Ended
Chhaya was now hired by the guild itself — not to steal secrets, but to search for any that had slipped through. She ran her search on every blueprint submitted to the archive: patterns that looked like passwords, connection strings, API keys. Each week she returned a short report. Most weeks it was empty. Occasionally: "Apprentice submitted a blueprint with a password on line twelve — corrected before merge." The search was automated. It ran on every submission. The guild also checked the vault access logs: who had fetched which secret, when, and from which machine. Any unusual pattern was reviewed. The audit was not a periodic event. It ran continuously.
“Continuous automated scanning catches what good intentions miss.”
The Secret That Was Never Born
Koshagar's final teaching was this: the best-managed secret is the one that never exists as a secret. For some services, the kingdom could use certificate-based authentication. For others, Koshagar could use short-lived tokens that expired after one hour — even if stolen, they were useless by the time Chhaya found them in a log. For services within the trusted network, Koshagar used private endpoints so credentials never crossed a public boundary. For every secret that had to exist, Koshagar asked: "Can it be temporary? Can it be identity-based? Can it be network-controlled?" The vault shrank. The secrets that remained in it were unavoidable. And those, Koshagar guarded perfectly.
“Reduce the surface before hardening it. The smallest vault is the safest vault.”
🪔 Deepak — the lamp of meaning · what this fable means in code
IaC secrets management separates two concerns: where secrets are stored and how infrastructure references them. Azure Key Vault stores secrets, certificates, and keys — infrastructure references vault URIs, not values. Managed identities let Azure resources authenticate to Key Vault without any stored credential, resolving the bootstrap problem. In Terraform, use azurerm_key_vault_secret data sources at apply time; never hardcode in .tfvars or pass on CLI. In Bicep, use getSecret() in parameter files or reference vault with resource ID at deploy time. Secret scanning tools (detect-secrets, gitleaks) run in CI to prevent accidental commits. Short-lived secrets and managed identities eliminate the rotation problem by eliminating the long-lived credential.