[Proposal] Kubernetes Admission Controller Threat Model

[raesene]

---

name: Kubernetes Admission Controller Threat Model about: A document which would look at the likely threats which apply to Kubernetes admission controllers title: "[Proposal] Kubernetes Admission Controller Threat Model" labels: "proposal, triage-required" assignees: ''

---

Description: Kubernetes Admission Controller Threat Model. A document which would look at the likely threats which apply to Kubernetes admission controllers, e.g. webhook admission controllers such as OPA, Kyverno, jsPolicy, K-rail and Kubewarden. The document would be generic covering common deployment patterns and threats which could affect their operation.

A couple of initial areas that could be worth exploring:

• Communications security between the API server and admission controller
• Availability of admission controllers, Denial of Service risks and the consequences of those (e.g. fail open/fail closed)
• Policy bypass risks (e.g. ways an attacker might try to bypass a policy, depending on how the rules are specified, for example difference in case sensitivity between policy and destination, string matching things like URLs)
• Risks of policy exemptions necessary for Kubernetes, or supporting components to operate efectively.
• Risks of policy obsolesence causing bypass (e.g. where Kubernetes API versions change or specification of objects are modified in new versions)
• Attacks on admission controller workloads, from attackers on the container network, or attackers with some level of access to a cluster node which hosts the components used by the admission controller.

Impact: As admission controllers become more common parts of the Kubernetes security landscape, there could be benefits in exploring the general threats and vulnerabilities that could be applied to them. Having a documented threat model could allow implementers and users to understand common risks and good practices for addressing them.

Scope: "not yet determined" feels right here. My initial guess would be that we'll need a meeting to kick-off, a round of gathering possible threats, then a meeting or two to generate the model and output document.

Intent to lead:

• [X] I volunteer to be a project lead on this proposal if the community is interested in pursing this work. This statement of intent does not preclude others from co-leading or becoming lead in my stead.

Proposal to Project:

• [ ] Added to the planned meeting template for mm dd
• [ ] Raised in a Security TAG meeting to determine interest - mm dd
• [ ] Collaborators comment on issue for determine interest and nominate project lead
• [ ] Scope determined via meeting mm dd and/or shared document with call for participation in #tag-security slack channel thread and mailing list email
• [ ] Scope presented to Security TAG leadership and Sponsor is assigned

TO DO

• [ ] Security TAG Leadership Representative:
• [ ] Project leader(s): @raesene
• [ ] Issue is assigned to project leaders and Security TAG Leadership Representative
• [ ] Project Members:
• [ ] Fill in addition TODO items here so the project team and community can see progress!
• [ ] Scope
• [ ] Deliverable(s)
• [ ] Project Schedule
• [ ] Slack Channel (as needed)
• [ ] Meeting Time & Day:
• [ ] Meeting Notes (link)
• [ ] Meeting Details (zoom or hangouts link)
• [ ] Retrospective

[PushkarJ]

+1 happy to help out here

[savitharaghunathan]

I am interested in helping out. Are there any prerequisites in terms of knowledge and skills?

[JimBugwadia]

+1 - me too! I am interested in contributing and helping out.

[lumjjb]

I'm wondering if this is more in scope for k8s SIG-Security. Could be treated as an collaborative effort with a [related group](https://github.com/cncf/tag-security/tree/main/governance/related-groups

Since this is very specific to Kubernetes. @PushkarJ @IanColdwater, @tabbysable

[PushkarJ]

@lumjjb 100% agree. I know Rory, Savitha are also active contributors to k8s sig-security, so sounds like we already have the right people in the conversation :)

@raesene you probably know this already, but for context, we are doing a pilot exercise similar to what you are proposing but it is scoped only to cluster api. This is where we are tracking this effort: https://github.com/cncf/tag-security/issues/603 I am happy to put this as an agenda topic in our next k8s sig-security meeting, if that helps :)

[raesene]

@lumjjb @PushkarJ yeah I think the exact location is an interesting point. Admission control applies to Kubernetes, but the projects involved are not part of core. Happy to have the conversation about where we feel it best fits :)

[rficcaglia]

I had added a (very high level) section for threat modeling in the google doc posted here https://github.com/kubernetes/community/issues/5814

so that it is included in all sub-project reviews/assessments in the future - very happy to cross-pollinate and make sure we incorporate examples from this effort (and vice versa)

[raesene]

Hi all, so this got covered at k8s SIG-Security and looks like the consensus is that it'll fit best in SIG-Docs-Security over there, so I'll close this issue and if people are interested there should be some chat starting over there :)