Tenant boundary now denies the template's day-one scaffold, including the CloudNativePG path

[devantler]

🤖 Generated by the Agentic Engineer

Evidence

platform-tenant-template main is red. Its scheduled run validates the day-one scaffold against platform's live main, deliberately, so drift shows up here first.

Two independent breakages are stacked in one job. The first (the cosign signer set) is fixed in devantler-tech/platform-tenant-template#182; fixing it revealed this second one, which had been masked because the job stops at the first failing step.

restrict-tenant-network-policies now denies the scaffold's own network policy — the one the template ships so a new tenant is reachable on day one. Both rules fire (run 34128237728):

policy restrict-tenant-network-policies -> resource tenant-admission-test/CiliumNetworkPolicy/app failed:
  1 - cnp-ingress-sources-must-be-constrained
  2 - cnp-egress-destinations-must-be-constrained
pass: 2, fail: 2, warn: 0, error: 0, skip: 0

Cause

#3612 made a selector key naming a namespace refusable, on this reasoning (policy header):

a selector is scoped to the policy's own namespace only while it carries no namespace key, so naming one overrides that scoping

That is sound, and it means k8s:io.kubernetes.pod.namespace is now refused unconditionally — including when it names the tenant's own namespace. The scaffold pins that key on every intra-namespace rule, because 6dc9250 in the template had just made naming it explicitly the required spelling to satisfy the previous version of this same boundary. The two commits ask for opposite things.

The part that needs a decision

The intra-namespace rules are mechanically fixable — drop the namespace key and pin a tenant label instead, exactly as the deny message advises. Two others are not, and that is why this is an issue rather than a PR:

1. CloudNativePG. A tenant with a database must let the operator in cnpg-system reach instance status (8000) and PostgreSQL (5432). That is another namespace, so it is now categorically refused, and no entity spelling substitutes — only kube-apiserver and the post-Gateway ingress identity may be named.
2. DNS. The scaffold's egress rule names kube-system + k8s-app: kube-dns, refused for the same reason. This one is likely fine to simply delete, since the platform auto-generates an allow-dns policy and the scaffold keeps its own rule only to be self-contained — worth confirming.

So, the question: is a tenant intended to be able to express the CloudNativePG operator path at all? Either the boundary needs a sanctioned way to name it, or the scaffold must stop shipping a database path and the template's documentation should say the operator path is granted elsewhere. Platform owns that call — the template can only follow it.

Platform's own tenant does not settle it: k8s/bases/apps/ascoachingogvaner ships only a default-deny NetworkPolicy, with no CiliumNetworkPolicy carrying intra-namespace or operator rules, so there is no sanctioned example to copy.

Acceptance criteria

• A decision recorded on the CloudNativePG path: either a sanctioned spelling in the boundary, or an explicit statement that tenants do not express it, with where it is granted instead.
• The template scaffold updated to match, so main there is green and a freshly generated tenant is admissible on day one.
• A test on this side that pins the outcome, so the next tightening cannot silently make the shipped scaffold inadmissible again — this is the third time the template has had to chase this boundary.