Workload templates inside ResourceGraphDefinitions are invisible to every static scanner #3055

🤖 Generated by the Agentic Engineer

Evidence

Trivy reports zero misconfigurations on both ResourceGraphDefinition files, measured on the
current tree with the exact CI invocation (trivy fs --scanners misconfig --ignorefile .trivyignore.yaml --skip-dirs tests ., v0.73.0):

k8s/bases/infrastructure/resource-graph-definitions/tenant/resource-graph-definition.yaml   misconfigs=0  fails=0
k8s/bases/infrastructure/resource-graph-definitions/webapp/resource-graph-definition.yaml   misconfigs=0  fails=0

That is not a clean bill of health — it is the scanner declining to look. Trivy parses the RGD as a
single custom resource and does not descend into the workload templates nested in its resources:
spec, so the Deployments, Services, HTTPRoutes and RBAC those templates generate are never
evaluated. The neighbouring plain cluster-role.yaml files in the same directories do produce
findings (1 and 2 respectively), which is what makes the zero attributable to the nesting rather
than to the directory being skipped.

The same reasoning applies to checkov, and to the Kubescape gate, which scans stored specs.

Why it matters

Tenants and their web applications are the workloads most likely to be added or changed without
platform-level review, and they are precisely the ones no static misconfiguration scanner currently
sees. A tenant template shipping privileged: true, no resource limits, or a workload placed in
kube-system would pass every static gate on this repository.

This was found while scoping KSV-0037 in #3054. That scoping does not cause the gap and does not
widen it — the RGD templates were already unreachable to the check, with and without the exception —
but it is why the exception's comment cannot claim tenant coverage, and the gap deserves its own
tracking rather than a footnote.

Expected behaviour

The workload templates inside an RGD are statically checked for the same misconfiguration classes as
a committed manifest, so a non-compliant tenant template fails a pull request.

Smallest useful first step

Confirm the reach precisely before choosing a mechanism: add a deliberately non-compliant container
spec to a scratch copy of the tenant RGD and confirm no scanner reports it. Then evaluate the
options — rendering the RGD's templates into concrete manifests in a scan-only step, a schema-aware
policy that reads spec.resources[].template, or a Kyverno policy enforcing the same controls at
admission on the generated objects (which would cover them at runtime rather than statically).

Acceptance criteria

• A non-compliant workload template inside tenant or webapp fails a check on the pull request
  that introduces it.
• The mechanism is documented next to the RGDs so the next template author knows what gates them.
• No blanket disable or path exclusion is introduced to achieve it.