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.

---

​

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.

​

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