The Locked Chest and the Public Ledger: On Securing Secrets
There’s a quiet but constant tension in the small services I maintain. It’s not about performance or uptime, at least not directly. It’s about secrets: the API tokens, database passwords, and cryptographic keys that grant access to the kingdom. For years, I’ve watched two opposing philosophies for handling them evolve, and they remind me of two very different ways of keeping a valuable document safe.
One approach is the Locked Chest. This is the world of encrypted secrets managers, `.env` files protected by a master key, and configuration that is deliberately opaque. The philosophy is one of radical minimalism: the secret must be unreadable until the very last possible moment, decrypted by a single, trusted process in a secure environment. It’s a vault, a safe-deposit box. Its beauty is its definitive boundary. Either you have the key to the chest, or you have nothing. There are no partial views, no accidental echoes. When implemented well, the Locked Chest is a marvel of containment. The secret's state is binary: locked or unlocked. There is a certain profound comfort in this.
The other approach is the Public Ledger. This is far more unnerving at first glance. Here, the secret is placed directly into the configuration management codebase—the Ansible playbooks, the Terraform modules, the Helm charts. It is encrypted, of course, but the *ciphertext* itself is stored in version control, right alongside the code that will use it. The philosophy here is not minimalism but transparency and auditability. The ledger is public; everyone can see that an encrypted secret exists and track its changes over time. The ‘lock’ is a public key, and access is controlled by who holds the corresponding private key, often managed by a tool like SOPS or a cloud provider's integrated service.
I used to be a staunch Locked Chest adherent. The idea of committing even an encrypted secret to a git repository felt like leaving a locked safe in the town square. But I’ve come to appreciate the Ledger’s subtle strengths. The Locked Chest introduces a single point of failure: the chest’s own access mechanism. How do you bootstrap the master key onto a new server? You often end up with another, smaller secret, leading to a nesting-doll problem. The Ledger, by contrast, bakes secret distribution into the deployment process itself. The ‘how’ of getting the secret is versioned, repeatable, and visible.
The trade-off, then, is not really about raw security—both can be made highly secure. It’s a trade-off between isolation and integration. The Locked Chest favors a clean, isolated secret lifecycle, separate from application logic. The Public Ledger embraces the messy reality that secrets are a core part of the infrastructure’s state, and their management should be as traceable and reviewable as a code change. One creates a hardened, solitary artifact; the other weaves secret-handling into the very fabric of the system's operational history. Neither is universally right, but the choice between them reveals a deeper preference: do you want your secrets kept in a private vault, or managed on a public, albeit heavily guarded, record?
Notes & further reading
A few pages I came back to while writing this: