Security model

Gateway’s security model helps an organization centralize infrastructure operations without pretending that one console removes the need to secure hosts, networks, identities, and backups. The platform owner controls Gateway and managed-node placement, the security owner defines identity and secret policy, and resource owners approve access to their workloads and data.

Gateway assumes managed hosts and administrators are consequential trust boundaries. It reduces reusable credentials and direct shell dependence through outbound daemon enrollment, PKI identities, resource scopes, audited operations, and bounded daemon roles.

Root-equivalent boundaries

The Gateway installation uses a writable Docker socket for supported host-level lifecycle work, and Docker Nodes control their local Docker Engine. Compromise of either boundary can become host-root compromise and can bypass product-level resource scopes. Run Gateway on a dedicated host or VM in a restricted management segment, isolate high-impact Node roles, and protect host administration independently of Gateway accounts.

A secure deployment succeeds when authority is explicit, credentials are not reused across trust boundaries, mutations are verified by the owning runtime, and failures do not silently fall back to a less secure path. “Reachable” is not the same as “authorized,” and “visible in cached inventory” is not permission to mutate.

Key principles:

• one-time enrollment rather than reusable node tokens;
• mTLS and pinned Gateway identity for managed transport;
• explicit resource scopes and separate reveal/export/mount permissions;
• encrypted secrets at rest and masked output by default;
• Gateway-owned internal containers excluded from user lifecycle APIs;
• separate application identities for managed database bindings;
• fail-closed behavior when ownership, entitlement, node state, or provider compatibility cannot be proven;
• immutable audit attribution after account lifecycle changes.

Gateway is not a host hardening product, firewall manager, general VPN, or replacement for engine-native backups. Secure the underlying operating systems and networks independently.

Trust boundaries

Boundary	Security responsibility
Gateway host	Protect application secrets, database access, container runtime, persistent volumes, and administrator access
PostgreSQL and Redis	Keep private, authenticated, backed up, and restricted to Gateway services
Relay	Preserve service identity, signed policy, database authorization path, and public 9443/tcp ownership
Managed Node	Protect daemon identity, systemd service, local runtime, storage, and role-specific privileges
Build Worker	Isolate untrusted source builds from ordinary workloads and host-control endpoints
Ingress Node	Protect TLS private keys, nginx configuration, logs, and public traffic
Database Node	Protect owner credentials, storage images, Database CA material, and engine administration
External provider	Apply provider-specific credential, retention, availability, and network controls

Administrators and anyone able to control the Gateway host Docker socket are trusted at a high level. Gateway-owned internal containers are hidden and protected from normal user lifecycle APIs, but this does not turn host-level Docker access into an untrusted boundary.

Identity and authorization

Human sessions, API tokens, OAuth, MCP, daemon certificates, service identities, database binding principals, logging tokens, and inference tokens are separate credential families. They are not interchangeable. The backend rechecks scopes, resource ownership, entitlements, and current state even when the UI hides an action.

Resource-scoped permissions limit which objects a user can see or mutate. Sensitive actions such as credential reveal, private-key export, host file access, console access, and secret mutation require distinct authority from ordinary read access.

Secret handling

Secrets are encrypted at rest and masked in normal responses. Write-only values must be replaced rather than retrieved. Keep master keys outside database backups, redact logs and screenshots, and avoid passing credentials through command arguments or repository URLs.

Managed database workloads receive binding-specific identities, not owner credentials. The target Docker daemon owns the private listener and allows only the intended stable workload identity on the binding network.

Fail-closed examples

Gateway rejects or defers operations when it cannot prove current ownership, node capability, plan entitlement, provider/model compatibility, signed update provenance, network source identity, or required authorization. Cached inventory may remain visible for diagnosis but cannot authorize a mutation.

Availability failures must not be “fixed” by introducing anonymous listeners, disabling certificate validation, exposing private ports, or copying owner credentials into workloads.

Security limitations

Gateway cannot protect a compromised administrator endpoint, malicious host root, unrestricted Docker socket owner, compromised external identity provider, or data deliberately exported by an authorized user. Use independent host hardening, network segmentation, endpoint security, backups, and organizational controls.

Security decision checklist

Before adopting Gateway for a production environment, identify who controls the Gateway host, Relay, every managed host, the external identity provider, source-control providers, DNS, email, AI providers, and backup storage. Document which parties can obtain plaintext application data or credentials. If one person or system owns several boundaries, record that concentration of privilege rather than assuming product scopes remove it.

For each new capability, answer four questions:

1. What data or infrastructure can it reach?
2. Which credential authorizes that access and where is it stored?
3. Which audit or Task evidence proves what happened?
4. What remains operational, and what must fail closed, when the dependency is unavailable?

Review the model after material topology, identity, provider, or entitlement changes. A design approved for one Ingress and one private database may not remain appropriate after adding Build Workers, public database access, external AI providers, or cross-team automation.

Operator assurance

Test denial as deliberately as success: an unscoped user, a revoked token, a Node with stale capability data, an unsigned or mismatched update, a workload without the binding identity, and a private outbound destination outside policy. Preserve the resulting audit and error evidence. Security controls that have never been exercised under failure should be treated as assumptions.