CVE-2023-32194 - How Kubernetes Role Assignment Can Leak Dangerous Namespace Permissions

Security in Kubernetes clusters can get pretty complex. While roles and permissions protect your workloads, sometimes there are vulnerabilities in how these permissions get handed out. One such issue is CVE-2023-32194, a vulnerability discovered in how Kubernetes grants permissions for *namespace* resources—regardless of their API group. In this post, we’ll break down what CVE-2023-32194 is, show you why it’s dangerous, provide exploit details, and link you to official references.

What’s the Problem?

In Kubernetes, access is managed with *roles* and *role bindings*. Roles specifically give permissions (like create, update, delete) to resources, e.g., Pods, Services, Namespaces.

With CVE-2023-32194, if someone is granted a role that allows them to create or * (all verbs), at the cluster-scoped (global) level for any resource of type namespaces—no matter *which* API group—Kubernetes actually gives them FULL access to the core namespaces resource.

That means the subject (a user, group, or service account) can access, create, update, or delete *any* namespace in your project. Oops.

Why Is This Bad?

Most Kubernetes deployments use namespaces to split up workloads, isolate apps, and separate teams. This bug means a user with only supposed access to a custom namespace API could wind up with *all-powerful* rights over every namespace in the cluster—including the system namespaces like kube-system or even be able to delete the cluster’s main namespaces.

Kubernetes RBAC Example

Suppose you want to give a user the power to create some custom API group’s namespaces resource. You make a ClusterRole like this:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: custom-ns-creator
rules:
- apiGroups: ["custom.io"]
  resources: ["namespaces"]
  verbs: ["create"]

This looks like it should only give access to the resource called namespaces in the custom.io API group. But because of this vulnerability, Kubernetes will grant this permission on the core namespaces too—effectively:

The Security Bug

If an attacker somehow receives or tricks an admin into assigning them this ClusterRole (or any role with verbs: ["*"] or even just create), they can run:

kubectl create namespace test-ns

Or even worse

kubectl delete namespace kube-system

And the Kubernetes API will let them, *even though the intent was to limit them to a custom resource.*

`yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1

Instead, What Should Happen?

Ideally, if you grant access to a resource in a specific API group, it should *not* give blanket permissions to the core resource with the same name. Only the intended resource should be accessible.

...then, yes, you’re likely affected!

## How To Fix / Mitigate

Conclusion

CVE-2023-32194 highlights a real risk in complex Kubernetes setups where roles and permission boundaries aren’t clear-cut. Double-check your role definitions, avoid wildcards, and always keep control of your namespaces! Stay patched, stay secure.

Timeline

Published on: 10/16/2024 13:15:12 UTC
Last modified on: 10/16/2024 16:38:14 UTC