Orchestrator

Security

This page lists what the Orchestrator protects, what it leaves to you, and the setting that matters most when workspace administrators are not fully trusted.

What it protects

  • Console sign-in. The global administrator and the console users sign in with a password. A session is a random token in an HttpOnly, SameSite=Strict cookie scoped to /api/. Only its SHA-256 is stored. Failed sign-ins are throttled per client address, 5 in 5 minutes.
  • The API token. ORC_API_TOKEN grants the same access as the console. It is compared in constant time and never shown on the Settings page.
  • Console users' passwords are PBKDF2-SHA256 hashes.
  • Landing sign-in. The cookie is HttpOnly, SameSite=Lax, and never forwarded to a workspace or a node.
  • Open redirects. The starting page follows a return address only to the same workspace on the same origin or on its own subdomain.

What you protect

  • ORC_STORAGE holds the workspaces' administrator passwords and the accounts' passwords in the database, and the self-signed key. Protect that folder like a secret. A fleet's fleet.key is created with mode 0600.
  • The Docker socket is root on the host. Whoever controls the Orchestrator controls the host's containers, and the Orchestrator's container, when you run it in Docker, holds the socket.
  • Custom HTML runs on every page of the Orchestrator, the console included. Only the global administrator edits it.
  • The console password lives in an environment variable or file. Keep the file readable by root only.

Untrusted workspace administrators

Every workspace served on a path shares the Orchestrator's origin. A workspace administrator who writes a custom front-end could make API calls with a signed-in console administrator's cookie.

If workspace administrators are not trusted, set ORC_MANAGEMENT_HOST to a separate host name, for example manage.example.com, and point it at the same server. The console and its API then answer only there, and workspaces are not served there. Opening workspaces on their subdomains gives each one an origin of its own as well.

With landing sign-in, workspaces on the path route can also call a sibling workspace as the signed-in visitor, as they could read its token there anyway. On their subdomains they cannot, because the proxy checks Sec-Fetch-Site.

Fleet

A central holds every node's secret and can run any image on any node. Protect it like the most sensitive node and put its console on ORC_MANAGEMENT_HOST. Node secrets, the API tokens of attached Orchestrators and enrollment codes are sealed with ORC_STORAGE/fleet.key. Join tokens are kept as hashes. Use HTTPS between the central and the nodes: over plain HTTP the signatures still authenticate every call, but nothing hides the traffic. See Fleet.

Network exposure

  • ORC_RESTRICT_LOCALHOST=true listens on loopback only.
  • ORC_HIDE_FROM_SEARCH_ENGINES=true asks crawlers to stay away. It is not access control.
  • Workspaces are reachable without the console. Anyone who knows an address can open a workspace and wake it. Each workspace asks for its own sign-in, and with landing sign-in the landing page asks first. Waking a sleeping workspace is not gated.