Exposure and network boundaries

In the supported topology, Edge is the only Clearplane container with host port mappings. Public HTTP reaches Edge on TCP port 80. Public HTTPS uses TCP port 443 for HTTP/1.1 and HTTP/2 and UDP port 443 for HTTP/3; Core, UI, and ContainerProxy publish no host ports.

This remains true only while the deployment keeps those boundaries intact. Publishing an application or control-plane port separately creates another public path that Clearplane cannot protect.

Network wiring

Joining clearplane-services does not publish a host port. To keep Edge as the only public request path, application containers join this network and do not publish their application ports to the host.

Management exposure

Management access also enters through Edge. When enabled, ordinary protected routes expose the browser UI and management API on the selected public host:

• / routes to UI over clearplane-internal.
• /api/{**catch-all} routes to Core and rewrites to /external/{**catch-all}.
• /api/ws/* uses the same API route for browser event connections.
• /api/metrics serves Prometheus metrics to a session with Metrics.Read or a scrape token.
• /internal/* is not part of the public route contract.

The UI and API therefore use the same public ingress and route controls as other services without exposing their containers directly.

Browser and API clients use the HttpOnly, SameSite=Strict session cookie issued by the external sign-in endpoint. API clients keep that cookie in a cookie jar and send the fixed CSRF header on unsafe requests; the sign-in response contains session status and expiry, not a bearer token.

A sign-in session expires 24 hours after it is created; activity and dashboard refreshes do not extend it. Closing the browser can also end the browser session.

Management route defaults

Core and UI use ordinary clearplane.proxy.* labels and the same policy pipeline as application routes. The shipped routes and their configuration resources appear in the System resource group.

The shipped Compose file gives both containers one YAML anchor, x-clearplane-management-labels, whose labels create each route's own access control, rate limit (600 requests per minute), automatic ban, request headers and response headers policies, a Detection WAF policy with the Management profile, and branded 403/502/503/504 error pages; caching is off. Access control defaults to Block and allows only CLEARPLANE_MANAGEMENT_ALLOW_ADDRESSES, so set it to your administrator address or narrow VPN CIDR before browser access. If the allow-list admits a private range broader than a /24, discovery warns that it can cover Docker's default address pools. To change another management policy, override its label on both containers.

When an enabled management route accepts every address, the Dashboard and Proxy routes show Management routes have no address restriction and name the affected routes. A route's own policies replace global ones, so the warning clears only when a policy that applies to that route defaults to Block; a removed assignment, a disabled policy, or an allow-by-default policy leaves the route unrestricted.

For a route mistake, inspect Proxy routes, Upstream clusters, Certificates, their policies, and discovery diagnostics. Edit Docker labels for label-owned resources and use the UI/API for API-owned resources. Management routes follow the ordinary ownership rules; there is no separate management-route reset command. Setup and account recovery are covered by Installation and CLI.

Outbound exports

Core can send optional WAF metrics over OTLP and WAF events to syslog over TLS, signed HTTPS webhooks and OTLP logs. Every new connection checks the resolved address against the global restricted destination classes and always refuses the control-plane network. Redirects and system proxy routing are disabled. Export credentials are encrypted at rest; list responses never expose them.

Configure destinations with Observability.Manage in System → Settings → Observability. See Export metrics and WAF events for token handling, formats, filters and retention limits.

Preserve the boundary

Apply the hardening checklist to keep these boundaries intact. See Architecture for the full runtime topology.