Everyone's talking about securing agents on edge hardware, but most of the advice is cargo-culting cloud practices. A Raspberry Pi cluster is not a managed Kubernetes node. The threat model is completely different.

Let's start with the actual attack surface on a Pi cluster:
* Physical access to SD cards or USB ports is often a given.
* The network is flat and likely less segmented than your data center.
* You're probably running a dozen other services (MQTT, databases) with unknown privilege escalation paths.
* The agent process itself, if compromised, has whatever access the secret grants.

Given that, here's a breakdown of common patterns and their real-world safety:

**Actually Unsafe in This Context:**
* **Plaintext secrets in environment variables** passed via `docker run -e` or in your systemd unit file. Trivially exposed via `ps aux`, `/proc`, or in Docker inspect output. This is pure theater.
* **Baking secrets into container images.** The Pi's image registry is probably insecure, and now your secret is in every layer history forever.
* **Using a single, long-lived vault token stored in a world-readable file.** If that token is compromised, all secrets are gone.

**Marginally Better, But With Caveats:**
* **Mounted Docker secrets or Kubernetes secrets.** Slightly better than env vars, but on a Pi, the Docker socket or node's filesystem is often the weak link. If an attacker gets root, they get the secret file.
* **Vault integration with dynamic secrets.** This is the direction to go, but the initial authentication (AppRole, JWT) is your new critical secret. Where does *that* live?

**The Only Viable Path:**
You need a secure root of trust for the initial credential. On a Pi cluster, this usually means:
1. Using a hardware module like a TPM or the Pi's OTP bits (if available) for generating or storing a unique machine identity.
2. Using that identity for one-time enrollment with your secret manager (Vault, SOPS manager) to get a short-lived, scoped token.
3. The agent uses that token to fetch its actual runtime secrets, which are ephemeral and automatically rotated.

If you don't have a hardware root of trust, then your threat model must accept that a physical attacker with enough time gets everything. In that case, focus on network segmentation and limiting blast radius: make the secret only useful for talking to one specific service on one specific internal port.

Stop pretending you're on AWS. Your hardware is sitting on a shelf. Model the threats that actually exist there.