Forem: Eionel

Configuring Kubernetes Role-Based Access Control with Lens Spaces

Eionel — Thu, 03 Mar 2022 18:17:07 +0000

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:

Latest version of Lens
Kubernetes cluster
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.

How to Build & Scale a Useful Open Source Technology

Eionel — Wed, 09 Feb 2022 17:59:42 +0000

It is now February 2022, 16 months after launching Lens - The Kubernetes Platform as an open source project. How has the project come so far in such a short time?

Lens was built to help developers, operators, and site reliability engineers take control of their Kubernetes clusters like they never imagined. Today, Lens has over 500,000 active users and over 17,000 GitHub stargazers. As a growing community, Lens has become one of the top trending open source projects within the cloud-native ecosystem. It has been adopted by some of the largest companies across the globe and is seeing over 15% month-over-month growth.

Growing an open source technology can be challenging for many reasons, from user adoption to building trust within the community, and of course, overall product retention. In this post, I’ll break down the tips and tricks we have used to ensure our open source project’s success within the cloud native ecosystem.

Step One: Understanding the Challenges

As Kubernetes users, we understood that Kubernetes has many underlying challenges that individuals and organizations need to overcome for their application modernization initiatives to be successful. Managing Kubernetes means writing code and keeping track of multiple Kubernetes YAML files and sets of access details. Keeping track of all of this information and all of these resources becomes especially challenging when working with dozens of Kubernetes clusters.

We identified several underlying challenges when it comes to Kubernetes, including:

The technology can be complicated and a burden to learn.
Understanding the root cause of errors is increasingly challenging.
Individuals / Organizations spend too much time helping users onboard their applications.
Users spend too much time switching between browsers, command lines, and documentation.

These issues are only the tip of the iceberg, but for the purposes of this blog, I want to emphasize that when you are trying to create something truly extraordinary you must sell the problem you solve, not the product…and before you can do that, you need to have a clear understanding of what that problem is. Once you've identified the problem space, you can move on to the next step, which is identifying the value you bring.

Step Two: Understand Your Product’s Value Prop

As you begin your journey in building an extraordinary product, software, or technology, you need to understand the value prop that you are providing to your end users or customers. Based on the challenges you have identified, this is where you begin to think of the solution to these challenges. So how do you begin?

One great advantage we have in building an open source project that provides value is simply being an end user. What exactly do I mean by that? Well, it's quite simple: the majority of individuals who are building an open source project are most likely already experts in the topic at hand.

With Lens, most of our engineers and developers already work with Kubernetes on a daily basis, easily identifying the challenges. Lens made their lives easier. Your team should benefit themselves from the open source project you build. If your team cannot benefit from the project, there is a strong possibility your targeted audience won’t either.

One feature we implemented for Lens is product telemetry. In our license agreement and source code, we ensure that we are able to collect anonymous user telemetry data that provides insights and highlights our user journey (while giving users the option to opt out, of course). We leveraged this telemetry data to better understand our user usage patterns, aggregating and analyzing this data to make product roadmap decisions, improvements and to understand why and how our users leverage Lens. Real time telemetry is by far the most influential data we could leverage; the hard part is digesting and analyzing it appropriately.

We also took the opportunity to incorporate real time surveys that our users can fill out to give us a better understanding of how to position our roadmap moving forward. Leveraging both our telemetry and real time surveys gave us a clear understanding of how our users are leveraging our technology and how we can improve our product.

*The main point I want to make here is that it is never easy to identify the true value your product brings to its end users, but there are several channels that you can explore to better understand how your users leverage your product. When building your product, it is essential to implement telemetry to identify usage patterns of your users.
*

Step Three: Build a Product That Resonates with All End-Users

When it comes to adoption, not much has changed. We know that we need to build a tool that is explicitly geared towards our end users. Our audience, specifically developers, operators, and site reliability engineers, all have one thing in common. They want to improve their overall efficiency, when working with Kubernetes. The goal is to eliminate complexity and increase productivity.

Every one of our “potential” users has a different level of expertise when working with Kubernetes, which meant we had to focus on building a tool that both experienced and novice Kubernetes users could use daily. This is our third step and one of our most important: creating a product that can resonate with all Kubernetes users, regardless of their experience. I know this might sound cliché, but I can’t overstate how essential it is to understand your targeted end-user.

*The main point I want to stress here is that your entire targeted audience should have the ability (and desire) to get up and running with the product relatively quickly. The solution, product, or tool should be so easy to use that anyone can become a “power user” with minimum effort (and without having to read documentation).
*

Step Four: Listen to the Community

Okay, now for the part you guys all care about: how Lens grew from 0 to 500,000 active users in less than two years. The majority of our growth came with virtually zero PR and without a profound marketing budget. The open source application grew, and continues to grow, primarily from word of mouth.

Yes, I said it: word of mouth. I know it's not the growth hack you were expecting, but Kubernetes developers, operators, and SRE’s currently using our product did the majority of the heavy lifting for us.

But that doesn't mean that we ignored the need to increase user adoption. One of the most important things we did to improve user experience and growth was to enable our community to provide feedback.

