Threat Model
The Kubernetes Security Special Interest Group (SIG) has defined an Admission Control Threat Model for Kubernetes. The Kubewarden team continuously evaluates Kubewarden against this threat model, and works to provide secure defaults. It's recommended that Kubewarden administrators read and understand the threat model, and use it to devise their own circumstance specific threat model as needed.
Details about each threat is provided in the document published by SIG Security.
Kubernetes threats​
Threat 1 - Attacker floods webhook with traffic preventing its operation​
Scenario​
An attacker who has access to the Webhook endpoint, at the network level, could send large quantities of traffic, causing an effective denial of service to the admission controller.
Mitigation​
Webhook fails closed. if the webhook doesn't respond in time, for any reason, the API server should reject the request. This is Kubewarden's default behavior.
Failing closed means that if, for any reason, Kubewarden stops responding or crashes, the API server rejects the request by default. This is even if the request would normally be accepted by Kubewarden.
Threat 2 - Attacker passes workloads which require complex processing causing timeouts​
Scenario​
An attacker, who can access the admission controller at a network level, passes requests to the admission controller requiring complex processing and causing timeouts as the admission controller uses compute power to process the workloads.
Mitigation​
Webhook fails closed and authenticate callers. This is Kubewarden's default behavior.
Threat 3 - Attacker exploits mis-configuration of webhook to bypass​
Scenario​
An attacker, who has rights to create workloads in the cluster, is able to exploit a mis-configuration to bypass the intended security control.
Mitigation​
Regular reviews of webhook configuration can help catch issues.
Threat 4 - Attacker has rights to delete or modify the Kubernetes webhook object​
Scenario​
An attacker who has Kubernetes API access, has sufficient privileges to delete the webhook object in the cluster.
Mitigation​
RBAC rights should be strictly controlled.
To-do​
Most of RBAC isn't within the scope of the current discussion. However, the following will be provided in due course for helping Kubewarden users:
- Directions around minimum RBAC to be implemented.
- Provision & documentation of a policy that detects and could block RBAC changes.
Threat 5 - Attacker gets access to valid credentials for the webhook​
Scenario​
An attacker gains access to valid client credentials for the admission controller webhook.
Mitigation​
Webhook fails closed. This is Kubewarden's default behavior.
Threat 6 - Attacker gains access to a cluster admin credential​
Scenario​
An attacker gains access to a cluster-admin level credential in the Kubernetes cluster.
Mitigation​
N/A