Internal service trust

Every Clearplane-to-Clearplane connection on clearplane-internal uses HTTPS 8443 with mutual TLS. Both sides authenticate the connection; network membership alone is not enough.

Exact service identity

Core generates a private root and a matched certificate generation for Edge, Core, UI, and ContainerProxy. Each service certificate carries an exact Clearplane service identity. A caller must present the identity allowed by the endpoint, and the server certificate must match the service the caller intended to reach.

Clearplane validates this private chain without adding the root to the host operating system trust store. It has no plaintext, permissive-certificate, workload-password, or bearer-token fallback for internal service traffic.

Certificate distribution

Core writes the matched internal certificate material to the service data volumes. Edge, UI, and ContainerProxy each mount only their own service data volume read-only; Core retains the writer role. Missing, malformed, mismatched, symlinked, or incorrectly permissioned material fails closed instead of weakening validation.

Treat these volumes as one certificate generation. Copying one service's certificate material into another service breaks the identity relationship rather than granting a generic internal credential.

Separation from upstream traffic

Internal client certificates stay on clearplane-internal. Edge does not forward its Clearplane service identity to applications on clearplane-services, and customer upstreams cannot become trusted internal peers by presenting a hostname or label.

This separation protects the control-plane trust domain from the applications it proxies. It does not authenticate the application protocol itself; use the upstream application's own authentication and transport controls where needed.

Unsigned local rules

Only a ruleset in the reserved local namespace — the identifier local, or one starting with local- — may be unsigned. Edge accepts its definition from Core over the exact-identity mTLS channel, checks its content hash and compiles it before activation. An unsigned definition cannot replace a signed Cloud ruleset.

Operators write and test custom rules in a saved draft. Publishing requires the management permission and passing integrity tests; saving a draft alone never changes Edge's rules.