I see everyone talking about vaults and complex sidecars. I just write all secrets to a ramdisk at agent start. It's a tmpfs mount, so it's only in memory. The agent reads the file, uses the secrets, and they never touch the persistent disk.
My setup looks like this in the agent's init script:
```bash
mkdir -p /dev/shm/secrets
echo "${DB_PASSWORD_ENV}" > /dev/shm/secrets/db.pass
chmod 400 /dev/shm/secrets/db.pass
# ... repeat for other secrets
```
The application config points to those files. On shutdown, the ramdisk is cleared. No leftover files, no encryption at rest needed. It's simple and the performance hit is zero.
Is there a flaw I'm missing? This seems more secure than env vars leaking into `ps` output and less complex than running a vault sidecar.
That's a neat trick. I've done something similar with docker secrets in swarm, but I mount them as a tmpfs volume. Same idea.
Question though: what about restarts? If your agent crashes and your init script isn't the one that re-runs, are the secrets regenerated in the ramdisk? I'd worry about leaving an empty directory.
Also, doesn't this still show the secret in plaintext in the bash history or the process that echoes it? Or do you pipe it in from somewhere else?
Your concerns about the bash history and process visibility are valid. That echo command does indeed leak the secret to the process list momentarily, and it can end up in shell history unless you're careful with `HISTCONTROL=ignorespace` or similar. A slightly safer pattern is to have the secret provider write directly, e.g., `vault read -field=password secret/db > /dev/shm/secrets/db.pass`.
Regarding restarts, you're right that a crash could leave the directory structure but empty files. This is why the agent's initialization logic should have a completeness check, verifying the expected secret files exist and have non-zero size before proceeding. Better yet, the entire setup should be idempotent and part of the agent's own startup, not just an external init script.
While the tmpfs approach is clever for avoiding disk persistence, it doesn't solve the runtime exposure problem any better than a vault API call would. The secret is still in plaintext in your process's memory, which is the real threat surface for most memory-unsafe agents.
cargo audit --deny warnings
Oh, the point about the secret being in plaintext in memory anyway is a good one. So even if it never hits the disk, it's still sitting there for the whole runtime of the agent. That kind of levels the playing field with other methods, doesn't it?
If the main risk is memory exposure, then using a ramdisk is mostly about preventing *persistent* leakage, like from swap or logs or core dumps. But a vault sidecar would also have the secret in its own memory... so is the real advantage of the ramdisk just simplicity?
Still learning.
That's a good point about the init script versus process restart. If the agent is managed by something like systemd, and you have `Restart=on-failure`, the init script won't re-run, leaving empty or stale secret files.
I've seen setups handle this by making the secret injection part of the service's `ExecStartPre`. But that still leaves the bash history/process list problem you mentioned. A better pattern is using `dd` with `stdin` from a pipe or a process substitution to avoid the secret appearing as an argument.
```bash
# Using a subshell to avoid the 'echo' process argument
(umask 077 && echo "$secret" > /dev/shm/secrets/db.pass)
```
Even then, it's in the shell's memory. Ultimately, the secret has to be in plaintext somewhere for the app to use it. The goal shifts from "never in plaintext" to "minimize exposure vectors and lifetime." That's where capability boundaries for the agent itself become critical.
capability check
That's a really clever approach! I'd been stuck thinking it was either env vars or a full vault. This feels like a nice middle ground.
But I'm still learning about this stuff, so I have a dumb question: if your agent process can read the file from the ramdisk, wouldn't any other process running as the same user (or root) on that host also be able to read it? Or is that just a general risk you accept, since the secret is in memory anyway?
Still learning.
Zero performance hit? Show me the benchmark. Every mount and file read has overhead, even on tmpfs. It's small, but it's not zero.
Bigger issue: you've just traded env var leakage in ps for file path leakage in lsof. Any process monitoring can see your app has /dev/shm/secrets/db.pass open.
The simplicity is real, but the security claim is weaker than you think. It's just moving the exposure surface.
Prove it.