Lens Security: How Lens secures the software supply chain
Lens Desktop helps developers and operators save time and work smarter with Kubernetes. While a command-line client like kubectl is a refined instrument for Kubernetes professionals, the developers on your team probably aren’t Kubernetes pros, and they shouldn’t have to be—not if their job is to write, troubleshoot, and push code. In this series, we’ll explore how your team can use Lens to solve common Kubernetes challenges, including collaboration, security, and more.
High-profile software supply chain attacks like Log4Shell have placed cloud native security squarely in the spotlight. “Shift-left” security doctrines propose to place more of the onus for security on developers and address security concerns earlier in the development cycle. Around the world, governments are issuing security guidelines, frameworks, and regulations, from the U.S. National Cybersecurity Strategy to the European Union’s Cyber Resiliency Act.
You need to tackle the challenge of the modern security landscape—but you can’t afford to lose velocity. You need security tooling tailored to cloud native development and integrated with your existing development environment.
Lens gives you what you need with Lens Security Center, available to users with a Lens Pro subscription.
Built-in security
One of the fundamental benefits of an integrated development environment is that it reduces context-switching—this is how Lens can help you save a day of work every week. By making security tooling a natural element of your Kubernetes development environment, Lens reduces the friction of “shifting left” and helps you build more secure apps more quickly.
Security on Kubernetes can be a complex undertaking. Consider these numbers:
Sysdig’s 2023 Cloud Native Security and Usage Report found that 87% of container images included serious vulnerabilities, and 15% of those vulnerabilities reached production environments.
Meanwhile, security firm Armo found that out of 10,000 analyzed clusters, 100% had at least one misconfiguration error. (That's not a typo. Every single one.)
When you’re working on Kubernetes, you need to not only verify the integrity of your code, but the proper configuration of your Kubernetes resources. Lens Security Center takes a multi-dimensional approach, giving you a simple interface to assess your code and environment from multiple perspectives.
Container images
Security Center gives you the ability to peruse and scan container images—organizing images by pod, deployment, or namespace—or to evaluate images across an entire cluster. This capability is perfect for checking images on a development cluster before they move further down the pipeline.
With Lens Security Center, you can easily scan images against a continually updated Common Vulnerabilities and Exposures (CVE) database. Better yet, Security Center gives you a detailed report on any CVE it discovers, including the severity, the affected components, and even potential steps you can take to mitigate the issue. With just a couple of clicks, catch everything from buffer overflow issues to arbitrary code execution vulnerabilities. You’ll learn how to do this below.
Resource configuration
It’s all too easy to misconfigure Kubernetes resources—the abstractions that manage the relationship between your workloads and the Kubernetes system. This can be especially challenging for developers new to Kubernetes. Unfortunately, misconfigurations can have serious ramifications for security, not to mention cost and resource utilization.
The good news is that Lens Security Center gives you a way to automatically validate your container images and Kubernetes resources against security best practices. If someone on your team has improperly given a resource root privileges or inadvertently exposed sensitive information via environment variables, Lens Security Center can catch the error and help you address it. (Again, we'll see how to do this below.)
Roles and ClusterRoles
When we talked about Teamwork, we discussed the Role and ClusterRole resources and how they govern RBAC on a Kubernetes cluster. That’s obviously an important dimension of Kubernetes security, so Lens Security Center enables you to scan those resources for conformance to your organization’s particular requirements, assess different roles’ access to sensitive secrets, or verify a given role’s verb permissions on a given resource. Lens Security Center gives you the tools to validate security in a shared Kubernetes environment.
Using Lens Security Center
If you have a Lens Pro subscription, you already have access to Lens Security Center. Let’s take a hands-on walk through the features.
Want to follow along?
You’ll need a Lens ID and a Lens Pro subscription. If you don’t have a free Lens ID yet, you can sign up at https://app.k8slens.dev/signin. Click Create your Lens ID, and then enter a username, password, and email. (Alternatively, you can authenticate with a GitHub or Google account.)
Once you have a Lens ID, you can subscribe to Lens Pro at https://app.k8slens.dev/subscribe, on either a monthly or yearly basis.
In order to follow along with the exercise in this chapter, add the following YAML manifests to your cluster.
Pod - http-server
apiVersion: v1
kind: Pod
metadata:
name: http-server
spec:
containers:
- name: http-server
image: ericgregory/http-server
ports:
- name: web
containerPort: 80
protocol: TCP
Role - write-pods
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: write-pods
namespace: default
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list", "create", "update", "patch", "delete" ]
First, you’ll want to add some more workloads to scan. You can use Lens’ Helm integration to quickly deploy a Helm chart for a complex application.
Click Releases under Helm in the left-hand navigation menu.
Select the WordPress chart from the bitnami repository and click Install, using the default values in the manifest and clicking Install again.
Once the pods are running, scroll down to the bottom of the left-hand menu and click on Security Center. This will give you the choice of scanning Images, Resources, and Roles.
Select Images.
From the Images screen, you can see the images on the cluster and data from your scans.
The http-server from Chapter 1 passed its scan—excellent. Now you’ll scan the WordPress image. Click the ⋮ icon and select Scan.
Lens Security Center found two vulnerabilities in the WordPress image—one medium severity, and one high-severity. We can click on the image for detailed information on the vulnerabilities:
From here, we can follow links to the relevant CVE records. We also have references for the version of the runc component in which the issues are fixed.
In the left-hand navigation, under Security Center, click Resources. You will be prompted to install the Trivy operator on the cluster.
Once the operator is installed, Lens will give you a readout of resource configuration issues.
In this case, WordPress is looking good, but there are some medium-severity resource configuration issues on your http-server pod. Click on the http-server pod to get a detailed audit of the configuration issues.
The image is using the :latest tag, which is not a best practice, and more importantly it’s running as root, making it easy for the program to elevate its own privileges. This is an important issue to fix.
Finally, click on the Roles pane. Here you can see that the Trivy operator has already completed its scan, and the write-pods Role that you created earlier has passed the check.
Looking ahead
With Lens, you can take a multi-dimensional approach to early-cycle security concerns, tackling configuration and container image integrity issues before they balloon into bigger problems—and all without losing development velocity.
But in a constantly evolving open source landscape like cloud native, you need the ability to tailor your development environment to your changing needs. In the next chapter, we’ll see how Lens integrates with popular open source technologies and gives you the power to extend the platform even further.
