Store deployment secrets in a dedicated vault, fetch them at runtime, and avoid hardcoding values in deployment files or local environment state. Separate production credentials from development and CI credentials, then use the deployment tool to read only the secrets it needs. That keeps the deploy flow repeatable while reducing secret sprawl and accidental exposure across developer laptops and server configs.
Why Kamal Deployments Need Secret Boundaries, Not Just Convenience
Kamal can make container deployment feel simple, but the security model still depends on how SSH keys and application secrets are separated, stored, and delivered. The goal is to keep deploy-time access narrow and reproducible while preventing long-lived credentials from leaking into files, shells, laptops, or CI systems. That is why vault-backed retrieval and strict secret scoping matter more than convenience.
For containerized applications, the risky pattern is not merely “having secrets”, it is allowing the same material to serve too many purposes. Deployment access, runtime configuration, production API credentials, and local developer overrides should not collapse into one shared bundle. That is especially important for SSH keys used to reach hosts and app secrets used by the application itself, because each has a different blast radius and lifecycle.
When teams treat deployment files as the source of truth for secrets, they create two problems at once: durable exposure and weak change control. A better pattern is to keep the deploy definition readable without embedding sensitive values, then resolve only the required material at execution time from a controlled secrets store such as a dynamic secret model or a vault-backed workflow. That reduces the chance that a stale key or token survives long after the deployment that needed it.
For broader context on why this matters, NHIMG’s key challenges and risks section and secret sprawl analysis both reflect the same operational failure mode: credentials spread into too many places and become hard to inventory, rotate, and revoke. In a Kamal flow, the practical implication is to keep SSH access materialized as host access only, while application secrets remain application-scoped and rotate independently.
What Good Secret Handling Looks Like in a Kamal Workflow
A sound Kamal deployment flow usually separates three trust boundaries: the machine or user that launches deployment, the target hosts reached over SSH, and the application runtime that consumes secrets. Security teams should verify that each boundary has its own credential path. The deployer should not inherit production app secrets just because it can initiate a release, and the runtime should not need the deployer’s SSH material to function.
The easiest mistake is to store secrets in local environment state because it feels fast during setup. That approach makes troubleshooting easier in the short term but widens exposure across shells, dotfiles, developer laptops, CI runners, and ad hoc server configs. A vault-backed fetch at deployment or startup time is safer because it centralises control, supports rotation, and gives teams a cleaner revocation point when a secret is suspected to be exposed.
Kamal users should also distinguish between SSH keys for host access and app secrets for containerised service configuration. SSH keys should be limited to the smallest set of hosts and deployment actions required, while app secrets should be injected only into the runtime that needs them. For implementation detail on why long-lived secret material should be minimised, the NHI overview and top NHI issues are useful references because they cover lifecycle, ownership, and overprivilege patterns that map directly to automated deployment credentials.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | SSH keys and app secrets are identity-bearing material needing controlled storage and rotation. |
| NHI-02 — Lifecycle and Offboarding | Separating prod, dev, and CI credentials requires provisioning and revocation discipline. | |
| NHI-06 — Access Governance and Least Privilege | Kamal should read only the secrets required for deployment and runtime operation. | |
| Recommendation — Store deployment credentials in a vault and rotate them on a defined lifecycle. Revoke unused deployment secrets promptly and keep environment-scoped credentials distinct. Restrict deploy-time access to the minimum secret set needed for each environment. | ||
| CIS Controls v8 | 6.3 — Establish and Maintain an Inventory of Authorized Third Parties | Deployment tooling and CI paths often introduce third-party secret exposure points. |
| 6.7 — Centralize Account Management | Centralised secret handling reduces sprawl across laptops, CI, and server configs. | |
| 3.1 — Establish and Maintain a Data Management Process | App secrets and SSH keys require defined handling, retention, and disposal rules. | |
| Recommendation — Inventory every system that can read deployment secrets and remove unnecessary access. Centralize secret issuance and revocation so changes propagate consistently. Apply formal handling rules for secret storage, rotation, and disposal. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication, and Access Control | Kamal deployments depend on controlling who and what can access secrets and hosts. |
| PR.DS — Data Security | Secrets are sensitive data that must be protected at rest and in transit. | |
| GV.PO — Policies, Processes, and Procedures | Secret handling in deployment workflows should be governed by documented process. | |
| Recommendation — Enforce least-privilege access for deployment identities and runtime secrets. Protect secrets with controlled storage and secure delivery mechanisms. Document deployment secret handling rules and enforce them consistently. | ||
Practitioner Guidance
What to prioritise: Audit where SSH keys and app secrets actually live during the deploy path, then remove any copy that is not required for the release to succeed. The highest-value fix is usually eliminating secret duplication across deployment files, developer environments, and CI variables.
What to verify: Confirm that the deployer can read only the secrets needed for the current environment, that production and non-production credentials are isolated, and that rotation will not break the deploy flow. If a secret is needed outside runtime or release time, treat that as a design smell.
Common mistake: Teams often harden the host SSH key while leaving the real exposure in app secrets, or they solve secret delivery for one environment and silently copy the same pattern everywhere else. That creates a false sense of control because the release works, but the secret lifecycle remains unmanaged.
Practitioner takeaway: The right target is not “secure deployment files”, it is a deployment process where secrets are short-lived, environment-specific, and retrievable only by the component that truly needs them.
Related resources from NHI Mgmt Group
- How should security teams handle secrets in frontend applications?
- How should security teams handle cloud secrets that are shared across applications and pipelines?
- How should security teams handle legacy app access when older applications still need to connect to modern cloud identities?
- How should security teams handle weak SSH keys that grant broad GitHub access?
