viccuad commented 2 years ago

Acceptance criteria

Following the k8s admission controller threat model document listed in kubernetes/sig-security/issues/7, check all threats and mitigations to see if we need to re-implement or add anything. Check if we want to provide a production setting with specific policies deployed by default (pod-privileged not allowed on same node as controller, etc).

In addition, list any stack differences if any on the Kubewarden stack, and provide a threat model analysis for those.

Create followup cards with the work to be done if necessary.

viccuad commented 2 years ago

The Kubernetes Sig-security has finished their threat model study: https://kubernetes.io/blog/2022/01/19/secure-your-admission-controllers-and-webhooks/ kubernetes/sig-security/tree/main/sig-security-docs/papers/admission-control

jvanz commented 2 years ago

Okay. There are 18 threats mapped in the document shared in https://github.com/kubewarden/kubewarden-controller/issues/129#issuecomment-1019851853. I'll discuss each one sharing a brief description of it, possible mitigation and what I think we should do about it (if necessary). If you need more details about each threat, go to the original document. The threats are:

Threat 1 - Attacker floods webhook with traffic preventing its

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. In other words, if the webhook does not respond in time, for any reasion, API server should reject the request. We are safe on this. Kubewarden default behavior already does that.

Threat 2 - Attacker passes workloads which require complex processing causing timeouts

An attacker, who can access the admission controller at a network level, passes requests to the admission controller which require complex processing, causing timeouts as the admission controller uses compute power to process the workloads

Mitigation Webhook fail closed and authenticate callers. We are safe, Kubewarden already does that.

Threat 3 - Attacker exploits misconfiguration of webhook to bypass

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 catch issues.

To do We need to provide some mechanism to notify operators when a webhook is changed. Maybe the controller can watch its webhooks, fix when the configuration is changed and notify the operator.

Threat 4 - Attacker has rights to delete or modify the k8s webhook object

An attacker who has Kubernetes API access, has sufficient privileges to delete the webhook object in the cluster.
Mitigation RBAC rights are strictly controlled.

To do I think most of the RBAC is not responsibility. But we can help our users if we:

Warning them in our docs and suggest some minimum RBAC to be used.
Provide a policy which detect RBAC changes and maybe block them.

Threat 5 - Attacker gets access to valid credentials for the webhook

An attacker gains access to valid client credentials for the admission controller webhook

Mitigation Webhook fails closed

Kubewarden is failed closed. Thus, we should be fine.

Threat 6 - Attacker gains access to a cluster admin credential

An attacker gains access to a cluster-admin level credential in the kubernetes cluster.
Mitigation
N/A

I cannot see what Kubewarden can do here.

Threat 7 - Attacker sniffs traffic on the container network

An attacker who has access to the container network is able to sniff traffic between the API server and the admission controller webhook.

Mitigation
Webhook uses TLS encryption for all traffic

Kubewarden are safe. Because the webhook connections are encrypted.

Threat 8 - Attacker carries out a MITM attack on the webhook

An attacker on the container network, who has access to the NET_RAW capability can attempt to use MITM tooling to intercept traffic between the API server and admission controller webhook.

Mitigation Webhook mTLS authentication is used.

To do Kubewarden should implement mutual TLS authentication We can add in the recommended policies from the kubewarden-defaults Helm chart a policy to drop the NET_RAW capability.

Threat 9 - Attacker steals traffic from the webhook via spoofing

An attacker is able to redirect traffic from the API server which is intended for the admission controller webhook by spoofing.

Mitigation
Webhook mTLS authentication is used.

To do Kubewarden should implement mutual TLS authentication

Threat 10 - Abusing a mutation rule to create a privileged container

An attacker is able to cause a mutating admission controller to modify a workload, such that it allows for privileged container creation

Mitigation
All rules are reviewed and tested.

To do We may came up with some tests to cover this rules reviews We should carefully review a PR changing the rules in the policies deployment

Threat 11 - Attacker deploys workloads to namespaces that are exempt from admission control

An attacker is able to deploy workloads to Kubernetes namespaces that are exempt from the admission controller configuration.

Mitigation
RBAC rights are strictly controlled

To do I think most of the RBAC is not responsability. But we can help our users if we:

Warning them in our docs and suggest some minimum RBAC to be used.
Provide a policy which detect RBAC changes and maybe block them. Is this possible?

Threat ID 12 - Block rule can be bypassed due to missing match (e.g. missing initcontainers)

