Module secret_mount 

Where yubaba writes a File-target secret it has resolved, and how the host path is derived from the container path.

Why the derivation lives here and not in yubaba

yubaba resolves a SecretMount and rewrites it into a read-only Bind volume before the spec reaches the backend, so the spec kamaji admits is not the spec the dispatcher signed: one mount has become one bind. Admission has to be able to recognise that rewrite — otherwise a signed recipe carrying a secret is refused by admission::AdmissionGrant::covers’s bind rule, which only knows about forge_state::HOST_ROOT, with a message about a forge state root that has nothing to do with what happened.

Recognising it means recomputing the host path, which means the derivation has to be visible to both sides. It was private to yubaba’s deploy::secret_mount; it lives here now, and yubaba calls in. forge_state is the same shape for the same reason.

Constants

HOST_ROOT

RAM-backed root for materialized secret files. /run is a tmpfs on systemd nodes, so decrypted PEM never touches disk. Each workload gets a <root>/<ident>/ subdir, reaped on workload destroy.

Functions

host_file_name

Derive a collision-free host filename from a container target path: strip the leading /, keep . for extensions, and replace path separators (and any other non-[A-Za-z0-9_.-] char) with _. A target that reduces to nothing or a dots-only name falls back to secret. The result is always a single flat filename (no separators), so it cannot traverse out of the per-workload dir.

materialized_host_path

The host path a File-target secret at container path target is materialized to for workload ident.

sanitize_component

Collapse a value into a single safe path component: every char outside [A-Za-z0-9_-] becomes _ (dots included, so . / .. can never traverse). Empty input maps to _.

workload_dir

The per-workload directory materialized secrets are written to.