Impact

Kubewarden is a policy engine for Kubernetes. The Kubewarden stack is deployed
via Helm charts. The Kubewarden stack has Deployments called
kubewarden-controller, that by default get randomly scheduled on cluster nodes.
The Deployments run under the ServiceAccount kubewarden-controller, and that
ServiceAccount is bound to a ClusterRole called
kubewarden-controller-manager-cluster-role. This cluster role has read
permissions ("get list watch" verbs) over the Secret resources of the cluster.

Thus, once an attacker has previous access to the worker node where the
kubewarden-controller deployment runs, they can leverage the ServiceAccount to
get read access of all the secrets in the entire cluster (i.e., cluster's admin
token if present), resulting in a cluster-level privilege escalation.

Patches

This problem is mitigated by reducing the scope of the ClusterRole
kubewarden-controller-manager-cluster-role ClusterRole, removing "get list
watch" verbs for secrets in it. This restricts access to only those secrets in
the namespace "kubewarden", assigned by the already existing Role
kubewarden-controller-manager-namespaced-role.

In addition, the kubewarden-controller image has been patched so the Kubernetes
go-clients used in the watches of controller-runtime neither watch nor cache
unneeded resources. Hence Secrets outside the default Kubewarden namespace are
not watched nor cached, even if the controller is not making use of them.

Workarounds

Reduce permissions of ClusterRole kubewarden-controller-manager-cluster-role
and remove Secrets from it.

Given that the kubewarden-controller image needed changes for its Kubernetes
go-client cache, it is not enough with reducing the scope of the
kubewarden-controller-manager-cluster-role ClusterRole. One must also consume
the image kubewarden-controller:v1.6.0 or later.

References

#216
kubewarden/kubewarden-controller#429