We are often asked about the difference between Kubernetes Role Based Access Control (RBAC) and Cloud Identity and Access Management (IAM). The concepts are related, but not the same, and not interchangeable by any means.Their differences have implications for Kubernetes security, which are important to know both for setting up your Kubernetes environment as well as maintaining it.
What is Kubernetes RBAC?
Role Based Access Control (RBAC) is a system for managing permissions or authorizations based on role or “group” assignments. As a simple example: you might have “roles” within your organization that cover your “accounting”, “HR”, “IT”, and “security” divisions (hopefully your roles are a bit more fine grained than that, but we’re keeping this simple). Each of those roles would have permissions attached to them for accessing certain systems (and certain permissions within those systems) in your technology infrastructure. Individual users are then granted permissions by being assigned to certain roles. One significant advantage of RBAC is the reduction in “overhead” and its potential for error: by assigning permissions at the group or role level, there are fewer unique permission sets to manage (1 per group/role instead of 1 per user) and it is easier to ensure that users have been correctly assigned permissions, especially when they change roles (simply change their group/role assignment instead of modifying all of their unique authorizations). At a conceptual level, RBAC requires a few components:
- Roles users can assume that define a set of permissions
- Users who can be assigned to those roles (and a way for those users to authenticate)
- A mechanism for assigning those users to roles
RBAC is directly concerned with the first and third of these. The creation of user identities and how users authenticate to them is outside the scope of RBAC, but is a prerequisite for implementing RBAC. See this blog for more details on RBAC.
How Does Kubernetes RBAC Relate to the Principle of Least Privilege?
The Principle of Least Privilege is a security concept which aims to provision only the permissions a user requires to perform their normal duties and no more. Following the Principle of Least Privilege means (a) not granting users permissions they don’t need, and (b) not using “admin” level permissions for normal work, thereby requiring users to explicitly elevate themselves to admin when they need those privileges for a task. RBAC can help and hurt when implementing the Principle of Least Privilege. There is a balancing act with RBAC between drawing roles too broadly (and thereby likely over-provisioning permissions for many users) and creating too many narrow roles (and thereby increasing the administrative burden of implementing RBAC). An ideal RBAC implementation will achieve something close to the Principle of Least Privilege, and in particular will ensure that there are separate roles for admin and non-admin permissions.
How Does Kubernetes RBAC Work?
RBAC has become the gold standard for how to manage permissions within a Kubernetes cluster. In Kubernetes, the first component above (“Roles users can assume”) is covered by Kubernetes Role and ClusterRole objects, and the third (“mechanism for assigning users to roles”) by RoleBinding and ClusterRoleBinding objects. Role and RoleBinding objects are scoped to particular namespaces, whereas ClusterRole and ClusterRoleBinding objects are cluster-wide. You can read more about how to use these objects in our post “Three Critical Kubernetes Concepts for Security Architects.”
What Is Cloud IAM?
Identity and Access Management (IAM) in cloud security is an umbrella phrase for a variety of systems and processes that manage any of the following:
- Creation and deletion of user identities
- How users authenticate to their identities
- Mapping authenticated user identities to particular permission sets
This comes into play most often in the case of a managed Kubernetes service, where you would be dealing with the likes of AWS IAM, Azure AD or Google Cloud Identity. Each IAM service has unique features and integrates differently to the services in each cloud platform.
How Does Kubernetes RBAC Relate to Cloud IAM?
RBAC is a particular strategy for handling the third item listed above: “mapping authenticated user identities to particular permission sets.” As discussed, RBAC does this by using group/role assignments to determine permission sets. This is not the only way one could manage those permission sets (for example, they could be set at the individual user level), but it is one of the most popular approaches, especially in the context of Kubernetes.
What Aspects of Cloud IAM does Kubernetes RBAC not Cover?
RBAC is only focused on authorization, or mapping authenticated user identities to their correct permission sets. As such, RBAC provides a way for defining those permission sets (roles) and a way for mapping them (assignments), but it does not, on its own provide:
- Ways of creating identities (the actual users you will map to roles)
- Ways of authenticating users to those identities
What Does this Mean for Kubernetes?
Defining and authenticating identities in Kubernetes requires additional components and, most likely, external integrations with your organization’s identity provider. Kubernetes does not actually have an API object for “normal” users (only service accounts), so defining and authenticating users has to be done externally. Once authenticated, you can use (Cluster)RoleBindings to assign the identity to certain roles (with the identity being recognized in-cluster by things like the subject field in an X.509 certificate). This in-cluster “authentication” step is rather flimsy— Kubernetes just takes your word for it that you are who you say you are— which underscores why it is critical (a) that your control plane not be accessible over the internet (allowing you to use more robust authentication systems to broker access) and (b) that you have a well defined RBAC schema that narrowly defines permissions for users to limit the blast radius of a “stolen” user identity.
How Can KSOC Help with Kubernetes RBAC
KSOC can monitor the actual usage of the (Cluster)Roles available in your cluster. This is intended to help you do two things. First, comparing actual usage with the permissions defined in the role can help you adhere to the principle of least privilege by identifying permissions that are not needed and can be removed. Second, real-time monitoring of permission use can help you spot anomalous, potentially malicious use of the permissions allowed by a Role.
To learn about the most common over-permissions in Kubernetes RBAC, check out the full whitepaper. Or skip it and schedule a demo today to see real-time Kubernetes Security Posture Management (KSPM) in action.