How Can Kubernetes RBAC Permissions Be Exploited?

TL;DR

Kubernetes access depends on authentication, authorization, and admission control, so compromised credentials become dangerous when RBAC grants excessive permissions. Service account tokens are automatically mounted into containers, and a pod can specify another service account in its namespace, making service account selection and permission scope important areas for security review.

Transcript

Good morning, everybody. Wow. Okay, if you weren't awake, you are now. All right. Welcome to the eight AM session. Hope you're ready. Um, the session is compromising Gurbanetys-- Kubernetes cluster by exploiting RBAC permissions, and our speaker today is Evyatar Girzi. Um, I would ask everyone to please mute your phone so that it's not disrupting d... Read More

Key Insights

• Kubernetes is an open source system for automating the deployment, scaling, and management of containerized applications. It can distribute containers across multiple machines, add or remove containers as demand changes, and manage environments containing thousands or even hundreds of thousands of containers.
• A Kubernetes cluster is a group of physical or virtual machines divided into master and worker nodes. The master provides command and control, while worker nodes run application workloads through pods containing one or more containers.
• The API server is the central Kubernetes component through which cluster traffic passes. It exposes an API used through kubectl or customized clients and performs validation, authentication, and authorization before requests can affect cluster resources.
• The etcd database contains Kubernetes secrets and configuration, making it the cluster's most sensitive component in the presentation. Its contents are stored in plain text under the default configuration, although encryption can be enabled, and normally only the API server communicates with it.
• Kubernetes API access has three stages: authentication validates credentials, authorization checks requested permissions, and admission control inspects object data. A request must successfully pass these controls before the requested operation can proceed.
• Service accounts are Kubernetes-managed identities bound to specific namespaces. They authenticate with JWT service account tokens, while normal users are managed through an independent external service and may authenticate with certificates, token files, passwords, OpenID, webhooks, or authenticating proxies.
• A default service account is automatically assigned whenever a pod is created without an explicitly specified service account. Its token, namespace information, and certificate are mounted inside the container, allowing the workload to authenticate to the Kubernetes API.
• RBAC permissions are connected to subjects through role bindings or cluster role bindings. Roles contain rules defining verbs and resources, such as permission to list secrets, while cluster-scoped bindings affect all namespaces and namespace-scoped bindings affect only a specific namespace.

Questions & Answers

Q: How does Kubernetes control access to its API?

Kubernetes API access passes through three stages. Authentication first validates the requester's credentials and confirms that the identity exists in the cluster. Authorization then checks whether that identity has permission to perform the requested operation. Finally, admission controllers inspect the content associated with the object or request before the operation is allowed to proceed.

Q: What is Kubernetes RBAC and how does it work?

Role-based access control, or RBAC, restricts system access to authorized users and service accounts. A role or cluster role contains rules describing allowed verbs and resources, such as listing secrets. A role binding or cluster role binding connects those permissions to a subject, which can be a user, service account, or group.

Q: Why are Kubernetes service account tokens a security concern?

Service account tokens are credentials that allow workloads to authenticate to the Kubernetes API. Kubernetes mounts a JWT token, namespace information, and a certificate inside a container. If an attacker gains access to that container, the mounted token provides an authenticated identity whose impact depends on the RBAC permissions assigned to its service account.

Q: How is a service account assigned to a Kubernetes pod?

When a pod is created without an explicitly selected service account, Kubernetes automatically assigns the default service account from the same namespace. A pod can also specify a different service account in that namespace if its name is known. The selected account's credentials are then mounted into the container for Kubernetes API authentication.

Q: What information is stored in Kubernetes etcd?

The etcd database stores Kubernetes secrets, configuration, and other information representing the cluster. The presentation identifies it as the most sensitive Kubernetes component. Under the default configuration, its data is stored in plain text, although encryption can be configured. Normally, only the API server is permitted to communicate directly with etcd.

Q: What are the main components of a Kubernetes cluster?

A Kubernetes cluster contains master and worker nodes. The master includes the API server, controller manager, scheduler, and etcd database. Worker nodes include the kubelet, which deploys container images and creates pods, and kube-proxy, which handles filtering and networking. Pods are logical units containing one or more application containers.

Q: What is the difference between a role binding and a cluster role binding?

A role binding connects permissions to a subject within a specific namespace, while a cluster role binding applies across all namespaces. The associated role rules define which operations are allowed on particular resources. For example, a rule with the verb list and the resource secrets permits the bound subject to list secrets within its applicable scope.

Q: How can excessive RBAC permissions contribute to Kubernetes compromise?

Excessive RBAC permissions increase what an authenticated identity can do through the Kubernetes API. An attacker who obtains a mounted service account token can authenticate as that account and exercise its assigned permissions. The risk becomes broader when bindings apply across the cluster or when a pod can select a more privileged service account within its namespace.

Summary & Key Takeaways

• Kubernetes manages containerized applications across clusters composed of master and worker nodes. The API server processes traffic and performs validation, authentication, and authorization. Other components maintain application state, schedule workloads, create pods, manage networking, and store cluster secrets and configuration in the etcd database, which uses plain text by default.

• Access to the Kubernetes API passes through authentication, authorization, and admission control. Authentication validates credentials and cluster identity. Authorization determines whether the requester may perform an operation. Admission controllers inspect object data after authorization, with Always Pull Images given as an example that ensures newly created pods use the most updated image.

• Kubernetes RBAC connects users or service accounts to roles through role bindings or cluster role bindings. Service accounts are namespace-bound and use JWT tokens mounted inside containers. Every pod receives the namespace's default service account unless another account is specified, creating risk when selectable accounts possess permissions that an attacker can exploit.