RBAC Controls: The Key to Hardening a Kubernetes Cluster
One of the ways that admins can control who has access to the API and thereby harden their clusters is by using Kubernetes Role-Based Access Control (RBAC).
Join the DZone community and get the full member experience.Join For Free
If you’re using Kubernetes, you understand the importance of the API server. Referred to as 'the core of Kubernetes’ control plane' in the platform’s own documentation, the API server enables users, cluster elements, and external components to communicate with each other. Each of those communication instances constitutes a REST API call for which the API server is responsible. The API server subsequently treats everything in Kubernetes as an API object, the platform notes elsewhere on its website. As such, administrators can use the API to manipulate the state of pods, namespaces, and other API objects.
This functionality makes it imperative for administrators to keep the API locked down. To do that, they need to realize that the API generally comes exposed on every deployment for management purposes. This default configuration makes it possible for an unauthenticated actor to interact with publicly exposed Kubernetes clusters and manipulate what’s considered to be a valid request. They could then change some of the settings and configure the API to approve requests in a way that allows for malicious activity such as connecting to or downloading files from suspicious websites.
This raises a question: how can admins secure the API against external attackers?
Regulating Access with RBAC
One of the ways that admins can control who has access to the API and thereby harden their clusters is by using Kubernetes Role-Based Access Control (RBAC). According to Kubernetes, RBAC is a method of managing access to the Kubernetes environment based upon an individual’s role within the enterprise. It uses the
rbac.authorization.k8s.io, an API group that lets admins use the Kubernetes API to dynamically configure permission policies. They can activate it by starting up the API server with
Once activated, admins can use RBAC to declare the following kinds of Kubernetes objects:
Role: This Kubernetes object creates permissions within a specific Kubernetes namespace. Admins, therefore, need to assign a namespace to a Role in order to activate the Kubernetes object.
ClusterRole: As opposed to Roles, ClusterRoles are non-namespaced resources. They are means through which organizations can specify a set of permissions across all namespaces as well as on cluster-scoped resources.
RoleBinding: Once admins have created a Role, they can use a RoleBinding to grant the permissions within that Role to a user or a group of users. It may reference any Role within the namespace and apply it to a group of users, groups, or service accounts. It may also reference a ClusterRole and bind it to its own namespace.
ClusterRoleBinding: This Kubernetes object operates like a RoleBinding but enables admins to bind a ClusterRole to all namespaces in the cluster.
Some Important Misconfigurations to Keep in Mind
RBAC is a way through which admins can harden the security of the Kubernetes API server. But they’ll succeed in that effort only if they avoid some common RBAC misconfiguration errors. As an example, the Cloud Native Computing Foundation (CNCF) notes that administrators might unnecessarily grant the built-in
cluster-admin Role to its users. The permissions of this Role essentially opens up unlimited access to a cluster; malicious actors could subsequently use a takeover of a single account with this Role’s permissions to compromise broad swaths of an affected organization’s Kubernetes environment. In response, admins can work to limit the number of service accounts that receive the permissions specified under this Role and use more nuanced Roles/ClusterRoles to enforce the principle of least privilege throughout the workforce.
Simultaneously, admins want to keep the task of granting permissions to the API server as simple as possible. That means not duplicating the same permissions across multiple Roles or ClusterRoles for the same users. It also means refraining from creating Roles or ClusterRoles that don’t end up receiving a subject. Complexity makes RBAC more challenging than it needs to be by obscuring which subjects have access and the types of permissions to which they are entitled. Consequently, admins need to be strategic about how they assign permissions.
A Window Into CKS
Using RBAC to harden their clusters is just one thing that admins can learn by becoming a Certified Kubernetes Security Specialist (CKS). They can also learn cluster setup, system hardening, Identity and Access Management (IAM) roles along with other security practices to help secure their organizations’ Kubernetes clusters.
Here’s StackRox with more information about CKS:
The CKS is the third Kubernetes based certification backed by the Cloud Native Computing Foundation (CNCF). CKS will join the existing Certified Kubernetes Administrator (CKA) and Certified Kubernetes Application Developer (CKAD) programs. All three certifications are online, proctored, performance-based exams that will require solving multiple Kubernetes security tasks from the command line…. The CKS focuses specifically on Kubernetes’ security-based features such as role-based access control (RBAC) and network policies and utilizing existing Kubernetes functionality to secure your clusters.
To learn more about CKS certification, please visit CNCF’s website here.
About the Author: David Bisson is an information security writer and security junkie. He's a contributing editor to IBM's Security Intelligence, Tripwire's The State of Security Blog, and a contributing writer to Bora. He also regularly produces written content for Zix and a number of other companies in the digital security space.
Opinions expressed by DZone contributors are their own.