Due to this opportunity, we have had over 1000 commits with roughly 1200 issues resolved within the first sixteen months of Lens being launched as an open source project—and we are just getting started! We quickly learned that resolving issues in a timely fashion demonstrated our care and respect for our users and the product, resulting in us quickly building trust within the open source cloud native community.

Indeed, to “hack” the system, you need to focus on developing a fantastic product. What do I mean by that? Well, I think author Seth Godin says it best: “Don’t find customers for your products, find products for your customers.” And this is precisely what we did. We put our end user’s biggest challenges first and built a product that anyone within the Kubernetes ecosystem could use. We learned that everything started with the product, so we asked ourselves, “Are we building something extraordinary that our end users would be willing to share with their colleagues?” If the answer to this question is anything but yes, then you have some work to do.

When it comes to building something truly extraordinary, you need to focus on understanding everyone that will try or use your product.

Do we solve problems, or are we just trying to sell a product?
Are we incorporating our user feedback into the solution?
Can anyone within the Kubernetes ecosystem use our product?
Is our product extraordinary and easy to use?

*The main point here is that you will never know exactly what it takes to make your product, technology, or software extraordinary. But there are several things you need to do to ensure you are on the correct path. The bullets mentioned above are specific things we kept in mind while building Lens.
*
Feel free to reach out to me directly if you would like a further conversation around this topic. Thank you for your time.

About Lens - The Kubernetes Platform

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.

What to Look For When Evaluating a Container Registry Solution

Eionel — Wed, 22 Dec 2021 17:45:19 +0000

Kubernetes is quickly becoming the de facto operating system for the cloud. It delivers common APIs and services for running software distributed on modern cloud based infrastructure. With strong support from all cloud technology mega-players, it has already been adopted by thousands of cloud based software projects. This is great! Right?

Setting up a Kubernetes service has become relatively easy, whether it be on-premise or in public cloud services. However, establishing a validated container registry solution to ensure the software supply chain is secure isn’t easy. There are many solutions when it comes to a container registry, and choosing a solution that meets enterprise requirements is challenging. The right solution needs to be able to validate, comply, automate and organize the images and workloads securely.

First, organizations need to identify whether they want a private or public registry. Generally speaking, public repositories make sense for individuals and small teams that want to get up and running relatively quickly. That being said, public repositories do not have security features such as privacy and access control, making it impossible for them to meet enterprise requirements.

Organizations that want to scale their container initiatives require a private container registry that meets enterprise standards. The solution needs to be able to scan for vulnerabilities, ensure role-based access control management, optimize for automation, and support various authentication systems.

Container registries play a crucial role in any container management strategy. In this blog, I will address the different types of container registries and how to select one to meet enterprise requirements.

Public vs Private Registries

Although adopting an image registry may seem straightforward, not all registry solutions are built equally, and they offer significant differences. Let’s take a look at the most commonly used registry types: public and private registries.

Public Registries

Public registries like Docker Hub are a common solution for many container management strategies. Public solutions are quite basic and easy to use, and small teams and organizations can begin to leverage public registries to get up and running relatively quickly. The caveat to this is when you begin to scale and share images among thousands of developers and locations. Public registries have only basic functionality and do not work well when trying to meet enterprise needs and requirements. As use of the registry grows, images become more vulnerable and become a security issue. This is where public solutions may begin to fall short of expectations.

With the recent news of Log4J’s security vulnerabilities, scanning your images for vulnerabilities is more important than ever. However, the majority of public registry solutions do not have the capability to scan images for vulnerabilities and thus do not meet enterprise requirements. Lately, public cloud providers are not foolproof. As the data suggests, public clouds are not invisible and outages will occur. Enterprises that need to meet regulatory requirements require a fool-proof solution.

Private Registries

Private registries are usually the go-to solution for secure enterprise container management strategies and for good reason. As mentioned above, public registries rarely meet enterprise requirements and are susceptible to many vulnerabilities. Enterprises need a private registry solution that meets all use-cases.

Evaluating the right container registry solution is never easy; the solution needs to meet several use cases. The most robust private registries can secure the software supply chain, store and manage images, and meet governance and compliance requirements.

Now that we understand public and private registries, let’s go into depth on what to look for when evaluating a container registry solution.

Critical Container Registry Features

There are numerous use cases to look for when evaluating a container registry solution. One of the most important features to look for is mirroring policies for a repository.

When an image gets pushed to a repository and meets the mirroring criteria, the registry will automatically push it to a repository in a remote registry. The most robust container registry solution should meet each of these use cases, securing the software supply chain, storing and managing images and meet governance and compliance requirements.

Below, I will quickly showcase each feature needed to meet all three of the above use case requirements.
Enterprise Grade Registry Features

Access Control
- IDM integration and Role-based access control to ensure strict access controls
Image Scanning
- Gain visibility into security vulnerabilities in images
Image Storage
- Securely store images and make them available to all developers
Cache & Monitoring
- Put images right where they are needed
Policy & Promotion
- Enforce security controls with promotion policies
Image Lifecycle
- Automatically manage images based on policy
Image Signing
- Verify image authenticity before running

