Security model
Opfield’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 Opfield and managed-node placement, the security owner defines identity and secret policy, and resource owners approve access to their workloads and data.
Opfield 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.
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 Opfield identity for managed transport;
- explicit resource scopes and separate reveal/export/mount permissions;
- encrypted secrets at rest and masked output by default;
- Opfield-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.
Opfield 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
Section titled “Trust boundaries”| Boundary | Security responsibility |
|---|---|
| Opfield host | Protect application secrets, database access, container runtime, persistent volumes, and administrator access |
| PostgreSQL and Redis | Keep private, authenticated, backed up, and restricted to Opfield 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 |
| Storage 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 Opfield host Docker socket are trusted at a high level. Opfield-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
Section titled “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. Credentials are not revealed during impersonation, Node console sessions and Node file reads are audited, and API tokens and the assistant cannot change their own account’s sign-in, MFA, or sessions, grant impersonation, or restore into groups beyond the caller’s permissions. The AI assistant asks for approval before it reveals or rotates credentials or exports private keys.
Secret handling
Section titled “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. The audit log redacts connection strings, secret URLs, webhook headers, and secret values, and container inspect, environment views, and archive export never show the passwords and keys of database and storage links.
Managed database workloads receive binding-specific identities, not owner credentials. The target Docker Node’s shared secure-link connector serves each binding on a private network of its own, which only the bound workload joins. Container links work the same way: each opens one port of the target, in one direction, to one consumer.
Where secrets live in a self-hosted installation
Section titled “Where secrets live in a self-hosted installation”Every plan can be self-hosted, and a self-hosted installation keeps its secrets in the environment you control:
| Material | Where it is stored |
|---|---|
| Credentials that Opfield stores for you: Docker secrets and environment values, registry credentials, DNS, Cloudflare, and hosting-provider tokens, SSH keys, OIDC and SMTP secrets, database and storage credentials, AI and Inference provider keys, webhook signing secrets, certificate-authority and ACME private keys, and the license key, installation token, and registration nonce | The installation’s own PostgreSQL database, encrypted with AES-256-GCM envelope encryption: each value has its own random data key, which is encrypted with the master key |
Master key (PKI_MASTER_KEY) |
Generated on the Opfield host during installation and kept in the installation’s .env file with restricted permissions; it is passed to Opfield services at start and is not stored in the database |
| Opfield’s own TLS private key | A file in Opfield’s persistent data on the Opfield host |
| Managed Node identity | The Node’s daemon private key stays on that Node |
| Managed database TLS keys | Daemon-owned storage on the Storage Node, outside the database image |
Anyone who controls the Opfield host, its .env file, or its Docker socket can reach this material. Keep the master key backup separate from database backups, and never paste .env contents into chat or support tickets. See Updates, backups, and restore for the recovery set.
What leaves a self-hosted installation
Section titled “What leaves a self-hosted installation”Opfield makes these outbound connections on its own. Everything else depends on integrations you configure, such as ACME and DNS providers, source-control systems, registries, identity providers, email, webhooks, SIEM receivers, and AI providers.
| Destination | Purpose | Data sent |
|---|---|---|
License service (license.thesqlabs.com) |
Registration after the first start, heartbeats every 15 minutes with a paid key or every 30 minutes on Community, key activation and deactivation, release authorization before an update, and commercial-core downloads for licensed installations | Installation ID, installation name, Opfield version, entitlements schema version, installation token, a random request nonce, and the pinned signing key IDs; a one-time registration nonce at registration, the paid key at activation, and the target version, release ID, and file path for updates. See Plans and entitlements |
Update service (updates.thesqlabs.com) |
Release checks at startup and every 4 hours by default (UPDATE_CHECK_INTERVAL_HOURS), and signed release downloads |
Release channel, component, and current version |
Container registries such as ghcr.io |
Pulling Opfield release images | Standard image pull requests |
| Public IP lookup services | Detecting the public addresses of Opfield and managed Nodes | Standard HTTPS requests; the Opfield backend skips the lookup when both PUBLIC_IPV4 and PUBLIC_IPV6 are set |
The installation script contacts only the update service, container registries, and Docker package repositories; Opfield registers with the license service shortly after its first start. The license and update services do not receive infrastructure configuration, resource contents, secrets, logs, prompts, or model responses. Opfield contains no usage telemetry or crash-reporting client. When AI Workspace or Opfield Inference is enabled, prompts go to the model providers that an administrator configures, not to Square Labs.
Responses from the license service are signed license states. Opfield pins the service’s Ed25519 public keys and accepts a state only when it was signed for this installation and request, and issued within 15 minutes of the local clock; it rejects unsigned, forged, replayed, or foreign states and verifies stored states again whenever it reads the license. See Signed license states.
Fail-closed examples
Section titled “Fail-closed examples”Opfield 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
Section titled “Security limitations”Opfield 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
Section titled “Security decision checklist”Before adopting Opfield for a production environment, identify who controls the Opfield 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:
- What data or infrastructure can it reach?
- Which credential authorizes that access and where is it stored?
- Which audit or Task evidence proves what happened?
- 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
Section titled “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.