What needs to happen
Rules carry a tenant reference, and a validating webhook exists to check that whoever creates a rule is entitled to the tenant resources it names. The check is written, tested, and registered with the manager.
It never runs. Two things stop it.
The authorizer behind it is the allow-everything placeholder, marked as such in the code. And no webhook configuration or serving certificate is deployed anywhere in the repository, so the API server has nothing to call in the first place.
Separately, the condition that decides whether a rule gets programmed into the data plane is granted by the controller as soon as gateway nodes exist for that namespace. It is not derived from any authorization result. The name of that condition suggests admission has vetted the rule. Admission has not seen it.
Why this matters
The gap is documented in comments, so nobody was misled while writing it. The risk is the next reader, who finds an authorization path that looks complete, and a condition whose name says a check passed.
Until both halves land, the only thing standing between a tenant and another tenant's traffic being steered at their addresses is ordinary access control on the rule objects themselves.
Desired outcome
- A real authorizer that resolves the tenant reference against the companion operator, replacing the placeholder.
- The webhook configuration and certificate wiring deployed, so the check runs before a rule is persisted.
- The programming condition reflects the admission outcome, or gets a name that says what it actually means.
- Until then, say plainly in the deployment docs that tenant ownership is not enforced.
Found while reviewing #351.
What needs to happen
Rules carry a tenant reference, and a validating webhook exists to check that whoever creates a rule is entitled to the tenant resources it names. The check is written, tested, and registered with the manager.
It never runs. Two things stop it.
The authorizer behind it is the allow-everything placeholder, marked as such in the code. And no webhook configuration or serving certificate is deployed anywhere in the repository, so the API server has nothing to call in the first place.
Separately, the condition that decides whether a rule gets programmed into the data plane is granted by the controller as soon as gateway nodes exist for that namespace. It is not derived from any authorization result. The name of that condition suggests admission has vetted the rule. Admission has not seen it.
Why this matters
The gap is documented in comments, so nobody was misled while writing it. The risk is the next reader, who finds an authorization path that looks complete, and a condition whose name says a check passed.
Until both halves land, the only thing standing between a tenant and another tenant's traffic being steered at their addresses is ordinary access control on the rule objects themselves.
Desired outcome
Found while reviewing #351.