An attacker created a workload manifest which uses a feature of the Kubernetes API which is not covered by the admission controller

Mitigation
All rules are reviewed and tested.

To do We may came up with some tests to cover this rules reviews We should carefully review a PR changing the rules in the policies deployment

Threat ID 13 - Attacker exploits bad string matching on a blocklist to bypass rules

An attacker, who has rights to create workloads, bypasses a rule by exploiting bad string matching.

Mitigation
All rules are reviewed and tested.

To do We may came up with some tests to cover this rules reviews We should carefully review a PR changing the rules in the policies deployment

Threat ID 14 - Attacker uses new/old features of the Kubernetes API which have no rules

An attacker, with rights to create workloads, uses new features of the Kubernetes API (for example a changed API version) to bypass a rule.

Mitigation
All rules are reviewed and tested.

To do We may came up with some tests to cover this rules reviews and API versions. We can create a configuration to reject by default requests where the API version not cover by the policy. We should warning policies developers to cover all the supported API version in theirs tests and reject all of others.

Threat ID 15 - Attacker deploys privileged container to node running Webhook controller

An attacker, who has rights to deploy privileged containers to the cluster, creates a privileged container on the cluster node where the admission controller webhook operates.

Mitigation
Admission controller uses restrictive policies to prevent privileged workloads

To do We have a policy to prevent privileged workloads in the recommended policies in the kubewarden-default helm chart. But we can improve by:

We may need to define all the API versions cover by the recommended policies
We can create a configuration to reject by default requests where the API version not cover by the policy.
We should warning policies developers to cover all the supported API version in theirs tests and reject all of others.

Threat ID 16 - Attacker mounts a privileged node hostpath allowing modification of Webhook controller configuration

An attacker, who has rights to deploy hostPath volumes with workloads, creates a volume which allows for access to the admission controller pod’s files.

Mitigation
Admission controller uses restrictive policies to prevent privileged workloads

To do We can add a recommended policy in the kubewarden-default Helm chart to prevent this.

Threat ID 17 - Attacker has privileged SSH access to cluster node running admission webhook

An attacker is able to log into cluster nodes as a privileged user via SSH.
Mitigation
N/A

I don't think Kubewarden can help on this

Threat ID 18 - Attacker uses policies to send confidential data from admission requests to external systems

An attacker is able to configure a policy that listens to admission requests and sends sensitive data to an external system.

Mitigation
Strictly control external access for webhook

To do We may define some network configuration to block external access from the Kubewarden pods.

jvanz commented 2 years ago

Moving this to pending review to discuss with the team. ;)

viccuad commented 2 years ago

This looks great! Starting to review made me think, should we open an RFC with this content, for review, and posterity?

jvanz commented 2 years ago

This looks great! Starting to review made me think, should we open an RFC with this content, for review, and posterity?

Hm, yeah. I think it makes sense. :)

jvanz commented 2 years ago

https://github.com/kubewarden/rfc/pull/2

kubewarden / kubewarden-controller

Re-check security posture against the k8s admission control threat model #129

Acceptance criteria

Threat 1 - Attacker floods webhook with traffic preventing its

Threat 2 - Attacker passes workloads which require complex processing causing timeouts

Threat 3 - Attacker exploits misconfiguration of webhook to bypass

Threat 4 - Attacker has rights to delete or modify the k8s webhook object

Threat 5 - Attacker gets access to valid credentials for the webhook

Threat 6 - Attacker gains access to a cluster admin credential

Threat 7 - Attacker sniffs traffic on the container network

Threat 8 - Attacker carries out a MITM attack on the webhook

Threat 9 - Attacker steals traffic from the webhook via spoofing

Threat 10 - Abusing a mutation rule to create a privileged container

Threat 11 - Attacker deploys workloads to namespaces that are exempt from admission control

Threat ID 12 - Block rule can be bypassed due to missing match (e.g. missing initcontainers)

Threat ID 13 - Attacker exploits bad string matching on a blocklist to bypass rules

Threat ID 14 - Attacker uses new/old features of the Kubernetes API which have no rules

Threat ID 15 - Attacker deploys privileged container to node running Webhook controller

Threat ID 16 - Attacker mounts a privileged node hostpath allowing modification of Webhook controller configuration

Threat ID 17 - Attacker has privileged SSH access to cluster node running admission webhook

Threat ID 18 - Attacker uses policies to send confidential data from admission requests to external systems