Status#
Accepted (supersedes all previous containerization guidance)
Context#
EvilBit Labs products — including DaemonEye — are endpoint security tooling that requires deep host-level access: process enumeration, filesystem monitoring, privilege management, and IPC via Unix sockets or named pipes. Containers introduce an abstraction layer that conflicts with these requirements:
- Privilege escalation — Accessing host processes from a container requires
--pid=host,--privileged, or elevated capabilities, negating container isolation benefits. - Security surface — Privileged containers expand the attack surface rather than reducing it.
- Airgapped environments — Container runtimes add deployment complexity in restricted networks.
- Operational model — DaemonEye components (procmond, daemoneye-agent) are designed as system services, not microservices.
Prior guidance was inconsistent across documentation, standards, and templates. Operators could reasonably read the project as container-first, which both mis-frames the product and risks operators deploying insecure configurations in production. This ADR establishes a single canonical policy and retires all prior guidance.
Decision#
Canonical stance#
EvilBit Labs products are designed for host-first deployment. Containerization is supported but not recommended for production, especially in security-sensitive or airgapped environments.
Permitted container use#
Containers may be used for development, CI, or non-sensitive deployments.
Production container restrictions#
Any production container use must follow these strict guidelines:
| Restriction | Rationale |
|---|---|
| No privileged containers | Negates all container isolation benefits |
No --pid=host, --network=host, or similar flags | Breaks namespace isolation that containers provide |
| No mounting sensitive host paths | Exposes host filesystem to container escape risk |
| No escalation of container capabilities | Minimizes attack surface |
| Compose/Helm examples must be marked as non-production | Prevents accidental production deployment of insecure configurations |
Unsafe example policy#
All unsafe container examples and contradictory statements in existing documentation must be either removed or explicitly qualified as non-production.
Consequences#
Positive#
- Clear deployment guidance. Eliminates ambiguity about the recommended deployment model.
- Security posture. Prevents accidental deployment of privileged containers in production.
- Operational simplicity. Host-first deployment avoids container runtime dependencies in airgapped environments.
- Consistent documentation. Single authoritative policy for all containerization guidance.
Negative#
- Teams accustomed to container-first workflows may find host deployment unfamiliar. Mitigation: provide clear host deployment guides and system service templates.
- CI/development container examples may drift toward production patterns. Mitigation: all container examples must be explicitly marked as non-production.
- Future container-friendly features may conflict with this policy. Mitigation: any new container guidance must be reviewed for ADR-0005 consistency.
Neutral#
- All documentation, standards, and templates must reference ADR-0005 for container policy going forward. Existing docs that discuss containerization need a compliance pass; the effort is one-time and proportional to the doc's relevance.
- Product documentation must clarify that host-first is the recommended deployment model.
Alternatives Considered#
Container-first deployment model#
Package and distribute DaemonEye primarily as containers (Dockerfile, Helm chart, Compose file), with host deployment as a secondary option. Pros: familiar workflow for many operators; standard CI/CD integration. Cons: requires --privileged or equivalent to function (negating the isolation benefit of containers); expands attack surface; doesn't fit airgapped environments; misrepresents the product as a microservice when it's a system service. Rejected — the abstractions containers provide are actively harmful for this product class.
Hybrid / co-equal model#
Present host and container deployment as equivalent first-class options. Pros: maximum operator choice; no one is "wrong." Cons: ambiguity in documentation invites insecure production container deployments; teams default to containers because they're familiar, not because they're right for this product; doubles the maintenance surface for deployment examples. Rejected — co-equal framing produces the exact pattern this ADR exists to prevent.
No official policy#
Leave deployment guidance scattered across existing docs without consolidation. Pros: no immediate work. Cons: the current state — contradictory guidance, unsafe examples in Compose files, operators reaching wrong conclusions. Rejected — the cost of the status quo is the reason this ADR exists.
