Guardrails on shared data planes
Enterprise Tier
A data plane is shared capacity: it can serve many projects at once, on one hostname or several, and each of those projects can carry its own guardrails. Guardrail enforcement on that shared capacity is scoped to each project, the data plane's project labels determine which guardrails it enforces, and specific signals belong in alerting.
Persona: Platform operator or security stakeholder running data planes that serve more than one project.
Outcomes
- Each project's guardrails apply only to that project's traffic.
- Project label health is enforcement health: until a data plane has pulled a project's configuration, that project's guardrails are not enforced there.
- Requests without project identity are blocked on a guardrail-carrying data plane, and the data plane counts them in metrics that warrant an alert.
Each project's guardrails apply only to that project's traffic
Guardrails are project-scoped, as described in About guardrails: a guardrail authored under one project belongs to that project alone. Several projects can share one data plane and one hostname, so the hostname does not decide the project. Agent Router resolves each request to its project from its API key and stamps that project on the request before guardrails are evaluated, so the gateway evaluates only the guardrails owned by the request's project. A project that has configured no guardrails is unaffected by the policies of the other projects sharing the data plane.
Selection is per request. All served projects' guardrails coexist on the same data plane; on each request, the gateway selects the policy set that belongs to the project identity stamped on that request.
The configuration the data plane receives is scoped the same way since 0.4.0. Guardrail providers delivered to a shared data plane carry the project that owns them, so the data plane no longer receives one undifferentiated provider list, and editing a provider regenerates configuration only for the data planes serving its own project. Provider credentials are not in that configuration at all: they reach the gateway as a mounted Kubernetes Secret, so another project's provider settings and credentials appear in no ConfigMap or configuration dump on shared capacity.
Project label health decides what is enforced
The set of projects whose guardrails a data plane enforces is derived from its project labels: labelling a data plane with a project enrolls that project's guardrails there, and removing the label withdraws them on the data plane's next configuration update. On a data plane before 0.7.0, the same set is derived from the project gateways attached to it.
That makes label health part of enforcement health. A project's guardrails are enforced on a data plane only once that data plane has pulled the project's configuration; until then, none of them are. Traffic that cannot be attributed to a served project is blocked (see the identity section below).
When a project's guardrails are not being enforced on a data plane:
- In the Admin Console, open Directory → Data Planes, select the data plane, and read the project's label. Each label shows three steps: label applied, config pulled (with the revision the data plane holds and the one it picks up next), and verified. A label stuck before config pulled means the data plane has not taken the project's configuration, so its guardrails are not enforced there. See Manage a data plane's addresses and projects.
- Check that the data plane is calling home, then remove and reapply the label to restore enforcement for that project. Reapplying a label clears its verified time until the next successful request for the project on that data plane.
Alert on requests missing project identity
Agent Router stamps identity onto every request as it crosses the gateway, the same identity surfaced on telemetry as the x-tars-customer and x-router-project-id header-mapped attributes in the OpenTelemetry reference. Applications do not set these; the data plane does, and guardrail selection depends on them.
On a data plane with any guardrails configured, a request that reaches guardrail evaluation without this identity is blocked, with no guardrail evaluated: an unattributable request cannot be matched to its project's policy. On a data plane with no guardrails configured at all, such requests are allowed, since there is nothing to enforce.
In both cases the data plane emits metrics counting requests that arrive without identity. These counters are the canary for a misconfigured or degraded request path, and they deserve a standing alert:
- Wire an alert on the missing-identity counters in the metrics stream each data plane exposes (see OpenTelemetry traces and metrics for the delivery paths). Under normal operation the rate is zero.
- Treat a sustained non-zero rate as an incident. On a guardrail-carrying data plane it means live traffic is being blocked; on a guardrail-free data plane it means requests are flowing without project attribution. Either way the request path needs repair, starting with the data plane's project labels and its configuration pulls.
Where to go next
About guardrails
The policy model: guardrails, rules, providers, patterns, and how a rule is evaluated.
Manage a data plane's addresses and projects
Review the projects a data plane is labelled with and how far each label has progressed.
Guardrails best practices and FAQ
Roll out, tune, and operate guardrails in production without self-inflicted outages.
OpenTelemetry traces and metrics
The metric families and identity attributes the data plane exposes for alerting.