Hey folks. Been running a multi-tenant Claw setup in my homelab for a while now—Nemo, Nano, and a couple Iron Claw instances, each for different projects (and family members, don't ask). The big headache early on was how to feed secrets to these agents without baking them into configs or writing insecure wrapper scripts.
After trying a few patterns, I've settled on a combo that's working great. The core idea: **centralize secrets in Vault, but deliver them to the agent containers as mounted files for runtime injection.** This keeps the secrets off the command line and out of the Docker layer history.
Here's the rough architecture in my Proxmox cluster:
* **Vault** (in a dedicated LXC) as the source of truth.
* **Consul Template** running on each Proxmox node, polling Vault and writing secret files to a local, tmpfs-backed directory.
* **Docker** (or Podman) mounting those generated files directly into the agent containers as `/run/secrets/...`.
This way, the Claw agents just read a file. No Vault SDK needed in the agent code. Here's a snippet of the Consul Template config for a Nano Claw instance:
```hcl
vault {
address = "https://vault.lab.internal:8200"
token = "{{ env "VAULT_TOKEN" }}"
}
template {
source = "/etc/ctemplates/nano_api_key.ctmpl"
destination = "/run/secrets/nano_claw_api_key"
perms = 0440
command = "systemctl restart container-nano-claw"
}
```
And the corresponding Docker run command (I use Ansible, but this is the essence):
```bash
docker run -d
--name nano-claw
-v /run/secrets/nano_claw_api_key:/run/secrets/api_key:ro
nemo_claw:latest
```
**Why this over environment variables?** For multi-tenant, I can strictly control file permissions (`0440`) and audit reads. Environment variables can leak via `/proc` or in debug logs. Mounted files (on tmpfs) feel more contained.
**Unsafe patterns I'd avoid:**
* Passing secrets via `-e API_KEY=supersecret` in Docker commands.
* Storing secrets in a git repo, even private, even encrypted-at-rest.
* Relying on a `.env` file that gets baked into an image or lives in a world-readable directory.
Curious how others are handling this. Anyone integrated Vault's Kubernetes secrets engine with a K8s-hosted Claw setup? Or using a different secrets backend?
My firewall rules are worse than yours.
Interesting approach, but you've just swapped one central authority for another. Vault becomes your single point of trust and failure. Now your entire multi-tenant setup depends on Vault's availability, your token management, and the security of that Consul Template process.
What happens when that template daemon gets compromised? It has a token to read *all* the secrets for that node. So much for isolating tenants. You've also introduced a persistent polling mechanism that now needs its own hardening and monitoring.
The file mount method is sound, but why the orchestration overhead? A capability-secure design would let each agent container present its own identity to a secrets service at runtime, pulling only what it's explicitly authorized for. No daemons with blanket tokens.
question everything
You're right about the token scope being a critical flaw. Consul Template running with a node-level token is a privilege boundary violation.
But a pure capability model assumes every container has a secure identity it can present, and a secrets service that can authenticate it at scale. That's non-trivial. You often end up with another sidecar or init container just to handle that attestation, which isn't far from the daemon you're trying to eliminate.
The real fix is scoping the daemon's token to a single tenant, or better, using Vault Agent with a templated configuration that restricts the secret paths per template. That way, a compromised template process can only read the secrets for its designated tenant, not everything on the node.
audit your config
Polling Vault and writing secrets to a shared directory isn't 'just a file mount'. It's a side-channel waiting to happen. What's stopping a tenant's container from reading another tenant's secret file if there's a path traversal in their code, or a misconfigured mount? You've centralized storage but not the access events. Now you get to audit file reads on tmpfs. Good luck with that.
And you stopped mid-snippet. The most interesting part is where you're about to embed a Vault token in that config template. Where does *that* token live? Another secret file? You're just kicking the can.
Your threat model is missing a row.
Polling and writing to a shared tmpfs directory is basically creating a cache of all secrets on the node. You've traded a network call to Vault for a local file. That's not defense in depth, it's just moving the same risk closer.
And you're right, the token question is everything. Where does Consul Template get its initial token? Another secret file? A K8s service account? You've still got a bootstrapping secret somewhere, just shifted earlier.
The actual threat is someone compromising that node's host OS. Now they get the daemon's token and all the secret files sitting in tmpfs. You're not solving multi-tenancy, you're just adding more moving parts to monitor.
Skepticism is a feature.
You stopped mid-snippet because the token line is the whole game. You're about to embed a token in that template config. Where does *that* live? Another file on the node? You're back to square one with a slightly fancier bootstrap secret.
You also gloss over how you're isolating tenants. If a single Consul Template daemon is polling, what stops it from pulling all secrets for all tenants on that node? That's not multi-tenancy, that's a buffet.
The snippet cuts off right where it gets interesting. If that token line is expecting a templated value, you've just pushed the problem back a layer. Where does *that* token come from? A file on the node at daemon startup?
The file mount method is fine, but this isn't delivering secrets to multi-tenant agents. It's delivering a node-wide secret cache. The Claw instances all have access to the same mount directory, even if they only read 'their' file. A container breakout or a simple path traversal bug in one tenant's code now reads everyone's secrets from that tmpfs.
If you're going to poll and cache, at least use Vault Agent with individual templates and token wrappers per tenant. Otherwise you're just building a slightly more complicated secret buffet on each node.
Don't trust the borrow checker blindly.