Lens Teamwork: How Lens connects teams on Kubernetes

If you’re working on Kubernetes, you’re probably working as part of a team. 

That means you need fine-grained role-based access control (RBAC) and a way to get new teammates up and running quickly. But if you’re working with Kubernetes straight out of the box, you’re out of luck. The Kubernetes API provides only the most bare-bones abstractions for “users” and leaves many fundamental RBAC decisions as exercises for the reader.  

But the way you share access to a cluster has important implications for everything from productivity to security. Lens Teamwork features make it simple to work with Kubernetes as a team—smoothly and securely.

You have a vanilla Kubernetes cluster, and you need to create a “user” for a new team member. If you were using out-of-the-box tools alone, that means you’d need to use kubectl to create a set of properly configured Kubernetes resources. 

First you’d need to enable RBAC by starting the Kubernetes API server with the appropriate flag:

% kube-apiserver --authorization-mode=RBAC

Next you’d need to define either a Role object (if you wanted users with this Role to be limited to a particular namespace) or a ClusterRole (if you wanted more flexibility).  

The YAML for a Role that enables write access on pods in the dev namespace might look like this:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: write-pods
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list", "create", "update", "patch", "delete" ]

You’d need to define appropriate access per resource, and per role, and then define each user in a RoleBinding object that assigns the Role attributes to individual users:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 name: write-pods
 namespace: dev
subjects:
- kind: User
 name: ada
 apiGroup: rbac.authorization.k8s.io
roleRef:
 kind: Role
 name: write-pods
 apiGroup: rbac.authorization.k8s.io

It’s a lot to manage at any scale—and you still haven’t solved fundamental problems like how to connect a user with the cluster securely. This is especially important for a distributed team. Exposing the Kubernetes API to the internet is highly insecure—will you use a VPN, complex IAMs, or another solution?

Lens provides a simpler way to manage users, and easy answers to the tough questions.

Lens is designed to make sharing secure cluster access a matter of point-and-click. With a Lens Pro subscription and a Lens ID, you can create a Team Space directly from the Lens preferences pane. Simply click Create new Space.

Name your new space and click Create Space. Now you can select Members to manage team member invitations and permissions. (You can also click Teams in the navigation bar to manage separate teams within the Team Space.)

Select Members.

On this pane, click Invite New Members to add members to your Team Space. On the next screen, you can invite new members by their Lens ID or email address—or you can create a link to easily share with new users.

Here you can define members’ permissions within the Team Space. The default roles include:

• Member: This role has read access to clusters connected with the Team Space, and can observe activity within the Team Space.

• Admin: This role has read and write access to connected clusters. It can also create and manage teams within the Team Space. 

• Owner: This is the role of the Team Space creator; it has read and write access to connected clusters and control over the Team Space.

If you want to utilize Kubernetes RBAC functionalities, you can do that, too—users with cluster read and write access will be able to create Role, ClusterRole, RoleBinding, and ClusterRoleBinding resources like usual. But with Lens, you can easily manage those resources from the Access Control pane—and create them as needed with a click of the plus sign button on the lower-left-hand of the screen.

Now that you have your Team Space and users configured, it’s time to connect them to a cluster. Since your Team Space is independent of any given cluster, you can connect it to multiple clusters, or to new clusters as needed. 

Press Escape to head back to the main Lens Desktop screen. From here, connecting a Team Space to a cluster is a simple matter of clicking the plus sign in the upper-right-hand corner when you’re managing a cluster through Lens.

Now you can simply select your Team Space and connect it to the cluster.

This Cluster Connect feature enables you to securely connect with a wide variety of Kubernetes cluster types, including:

• Amazon Elastic Kubernetes Service (EKS)

• Azure Kubernetes Service (AKS)

• Google Kubernetes Engine (GKE)

• Local development clusters

• On-premises clusters

The Cluster Connect tunnel is created using TLS encryption and the open source BoreD project’s tunneling system.  Whatever type of cluster you’re using, connections between Lens—for each Team Space user—and the Kubernetes cluster are end-to-end encrypted. Developers and operators can work on shared clusters easily from anywhere. Security for a distributed team is a simple point-and-click.

Of course, cloud native security is no simple matter, and you will need more than secure cluster access to harden your Kubernetes security. In the next post, we’ll take a look at how Lens provides the tools to make security simpler and easier.