jochen
e387c4bd0e
The fact-check found mailu, whose user is its mailbox, so 0114 rotates over two credentials rather than two logins, the adapter choosing what a credential is. Also: minio keeps non-empty buckets; five backends take their admin credential only at first init, so single-party rotation is staged; postgres ownership moves to a non-login role; the harness keys by consumer; rotation state lives with the vault. Consistency fixes across 0110-0113, 26 and 27; issue 103 resolved by mesh-host PR #22.
2.7 KiB
02 — The readers
How a secret reaches a running process, and what makes the process take a new one.
No module watches a secret
A search of every module's code in the catalogue found no file watching of any kind, and no re-reading of a secret while running. Every reader reads a secret when it starts. There is no consumer that takes a new value live, so every rotation that changes what a consumer presents ends in the consumer restarting.
The host already recreates what read a changed file
The node host records, for every long-running container, the digest of each file it read when it was created: its env-files, and every file bind-mounted into it directly. When a digest changes, the host recreates the container, even though its spec is otherwise unchanged. This is the fix for issue 103. It is on the host's main branch, while the issue is still recorded as located, not fixed.
Two cases are deliberately left out and need restart-on in the definition:
- a file read out of a mounted directory, because the host cannot know whether the service reads it once or watches it (a route proxy re-reads its routes live; a provisioner polls what it receives);
- a process rather than a container.
What the catalogue does with it
22 definitions declare a secret they receive. In 16 of them it reaches the service through a
rendered file, usually an env-file. That case the host already covers. 14 declare restart-on for
something. Whether each of the 22 is fully covered depends on how its secret travels: through an
env-file or a direct mount, which the host covers, or through a directory or into a process, which
needs restart-on. That was not classified module by module. It is the check to run before a
rotation mechanism relies on it.
The count covers only the secrets field. The 49 modules with their own bus account, and 54 with any
own secret, are readers too, and their bus accounts are rotated like any credential two parties hold.
Their files are mounted directly, which the host covers, but the classification has to name them.
What this means for rotation
- The read at start half of 0113's recipient model is already true, and mostly already handled by the host. The restart is derived from the files a container reads, not declared per secret.
- Any mechanism, in place or overlapping, ends with the reader being recreated. What differs is whether the credential it held until then still works.
- For a single-party secret, a module's own, the reader is also the only holder. There is nobody to overlap with, and delivering the new file recreates the reader.