Configuring Kubernetes Role-Based Access Control with Lens Spaces

Setting up a Kubernetes service has become relatively easy, whether it be on-premise or in public cloud services. However, securely sharing access to this cluster with colleagues is a daunting task. Giving access can be a painful process involving cluster certificates, access management systems, networking setup, and firewalls.

Administrators typically do not want to expose their Kubernetes clusters on a public network directly. Instead, to secure access with colleagues, they either stay on a private network or create VPN access for remote work — a set-up that is not only expensive but challenging to implement. When you work with multiple clusters in different clouds, it requires numerous VPNs, and giving developers access becomes a true headache.

With Lens Spaces, a feature within Lens — The Kubernetes Platform, Kubernetes users can easily share access to a cluster securely. Lens Spaces utilizes end-to-end encryption to secure connections between users and clusters, eliminating the need for a VPN. This provides a much more secure environment for giving access to a Kubernetes cluster. Through Lens Spaces, multiple team members can access a Kubernetes cluster securely with the correct permissions associated. (If you’d like to learn more about how this works, check out the Lens docs.)

In this blog, I will address role-based access control (RBAC) via Lens and how to configure your RBAC manifest via Lens. This way, cluster administrators can easily manage cluster access. I will create specific roles that will dictate how a colleague may interact with our Kubernetes cluster.

Prerequisites:

1. Latest version of Lens
2. Kubernetes cluster
3. Lens Spaces account

Using Lens Spaces’ Built-In Teams for RBAC

To start, let’s talk about the default Kubernetes RBAC settings for users sharing secure access to their clusters via Lens Spaces. Each user connected to a cluster via Lens Spaces will get their permissions to a cluster via the Lens Spaces teams they belong to. Admins and owners of a space can easily change permissions using the Lens Spaces built-in teams: Members, Admins, and Owners.

• Members — Have Read Access to all connected clusters in a space
• Admins — Have Read & Write Access to all connected clusters in a space
• Owners — Have Read & Write Access to all connected clusters in a space

To support these roles, all clusters connected to Lens Spaces are preconfigured with the following Cluster Roles and Cluster Role Bindings:

ClusterRole: lens-spaces-view

ClusterRole: lens-cluster-admin (Read & Write Access)

ClusterRoleBinding: lens-platform-read-teams

ClusterRoleBindings:lens-platform-write-teams

Granular Configuration:

Although the default configuration may be useful to some, many cluster administrators need to adjust cluster access at a granular level. Admins and owners of a space can easily grant additional permissions by creating their own space “team”: for example, developers, operators, and L1 support.

Now, let’s imagine your space has a team called “Developers” and everyone within this team needs edit access to the default namespace. In order to do this, you will need to create an additional “Role-Binding.”

There are two ways to do this, and I will demonstrate both options.

The first (and more complex) option is writing and deploying the YAML code below to your cluster. Once deployed, everyone within the “Developers Team” will have edit access to the “default namespace.”

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: edit
namespace: default
subjects:
- kind: Group
apiGroup: rbac.authorization.k8s.io
name: lens-spaces:Developers
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: edit

Now for the simpler option: using Lens’ features to create the role binding that you envision, without the need to write any YAML.

In Lens, navigate to “Access Control” and select “Cluster Role Bindings”.

Once you are in the “Role Bindings” section of Lens within Access Control, click the + Icon on the bottom right.

You should see the following screen, which allows you to configure your new RoleBindings.

Now, it’s time to configure your RoleBindings via Lens. In this exercise, we are going to achieve the same outcome as the YAML code above.

Now you will need to input the values in the respected field.

Namespace = Default
Role Reference = Edit
Binding Name = Edit

Groups = Lens-Spaces:Developers (Press Enter to confirm the group)

Now you can click “Create” and your new RoleBinding will be created.

So what exactly did we do? With this change, anyone within the “Developers” team in your Space will have Read & Write Access to all resources within the “Default” namespace.

Now, developers will be able to easily review and access all logs within the “Default” namespace (for example).

Summary:

In this blog, I talked about the challenges that cluster administrators may face when sharing access to their cluster with colleagues and how to overcome these challenges. I took the time to provide in-depth examples of how you can leverage Lens Spaces to configure granular access control into a specific namespace within your cluster. With the changes we made, users can now view all resources within the default namespace.

About Lens:

Lens is the way the world runs Kubernetes. It’s lowering the barrier of entry for people just getting started and radically improving productivity for people with more experience. Users of Lens gain clarity on how their clusters and cloud native software stacks work. It helps people to put things in perspective and to make sense of it all. Thousands of businesses and hundreds of thousands of Kubernetes users develop and operate their Kubernetes on Lens. The Lens open source project is backed by a number of Kubernetes and cloud-native ecosystem pioneers. With a community of over 450,000 Kubernetes users and 17k stars on GitHub, Lens is the largest and most advanced Kubernetes platform in the world. Download Lens at https://k8slens.dev.