Zero Standing Privileges for Kubernetes RBAC

Securing the Kubernetes (k8s) environment requires planning and a multi-layered approach. The k8s user management capabilities are flexible but limited. Managing user access to k8s requires well-designed authentication and authorization platforms with support for role-based access control (RBAC), and user federation/authentication amongst various other capabilities.

Much like many cloud environments, the growth of k8s platforms within an organization has been exponential with more and more application developers and DevOps teams preferring k8s over other types of infrastructure. Ensuring security across hybrid and multi-cloud environments is complex.

The pain point is shifting from ensuring security at the time of deployment to maintaining the security of multi-cloud, multi-cluster environments over time. Teams are getting better at deploying Kubernetes securely—even across different clouds—but are struggling to maintain security in multi-cloud environments.

In this blog, we shall look at authorization options for Kubernetes and how Britive facilitates centrally managed access across all k8s clusters with time-bound and limited access permissions.

Authorization in Kubernetes

The Kubernetes API server may authorize a request using one of several authorization modes: Node, ABAC, RBAC, and Webhooks. RBAC and ABAC are widely used for user and service account authorization. Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise. In this context, access is the ability of a particular user to perform a specific task, such as view, create, or modify a file. RBAC allows for fine-grained access control policies that suit an organization’s security requirements. RBAC allows you to segregate responsibilities by assigning different roles to different teams or individuals.

RBAC enables you to restrict access to specific namespaces. This can be useful when multiple teams or projects share a cluster, and you want to isolate their resources and limit their privileges within their designated namespaces

The RBAC API declares four kinds of Kubernetes objects: Role, ClusterRole, RoleBinding, and ClusterRoleBinding. We can describe or amend the RBAC objects using tools such as kubectl, just like any other Kubernetes object. The RoleBindings are particularly important for our implementation as this allows us to grant user access to k8s objects upon request on a just-in-time (JIT) basis.

Roles

As noted in the official documentation, A Role always sets permissions within a particular namespace; when you create a Role, you have to specify the namespace it belongs in. ClusterRole, by contrast, is a non-namespaced resource. The resources have different names (Role and ClusterRole) because a Kubernetes object must always be either namespaced or not; it can't be both.

ClusterRoles have several uses. You can use a ClusterRole to:

1. define permissions on namespaced resources and be granted access within an individual namespace(s)
2. define permissions on namespaced resources and be granted access across all namespaces
3. define permissions on cluster-scoped resources

Role Bindings

A role binding grants the permissions defined in a role to a user or set of users. It holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted. A RoleBinding grants permissions within a specific namespace whereas a ClusterRoleBinding grants that access cluster-wide. A RoleBinding may reference any Role in the same namespace. Alternatively, a RoleBinding can reference a ClusterRole and bind that ClusterRole to the namespace of the RoleBinding, though this not widely used. If you want to bind a ClusterRole to all the namespaces in your cluster, you use a ClusterRoleBinding. Command line utilities to manage these objects are described here.

Examples

Roles

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: app-1 name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"]apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: secret-reader rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"]

Bindings

apiVersion: rbac.authorization.k8s.io/v1 # This role binding allows "jane" to read pods in the "default" namespace. # You need to already have a Role named "pod-reader" in that namespace. kind: RoleBinding metadata: name: read-pods namespace: default subjects: - kind: User name: jane # "name" is case sensitive apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.ioapiVersion: rbac.authorization.k8s.io/v1 # This cluster role binding allows anyone in the "manager" group to read secrets in any namespace. kind: ClusterRoleBinding metadata: name: read-secrets-global subjects: - kind: Group name: manager apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io

Britive’s Approach to Secure Kubernetes Access

The examples above highlight the simplicity of role definitions and bindings. This simplicity also brings with it a complex challenge of managing access and granting just enough permissions to user and user groups. Though the framework is a as part of the any base Kubernetes platform designing, implementing, and scaling effective RBAC solution is often left to the administrators.

Without the help of a mature third-party solution various operational and security challenges may arise. Most organizations today use some of group-based RBAC model within their IAM eco-system. These capabilities can be extended to all Kubernetes cluster with the help of proven and standards-based approach. Britive’s Kubernetes access platform leverages short-lived Open-ID Connect tokens to grant fine-grained time-controlled access to the clusters.

Britive’s approach helps every organization to move away from synching long-term, unaudited group memberships to all the clusters. Instead Britive allows for just enough access via the tokens for each cluster or a namespace within a cluster

Britive Access profile and policy-based access broker allows organization to define fine-grained policies to limit session bloat while enabling developers and admins alike to move within their environment at the speed cloud. Britive’s privilege access broker mints short-lived tokens that contain just enough access permissions for an individual session. These access permissions are coupled with Kubernetes RBAC group bindings for effort-less security and auditability.

Britive’s command utility seamlessly works in the background to make all of this possible for the end users. The users are able to use the tools and workflows they’re already familiar with without the need of additional steps or cumbersome proprietary utilities.

In the next blog, we will go through a real-world example of this solution with a detailed configuration of the Britive platform and automation tools available at your disposal to make this possible.