Each of the features listed above in compass everything needed to secure the software supply chain, ensure the images are stored securely, and meet compliance requirements. Evaluating and selecting the correct container registry solution is a critical component of any container management strategy.

Final Thoughts:

Getting started with a container registry in order to secure the software supply chain is a must. With the various types of registries currently available, teams and organizations need to understand which use case fits them best. From an enterprise perspective, security and policy management controls play a vital role in selecting the correct container registry. Smaller teams may opt for a public registry in order to move quickly. Below you will find a list of container registry solutions that you can get started with today.

Container Registry Solutions:

Mirantis Secure Registry (formerly Docker Trusted Registry) Enterprise grade container registry is built to securely share, store and deploy container software anywhere.
Amazon Elastic Container Registry Easily store, share, and deploy your container software anywhere
Google Container Registry Store, manage, and secure your Docker container images

How To Give Developers Secure Access to Kubernetes Clusters

Eionel — Mon, 08 Nov 2021 18:47:28 +0000

Installing Lens

Navigate to the Lens website (https://k8slens.dev/) and download the latest version of Lens for your preferred OS. Once you have downloaded and installed, open the application, Lens IDE will automatically add your Kubeconfig (if done correctly, you will see a cluster icon on the left-hand-side). Lens works with any certified CNCF Kubernetes distro.

Now that your cluster has been added, you have full situational awareness of your Kubernetes cluster. Users can easily monitor all objects and resources within their cluster.

Creating a Lens Space account

In order to share a cluster with a team or team member, you will first need to create a Lens Spaces account:
In the bottom right corner of Lens, click “Lens Login” (or go to https://app.k8slens.dev/signup)

Click “Create an account” and follow the process to sign up for a Lens Spaces account. Once you have registered for an account, log into Lens Spaces and open up the desktop application.

Creating a Lens Space and Sharing Access to Your Cluster
Once logged in, you will need to create a secure “Space” in Lens 5 and share your cluster to that space. To do so, click on your username in the bottom right corner of Lens 5 and select “Add Space …”. Enter a unique Space name.

Now, navigate to your “Catalog” on the left-hand side of the desktop application. Within the Catalog, navigate to the “cluster” you just added. Click the ellipsis on the right-hand side of your cluster and select “Share Cluster”.

From there, you will need to select the space you would like to add the cluster to. Select the space you just created and specify the region for Cluster Connect Server Infrastructure (Lens Agent is installed in your cluster). Now, select “Install Cluster Connect and Share”.

You have now successfully installed Cluster Connect to your cluster and shared it to the selected Space. You can learn more about Cluster Connect here.

Invite members to your Space

Now that you have created a Space and shared the selected cluster to the Space, you will need to invite members to your Space to share access to your cluster.

Now Navigate to the share icon on your cluster, and select the Space you wish to add members to.

Enter your colleague’s username or email address (Press enter to confirm). If the invitee already has a Lens Spaces account, they will receive a direct invite, otherwise, they will need to receive an email invite.

Accepting a Space Invite:

For an invitee to access your cluster, they need to accept your invitation:

Click on your username in the bottom right corner. Click “My Profile”. Within your profile settings, click “Spaces”. You will now be able to see “Invitations”. Click “Accept”. You have now joined a new Space.

In order to view the shared clusters, close your Lens Space settings and navigate to your “Catalog”. Here, you will be able to view clusters that you have permission to access.

Creating a Team Within Your Space

In order to give specific access to a particular team or team member, you will need to create a “Team” within your Space.
Begin by clicking your username in the bottom right-hand corner and choose “Edit Space …”.

Select the “Space” you would like to add a “Team” to. Now, within your Space settings, click “Teams”. Then click “Create New Team” and enter the team name.

Once you have created a team within your Space, you will need to add a member to that team.

Click the ellipsis on the right side of your team and select “Add Member” then select a Space member (You can not add members to a team who are not already a part of your Space). You have now successfully created and added a member to the team.

How To Give Granular Access

Okay, now you may want to grant more specific permissions to the team you just created.

Let’s imagine your space has a team called “Developers” who need read access to a single namespace called “monitoring”. In order to do this, you will need to add “RoleBinding” to your Kubernetes Cluster.

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

This will grant lens-spaces-view role to the “Developers team” in the monitoring namespace.

In addition to this you may want to limit Space members permissions, by default we grant read access to all namespaces. To change this, you can edit or remove lens-platform-read-teams ClusterRoleBinding.

About Lens

Lens provides the full situational awareness for everything that runs in Kubernetes. It’s lowering the barrier of entry for people just getting started and improving productivity for people with more experience. Lens is built on open source and free of charge for any purpose. The Lens open source project is backed by a number of Kubernetes and cloud-native ecosystem pioneers. With more than 5 million downloads, over 250,000 users, and 15.3k stars on GitHub, it’s the most popular IDE for Kubernetes. https://k8slens.dev.