Added kyverno joint assessment

[06kellyjac]

Resolves #1703

Exporting the gdoc to markdown & images.
Some adjustments to add code backticks to match the self-assessment doc, there are likely some areas that could have more backticks and some where they should be removed

Changes to the architecture diagram name welcome.
The other image in images seems the same.

I've also added a heading to the metadata table.

I've not checked cspell rules, there didn't seem to be a config or CI for it in the repo so I've left it alone for now.

cc @sublimino

[mnm678]

Is there anything blocking this pr?

[IceCodeBear]

Hi @mnm678, no blockers, all follow-up items from the assessment have been addressed. We're scheduled to present at an upcoming TAG Security and Compliance meeting

[Santoshkumarpuppala]

Thanks to the reviewers and the Kyverno team for this. It's a strong joint assessment, and the parts I want to credit first are the ones that were optional to include. The document volunteers that the default installation ships no NetworkPolicy; that a default install has no client authentication for the API server, with a pointer telling users to enable it; that ValidatingPolicy and ImageValidatingPolicy don't currently honour the RuntimeCELCostBudget, with the tracking issue linked; that the Global Context Cache is in-memory and may be a problem for cross-namespace usage, again with its issue linked; and that conflicting mutations can churn until circuit breakers trip and then require human intervention. Documents that name their own open problems with issue numbers attached are rare, and the two Ada Logics audits plus a linked changes-tracking issue make the claims here straightforwardly checkable.

I read it with one narrow lens: for each boundary the document claims, does it name the single server-side point that enforces it, and what would a negative test look like — a request that should be refused, and is. Kyverno is an unusual subject for that lens, because it is itself the enforcement point for everyone else's boundaries. So the question turns into: what constrains Kyverno, and who is trusted to reconfigure it? The document answers that well in one place and leaves it implicit in three others.

The place it answers well, and which I'd hold up as the pattern for the rest: the main ConfigMap is described as "editable by Kubernetes RBAC users with admin/edit access to the Kyverno namespace. By default, access is limited to cluster administrators." That names the object, the mechanism, and the default, in one sentence. Three more boundaries would benefit from the same treatment.

1. Policy Exceptions. This is where I'd start. PolicyException is described as a set of "narrowly scoped, auditable bypasses of specific policies, rules, and targets," and the document notes that creation and deletion appear in Kubernetes audit logs. But an exception is by construction a mechanism for switching off a security control, so the question a reader most needs answered is who may create one and where it is honoured — and the document doesn't name the controls that decide that. Kyverno has specific, named ones: exceptions are off unless enablePolicyException is set, and --exceptionNamespace restricts which namespace they are read from, with exceptions honoured cluster-wide when it isn't set. That is exactly the shape of statement the ConfigMap paragraph already makes. The negative test writes itself: a PolicyException created in a namespace outside the configured exception namespace does not exempt the resource, and the policy still refuses it. Adding those two setting names, their defaults, and that negative test would close the highest-consequence gap in the document.

2. Policy authorship is permission delegation. The Background Controller section credits the right default — it "does not run with wildcard roles by default, need explicit RBAC for resources managed" — and that's worth having. What isn't stated is the consequence: a generate or mutate-existing rule executes with the controller's ServiceAccount permissions, not the policy author's. So whoever can create a cluster-scoped policy can cause writes wherever the controller's RBAC reaches, regardless of their own access to those namespaces. I read that as intended design; it's how generate rules have to work. But it means "who can author a cluster-scoped policy" is a privilege boundary roughly equivalent to the controller's own role, and I think the document should say that in a sentence rather than leaving readers to derive it. It also makes the "customizing permissions" link load-bearing rather than informational, which is worth signalling.

3. Enforcement versus reporting. The Goals section says that if the admission controller is unavailable, "CLI tools and background scanning provide alternative enforcement mechanisms to maintain security posture." Background scanning produces PolicyReports after the fact; it doesn't refuse anything. The document is careful about this distinction elsewhere — it correctly credits fail-closed as the webhook failure mode default under Dynamic Webhook Management — so I take this as loose wording in the Goals paragraph. But it's the sentence most likely to be quoted out of context by someone deciding whether a controller is optional, and "detective rather than preventive coverage" would be more accurate at no cost.

Two smaller ones. The Global Context Cache note says the cache is accessible only to Kyverno controllers; the follow-up question is whether a policy evaluated for one namespace can read an entry populated from a source credentialled for another. That's a cross-namespace read boundary, and it's worth an explicit yes or no even if the answer is "yes, it's cluster-scoped by design." And the Threat Modeling section defers entirely to the Kubernetes SIG Security admission controller threat model, which is the right base but doesn't cover the Kyverno-specific items the document already discusses in prose. Most of the raw material for a short table is already scattered through Functions and Features; collecting five or six Kyverno-specific rows — exception scope, policy-authorship delegation, cache staleness, circuit-breaker exhaustion, certificate renewal under leader-election churn — with threat, mitigation, residual risk and who enforces it, would make the residual risks legible in one place rather than distributed across the document.

Housekeeping: the Completed field in the header table still reads "tbd", and the newly added images/kyverno-architecture-2.png doesn't appear to be referenced from the document body.

None of this is a vulnerability claim — it's all "the document asserts a boundary and I'd like the text to name what enforces it, or the dependency it rests on." Happy to be pushed back on any of it, especially the exception-scoping details, where your implementation knowledge is more current than my read of the docs.

[evankanderson]

@JustinCappos -- I think you and @sublimino did this joint assessment. I'm going to have you approve this.

[JustinCappos]

I think there is a minor issue. What is here is usually the updated self-assessment document and the joint assessment is a short document written by @sublimino with the assessment team's suggestions. So, we'd need to rename the current joint doc and add the joint assessment in the new one.

…

On Thu, Aug 20, 2026 at 12:40 PM Evan Anderson ***@***.***> wrote: *evankanderson* left a comment (cncf/toc#2208) <#2208 (comment)> @JustinCappos <https://github.com/JustinCappos> -- I think you and @sublimino <https://github.com/sublimino> did this joint assessment. I'm going to have you approve this. — Reply to this email directly, view it on GitHub <#2208?email_source=notifications&email_token=AAGROD6SMFW6RCM7NWYFQC35K4SWZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZVHA4DSMZSG442M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5358893279>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD54NOCI5GC5QJFLSDL5K4SWZAVCNFSNUABEKJSXA33TNF2G64TZHM2DONJXGQZDSNJ3JFZXG5LFHM2DONBVGQZTMNZXHGQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAGROD3YADRFCR26EDIADNT5K4SWZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZVHA4DSMZSG442M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AAGROD74TF2JO3XZ2H5KMAT5K4SWZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZVHA4DSMZSG442M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[IceCodeBear]

Thanks @JustinCappos, this is very helpful; we agree with the process correction. Our understanding is that the current long document should be handled as the updated self-assessment, with a separate short joint-assessment document for the assessment team's recommendations. Since this PR is sponsor-led, we’ll defer to your preferred flow: if you want to update directly, that works; if helpful for fast-tracking, Kyverno maintainers can prepare a patch/co-author the rename/split and hand it over for your review

[sherine-k]

Hi folks,
I'm off this week, but I can help resume and finish this joint assessment on Monday if that's ok.

[06kellyjac]

Thanks for the offers @IceCodeBear & @sherine-k
@sublimino and I will try get an adjusted joint-assessment up & migrate the changes into self-assessment by the end of the week.