🤖 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
Evidence
Trivy reports zero misconfigurations on both
ResourceGraphDefinitionfiles, measured on thecurrent tree with the exact CI invocation (
trivy fs --scanners misconfig --ignorefile .trivyignore.yaml --skip-dirs tests ., v0.73.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.yamlfiles in the same directories do producefindings (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 inkube-systemwould 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 atadmission on the generated objects (which would cover them at runtime rather than statically).
Acceptance criteria
tenantorwebappfails a check on the pull requestthat introduces it.