Control Plane

A single Sidecar reads one config file and needs nothing else. That is deliberate, and it stops working the moment you run twenty of them: twenty files, twenty deploys to change one rule, and no single place that says which rules are actually live. The Control Plane is that place. Sidecars register with it, ask it for their configuration, and it answers. Rules are written once and delivered everywhere.

---

​

How it works

The Sidecar is always the side that reaches out, and what it asks for is its configuration.

• Nothing to maintain: the Sidecar boots, finds its server host, loads the configuration available to it into memory, and keeps running. There is no session to hold open and nothing to reconnect.
• The token is the authentication: the Sidecar pings with its token, and the Control Plane answers — I know which Sidecar you are, use this configuration.
• Ordinary HTTP: configuration moves over a plain request and response. Nothing is tunnelled, so neither side has to know the other’s physical address.

A Sidecar that loses contact keeps serving traffic with the configuration it already holds, so a Control Plane restart is not an outage for the resources behind it. The exception is a listener that holds statements for human review: it files each held statement with the Control Plane, so while the Control Plane is unreachable, every statement that listener would hold is denied.

---

​

What it solves

​

Rule combinations decided once

Features apply per resource, and the combination is decided in one place rather than reconstructed from whatever each config file happens to say. The cost of understanding the whole environment drops to reading one screen.

​

Pre-configured rule sets

Without a Control Plane, protecting a resource means writing a Guardrail, then configuring an Analyzer, then adding Data Masking — three separate edits that have to agree with each other. The Control Plane ships them as sets: one action applies a whole posture to a resource.

​

Human review of held statements

An analyzer risk level set to require_review holds the statement for a person. The Sidecar files it with the Control Plane, and the listener’s approval_rule names the access request rule that decides who may approve. The statement waits on its connection for up to 30 minutes, and an approval in that time runs it. After a timeout, an identical retry after approval goes through once. With review_mode: return the statement is denied at once instead, for agents that resend it after approval. A rule can limit the time to decide and the time to use an approval; a review past its limit expires and releases nothing. See Holding a statement for a person.

​

One view of every Sidecar

Which Sidecars are running, what each one resolved, and when it last checked in.

---

​

When you need one

Start with a Sidecar. Add the Control Plane when there is more than one to manage.

---

​

Next