Access control processes and techniques enable you to control which applications and users are either allowed or denied certain access or permissions. Kubernetes is a popular open-source container orchestrator, commonly used to deploy mission critical applications. Access control is a foundation of Kubernetes security. Kubernetes provides two main access control options—Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC).

This article explains the differences between RBAC and ABAC, and how to enable and use these options in your Kubernetes clusters.

What Is Role-Based Access Control (RBAC)?

RBAC, or role-based security, is an access control technique that lets you assign permissions to end-users according to their role within the organization. RBAC offers fine-grained control. It is a simple and manageable access control approach, and is generally considered less prone to errors than individually assigning permissions.

RBAC can help protect sensitive data and reduce cybersecurity risk. RBAC enables organizations to implement the principle of least privilege, which can help ensure employees are granted only the privileges they require to perform their job. Ideally, employees should not be able to access information or perform actions they do need.

RBAC is ideal for large organizations that grant access to hundreds or thousands of employees according to individual roles and responsibilities. Smaller organizations also employ RBAC because it is easier than using access control lists.

RBAC systems define user access provisioning according to the common responsibilities and needs of a particular group. For example, the marketing department is considered a group. Each role gets assigned a specific set of permissions. To fine-tune permissions, you can assign one or more roles for each individual.

What Is Attribute-Based Access Control (ABAC)?

ABAC is an authorization paradigm that evaluates attributes or characteristics to determine access. The main goal of ABAC is to protect objects, such as network devices, IT resources and data from unauthorized actions and users. Any use or action that does not have the approved characteristics predefined in policies is not allowed.

How Does Kubernetes Authorization Work?

Kubernetes requires users to authenticate (log in) before authorizing requests (granting access permissions).

Kubernetes authorization can work with existing access control systems that handle a wide range of APIs, including the Kubernetes API. This is why Kubernetes is designed to expect attributes common to REST API requests.

Kubernetes denies permissions by default. The API server checks all request attributes against existing policies and then either allows or denies a request. To proceed, all components of the API request must be allowed by an existing policy.

The Kubernetes API server can use several authorization modes to authorize requests. Here are two primary methods:

• Role-based access control (RBAC)—a method that regulates access to network or computer resources according to roles defined for individual users. Access is defined as the ability of each individual user to perform a certain task. For example, create, modify, or view a file.
• Attribute-based access control (ABAC)—an access control model that grants access rights according to the combined attributes of policies. A policy can use any attribute type, including user attributes, objects, resource attributes and environment attributes.

Working with RBAC in Kubernetes

In Kubernetes, the rbac.authorization.k8s.io API group is responsible for driving  authorization decisions. This API group is a component of RBAC authorization that enables you to configure policies in a dynamic manner. This is especially important when Kubernetes performs autoscaling, to ensure that new resources added to the cluster have the appropriate permissions.

You can enable RBAC by starting the API server using the --authorization-mode flag and setting it as a comma-separated list, which must include RBAC.

For example: kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options.

The RBAC API can declare four types of Kubernetes objects, including Role, RoleBinding, ClusterRoleBinding, and ClusterRole. Each ClusterRole or Role contains rules, which represent a certain collection of permissions. Here is more information about each of these objects.

Role and ClusterRole

A Kubernetes object must either be namespaced or not namespaced—it cannot be both.

A Role lets you set permissions within a certain namespace. This means that when creating a Role, you must specify which namespace this role belongs in.

A ClusterRole is a non-namespaced resource. Here is what you can do with ClusterRoles:

• Specify permissions on a namespaced resource and gain permissions within the individual namespace.
• Specify permissions on several namespaced resources and gain permissions across all your namespaces.
• Specify permissions on a cluster-scoped resource.

You can define a role within your namespace by using - Role.

You can define a role across the cluster by using a ClusterRole.

RoleBinding and ClusterRoleBinding

RoleBinding grants permissions as defined within a Role to an individual user or set of users. A RoleBinding contains a list of subjects, such as users, service accounts or groups, as well as a reference to the specific role being granted.

A RoleBinding can grant permissions within a certain namespace. A ClusterRoleBinding, on the other hand, grants access across an entire cluster.

A RoleBinding can reference any Role within the same namespace. A RoleBinding may also be used to reference a ClusterRole to bind it to a namespace associated with the RoleBinding.

You can bind a ClusterRole to all namespaces within a cluster by using a ClusterRoleBinding.

Working with ABAC in Kubernetes

To enable ABAC mode in Kubernetes, use the following flags on startup:

• --authorization-policy-file=SOME_FILENAME
• --authorization-mode=ABAC

Here are several aspects to consider when using ABAC in Kubernetes:

• You can only use a file format of one JSON object per each line. You should not add a map or an enclosing list—use only one map per each line. Each line serves as a policy object, and each policy object offers a map with a variety of properties.
• Each request consists of attributes that correspond to all properties belonging to a policy object. Attributes are determined once a request is received.
• A tuple of attributes is always checked for a match against all policies within a policy file. The request is authorized only if at least one line matches the request attributes. However, a request can still fail any later validation process.

RBAC vs RBAC: Which Should You Use in Your Kubernetes Cluster?

Here are the most common use cases for RBAC:

• Small organizations with basic permission structures—for example, organizations with 20-50 users.
• Organizations with role-based hierarchies—you can use RBAC if the access control policies within the organization are defined according to roles and are not task-based. However, large enterprises usually require more sophistication and should use symmetric RBAC.
• Simple and non-business critical applications—you should use RBAC for simple applications. However, use RBAC only if your application is not mission-critical and you are not required to handle access to potentially sensitive data.

Here are the most common use cases for ABAC:

• Companies with offices in multiple locations or a large, distributed workforce—organizations with employees working remotely or from geographically distributed networks and offices need to control access to systems according to time zones, geographical locations and network connections (VPNs). ABAC enables you to control these attributes. You cannot do this with RBAC.
• Organizations that require dynamic controls—companies often need to create authorization rules based on properties that are derived from external data sources. For example, a rule that grants users access to the system only if their Account Status in Salesforce equals Customer.

RBAC is a static framework and cannot support dynamic and contextual business rules. ABAC, on the other hand, can be applied universally to any technology stack and infrastructure, including the network layer, the data layer and the application layer.

Since there are ideal scenarios to each access control technique, you can employ a hybrid approach that combines the two control models in a manner that suits your unique requirements.

Conclusion

This article covered the main differences between two Kubernetes access control methods—RBAC and ABAC. To summarize, RBAC uses roles defined for individual users in order to regulate access to network or computer resources. ABAC, on the other hand, grants access rights according to the combined attributes of policies.

RBAC is usually applied for small organizations, whereas ABAC is used to enable a distributed workforce and dynamic controls. Ideally, you should leverage the benefits of both methods in order to satisfy the access control requirements of your scenario.

______

Author Bio: Gilad David Maayan

Gilad David Maayan is a technology writer who has worked with over 150 technology companies including SAP (News - Alert), Imperva, Samsung NEXT, NetApp and Ixia, producing technical and thought leadership content that elucidates technical solutions for developers and IT leadership. Today he heads Agile SEO, the leading marketing agency in the technology industry.

LinkedIn (News - Alert): https://www.linkedin.com/in/giladdavidmaayan/

---

(Twitter (News - Alert): https://twitter.com/gilad_maayan)

(FB: https://www.facebook.com/gilad.maayan)