Part of our kubernetes series, lets Understand Kubernetes RBAC with concepts. Also, will try to cover some examples with top misconfigurations. Before we jump into kubernetes RBAC, let’s see what RBAC is.
What Is Role-Based Access Control?
Role-based access control is control over user groups and access to resources based on a defined role.
According to the National Institute of Science and Technology (NIST), “rudimentary forms of role-based access control were implemented in a variety of ad hoc forms on many systems beginning in the 1970s.” However, a formal model wasn’t proposed until 1992. Ferrailo and Kuhn published a paper that proposed an alternative to the traditional models of Mandatory Access Control (MAC) and Discretionary Access Control (DAC). RBAC defined three basic requirements for access control:
1. Role Assignment: subjects are assigned roles and only allowed transactions if allowed by the defined user-role.
2. Role Authorization: subjects only use roles for which they are authorized.
3. Transaction Authorization: subjects only execute transactions authorized by that subject’s role memberships.
A role is a collection of permissions. This allows organizations to grant appropriate permissions to employees or contractors, and ensure privileges and permissions keep to a role hierarchy.
What Is Kubernetes RBAC?
The Kubernetes API provides access to sensitive data, including deployment details, persistent storage settings, and secrets. Over the years, the Kubernetes community has provided several important security features to the Kubernetes API, including role-based access control (RBAC).
RBAC helps protect Kubernetes clusters by letting you control who has access to each API resource. This is much important, as several misconfigurations can lead to weak access controls that fail to implement the principle of least privilege.
Lets check about Kubernetes RBAC in detail.
Why Does RBAC Matter?
An RBAC mechanism provides fine-grained control over user privileges for software applications. It helps avoid accounts with excessive privileges by assigning functions to the individual users who need them.
Providing users with too many access privileges increases the risk of stolen or lost credentials and exposes the organization to insider threats. For example, developers should not have permission to delete a production deployment. Even if you trust every employee in your organization, malicious outsiders could gain control over privileged accounts through social engineering or phishing attacks.
RBAC in Kubernetes allows you to create policies that prevent users from performing admin-level actions, such as deleting pods.
There are several ways to use RBAC in a Kubernetes project:
- Integrate with an existing enterprise solution — the RBAC solution manages access to protected resources via a central role directory. Users can authenticate their identity and access resources in a Kubernetes pod, typically using a single sign-on (SSO) solution.
- Maintain fine-grained control over user access within a cluster — you can use RBAC to control which users have access to the Kubernetes cluster and the level of access to various parts of the project. This fine-grained control allows team members to access only the specific resources they need.
Kubernetes RBAC Basic Concepts
Here are some of the main Kubernetes elements for RBAC.
Role and Cluster Roles
A Role or ClusterRole in Kubernetes contains the rules and permissions for a RBAC given role. These permissions are always additive, so there are no negative rules like “deny.”
RBAC roles set the permissions for a specific namespace. When you create a new role, you must specify its namespace. In contrast, a cluster role is a resource without a namespace. These two resources (Role, ClusterRole) have different names because all Kubernetes objects must always be namespaced or non-namespaced — the same object cannot be both.
Cluster roles serve a variety of purposes, including:
1. Defining permissions for namespace resources that provide access to a specific namespace.
2. Defining permissions for namespace resources that provide access to all namespaces.
3. Defining permissions for cluster-wide resources.
You can use roles to define the permission in a specific namespace, while cluster roles can define permissions across the entire cluster.
Role and Cluster Role Bindings
Role bindings –RoleBinding grant the permissions defined by roles to the relevant user or user group. They contain a list of service accounts, users, or groups — subjects — and references to the relevant roles. While a role binding grants permissions in a specified namespace, a cluster role binding –ClusterRoleBinding grants access across the cluster.
Role bindings can reference any role in a given namespace. Alternatively, a role binding can reference a cluster role and bind it to the role binding’s namespace. You can use cluster role bindings to bind cluster roles to cluster-wide namespaces.
The name of either type of binding must include a valid path segment.
Continue Reading on https://foxutech.com/understand-kubernetes-rbac-concepts-example-best-practices/
