Avoiding Common Kubernetes Security Misconfigurations with RBAC Best Practices

Kubernetes misconfigured RBAC is the most exploited security condition. Example on how to avoid these misconfigurations and keep your Kubernetes cluster secure

Ankush Madaan
February 28, 2023
Blog

About

Kubernetes misconfigured RBAC is the most exploited security condition. Example on how to avoid these misconfigurations and keep your Kubernetes cluster secure

Industries

AWS, Kubernetes, RBAC, Security

Share Via

Introduction

Kubernetes is a popular container orchestration tool that allows you to deploy and manage containerized applications at scale. However, like any other technology, Kubernetes has its own security concerns that need to be addressed to ensure that your cluster is secure. One of the most critical security concerns in Kubernetes is misconfigured RBAC (Role-Based Access Control). RBAC is used to define and manage user access and permissions within the cluster. It defines roles, role bindings, and service accounts to control who can perform certain actions within the cluster. To avoid common Kubernetes security misconfigurations, it is essential to follow RBAC best practices. This includes:

Limiting access to Kubernetes API: Only grant access to Kubernetes API resources that users and applications need to perform their functions. Use RBAC rules to restrict access to sensitive API objects, such as secrets and config maps.
Implementing least privilege access: Grant users and applications the minimum level of access they need to perform their tasks. Avoid granting overly broad permissions that can be abused by attackers.
Using namespaces for access control: Use namespaces to group related objects and control access to them. Apply RBAC rules to namespace scopes to restrict access to sensitive resources.
Enforcing multi-factor authentication: Implement multi-factor authentication (MFA) for all users and service accounts accessing the Kubernetes API. This adds an extra layer of security to prevent unauthorised access.
Monitoring RBAC activity: Use audit logs to track RBAC activity and detect suspicious behavior. Regularly review RBAC policies to ensure they are up-to-date and effective.

Let’s look at the most common Misconfigured permissions. This arise when the roles and role bindings are not configured correctly, allowing users or services to have more privileges than they should.

Here’s an example of a commonly made misconfiguration:

Let’s say a developer creates a new service account called myapp-sa for an application that they are deploying in the Kubernetes cluster. They set the service account’s permissions to include access to sensitive resources, such as secrets or other Kubernetes objects. However, they forget to create a role binding that associates the service account with a role that grants only the necessary permissions. As a result, the service account is granted more permissions than it should have.

Here’s an example YAML file that shows this misconfiguration:

	yamlCopy code
	# serviceaccount.yaml

	apiVersion: v1
	kind: ServiceAccount
	metadata:
	name: myapp-sa
	---
	# role.yaml

	kind: Role
	apiVersion: rbac.authorization.k8s.io/v1
	metadata:
	name: myapp-role
	rules:
	- apiGroups: [""] # "" indicates the core API group
	resources: ["pods", "secrets"] # give access to pods and secrets
	verbs: ["get", "watch", "list", "create", "update", "delete"] # give full access
	---
	# misconfigured-role-binding.yaml

	kind: RoleBinding
	apiVersion: rbac.authorization.k8s.io/v1
	metadata:
	name: myapp-role-binding
	roleRef:
	apiGroup: rbac.authorization.k8s.io
	kind: Role
	name: myapp-role # reference the role created earlier
	subjects:
	- kind: ServiceAccount
	name: myapp-sa # reference the service account created earlier

view raw Kubernetes misconfigured RBAC hosted with ❤ by GitHub

In this example, the myapp-sa service account is created with full access to pods and secrets. However, the myapp-role-binding role binding is misconfigured because it references the myapp-role role, which grants full access to the resources. As a result, the myapp-sa service account is granted more permissions than it should have, potentially exposing sensitive data to unauthorized access. To avoid this misconfiguration, the myapp-role should be updated to grant only the necessary permissions, and the myapp-role-binding should be updated to reference the updated role. For example, if the application only requires read-only access to pods and secrets, the myapp-role can be updated to only grant get and list permissions.

Here’s an example YAML file with correct configuration:

	yamlCopy code
	# role.yaml

	kind: Role
	apiVersion: rbac.authorization.k8s.io/v1
	metadata:
	name: myapp-role
	rules:
	- apiGroups: [""]
	resources: ["pods", "secrets"]
	verbs: ["get", "list"]

view raw Kubernetes correct RBAC hosted with ❤ by GitHub

With this update, the myapp-sa service account is granted only the necessary read-only permissions.

Tu further validate the permission you can run :

kubectl auth can-i <verb> <resource> –as=system:serviceaccount:<namespace>:<serviceaccountname> [-n <namespace>]

By following Kubernetes best practices and regularly reviewing RBAC configurations, you can minimize the risk of misconfigurations and ensure that your cluster is secure. Additionally, using tools such as Kube-bench and kubeaudit can help identify misconfigurations and vulnerabilities in Kubernetes clusters.