Zero Trust in Octelium

Zero trust is a security model in which network location does not create implicit trust. Access to protected resources is explicitly authenticated and authorized according to least privilege, using identity, resource state, device posture, and other contextual signals rather than assuming that a request is trustworthy because it originates from an internal network.

NIST SP 800-207 formalizes the main principles and logical architecture of zero trust. Zero trust is not a product category or a single protocol. It is a security model that can be implemented through different architectures and enforcement mechanisms.

This page maps the principles and logical architecture described by NIST SP 800-207 to concrete Octelium mechanisms. Each section links to the relevant documentation so that the architecture and behavior can be examined directly.

How Octelium Applies Zero Trust

• Resources are protected directly. Protected applications, APIs, SSH servers, databases, Kubernetes clusters, DNS services, TCP/UDP applications, protected public resources, and managed containers are represented by Services. Access is authorized against the Service and its request context rather than inferred from access to the network containing the upstream resource. Read more about Services here.

• Network location does not create implicit trust. Connecting to an Octelium Cluster or reaching a Service does not itself grant access. Human and workload subjects are represented as Users and access the Cluster through Sessions. Human Users can authenticate through OpenID Connect or SAML 2.0 IdentityProviders and built-in Authenticators, while workloads can authenticate through OAuth2 client credentials, bearer access tokens, authentication tokens, or OIDC assertions from external workload identity systems such as GitHub Actions, cloud providers, and Kubernetes clusters. Read more about IdentityProviders here, Credentials here, and Sessions here.

• Communication is secured regardless of network location. Private client-based access is carried through encrypted WireGuard or QUIC tunnels, while public clientless access uses HTTPS and standard web authentication flows. The same Service, identity, Policy, and audit model applies whether the request originates from a private client connection or a public clientless access path. Read more about how Octelium works here.

• Access is explicitly authorized through a policy enforcement and decision architecture. Requests pass through the Service's identity-aware proxy, Vigil, which acts as the policy enforcement point (PEP). Vigil builds the request context and sends it to Octovigil, which acts as the policy decision point (PDP), for an authorization decision. This architecture maps directly to the logical PEP/PDP model described by NIST SP 800-207. Read more about the request lifecycle here.

• Access decisions use dynamic context. Policies, written in CEL or OPA, can evaluate the User, Group memberships, Session, Device, authentication state, Service, Namespace, geolocation, request context, and arbitrary attributes supplied by external systems such as SIEM, threat intelligence, on-call management, and other security or operational tools. Read more about Policies here and extending access control with attributes here.

• Device state and posture can contribute to authorization. When a Session is associated with a Device, Policies can use current Device information as part of the access decision. Where posture information is available, policy decisions can also incorporate signals from device-management, endpoint-security, or posture systems rather than relying only on user identity. Read more about Devices here.

• Authentication and authorization are continuously reevaluated. Session access tokens are not treated as sufficient stateless proof of authorization. Octelium resolves current Session, User, Group, Device, and policy state during authorization, so rejecting or deleting a Session, disabling a User, or changing Policies can affect subsequent access without waiting for a long-lived token to expire. Authentication strength is tracked through authenticator assurance levels (AAL), and Users can be required to re-authenticate using FIDO2/WebAuthn/Passkey, TPM 2.0, or TOTP Authenticators. Read more about Sessions here and Authenticators here.

• Access activity is continuously logged and exported. Octelium emits structured access Logs for allowed and denied access at the granularity supported by each Service mode. Logs can identify the User, Session, Device, Service, authorization result, matching Policy and rule, and protocol-specific request or connection information such as HTTP paths and methods, database queries, Kubernetes operations, SSH session information, DNS requests, and TCP/UDP flow metadata. Logs are emitted in real time to OpenTelemetry OTLP receivers for integration with observability, logging, and SIEM systems. Read more here.

Additional Least-Privilege Mechanisms

The following Octelium capabilities are not separate NIST tenets, but they further reduce authorization scope, standing access, and credential exposure.

• Application-layer-aware authorization. Because many Services are implemented as application-aware identity-aware proxies, Policies can authorize requests using protocol-specific context. This can include HTTP method, path, headers, query parameters, and serialized JSON body fields; database query context; Kubernetes API verb, resource, namespace, and API version; SSH user; DNS request information; and other mode-specific fields. Read more about L7-aware Policies here.

• Dynamic secretless access. Users can access protected APIs, SSH servers, PostgreSQL and MySQL databases, Kubernetes clusters, and mTLS-protected resources without receiving the upstream API key, password, private key, kubeconfig, or client certificate private key. Upstream credentials are stored as Secrets and used dynamically by the Service when authenticating to the upstream, so long-lived upstream application credentials do not need to be distributed to Users or workloads. Read more here.

• No inherent superuser or implicit administrative privilege. Octelium intentionally has no built-in "admin" or "superuser" User. Access to every Service, including the API Server itself, must be explicitly granted through Policies and can be constrained by identity, time, authentication state, device state, resource context, and request context. Read more here.

• Context-aware dynamic configuration and routing. Authorization is not the only behavior that can be selected from request context. Octelium can dynamically choose upstreams, upstream accounts and credentials, protocol-specific configuration, and routing behavior using CEL or OPA expressions evaluated from the current request context. Read more about dynamic configuration here.

• Sandboxed execution with identity-based access through Cordium. Cordium is an open-source, self-hosted sandbox platform built on Octelium. Processes running inside Cordium Workspaces, including developer tools, automated workloads, and AI agents, can access authorized Octelium Services through Workspace identity without distributing upstream API keys, SSH keys, database passwords, or other application credentials into the sandbox.

What Zero Trust Is Not

Zero trust is not defined by a single technology or product label.

• Network segmentation alone is not zero trust. Segmentation and microsegmentation can be useful enforcement mechanisms inside a zero trust architecture, but network location or membership in a network segment must not by itself create implicit trust.

• MFA alone does not create a zero trust architecture. Strong authentication is an important input to access decisions, but successful authentication should not automatically grant broad or unrelated access. Authorization still needs to be explicit, least-privileged, and based on the resource and current context.

• VPN connectivity alone is not zero trust. A secure tunnel can be one transport mechanism inside a zero trust architecture, but establishing the tunnel should not itself grant broad network access. Octelium uses encrypted tunnels for private client-based access while still authorizing access against individual Services and Policies.

Where to Go Next

• See the architecture: How Octelium Works walks through the identity-aware proxy model, the request lifecycle, the PEP/PDP separation, private and clientless access paths, and the control plane.

• See the enforcement model: Policies and access control documents the policy-as-code model, request context, Policy evaluation behavior, and L7-aware authorization.

• Understand the resource model: Services, Users, Sessions, and Devices document the resources used in access decisions.

• Try it yourself: the quick installation guide installs a full Cluster on a Linux VM, and the implementation is available in the Octelium source repository.