Using the Kubernetes Lens Dashboard to Boost Kubernetes Security

Kubernetes security is a complex challenge. Luckily, new open source tools are springing up to help address it. I’ll discuss a new, popular tool called Kubernetes Lens, which is making Kubernetes clusters easier to manage and more visible for DevOps teams while helping boost security.

What is Kubernetes Lens?

Kubernetes Lens is an integrated development environment (IDE) that allows users to connect and manage multiple Kubernetes clusters on Mac, Windows, and Linux platforms. It was originally developed by Kontena, was acquired by Mirantis, and open sourced under the MIT license.

Lens provides a graphical interface that lets you deploy and manage Kubernetes clusters, as well as view key metrics and insights on the resources running on a cluster. These metrics include configuration, networking, storage and access control.

Kubernetes Security Issues and Risks

Cluster Misconfiguration and Default Settings

The Kubernetes API and its components consist of a complex set of resource definitions and configuration options. Kubernetes provides default values for most configuration parameters, to avoid the burden of creating long YAML files. However, you should be aware of three important security issues related to these default settings:

● The default Kubernetes configuration is not always the most secure choice.
● Online code samples of Kubernetes resources can help you get started, but you should carefully review what these example resources define for deploying to your cluster.
● When working on a cluster, it’s common to use the “kubectl edit” command to change Kubernetes resources.

However, if you forget to update your source files, your changes will be overwritten the next time you deploy, and untracked changes can lead to unexpected behavior.

Kubernetes RBAC Policies

RBAC is the Kubernetes native way of managing and controlling authentication to Kubernetes resources. Therefore, it is important to configure and maintain RBAC policies to protect your cluster from unwanted access and insider threats.

There are two things to consider when using RBAC policies:

● Some RBAC policies are too permissive, such as the cluster_admin role, which allows you to do anything on the cluster by default. These roles might be assigned to developers to allow higher productivity, but in the event of a security breach, an attacker could use cluster_admin to quickly gain advanced access to the cluster. To prevent this, you need to configure RBAC policies for specific resources and assign them to specific user groups.
● The software development lifecycle typically includes multiple environments: development, testing, staging, and production. There are typically multiple teams focusing on different priorities: developers, testers, operators, and cloud administrators. RBAC policies should be appropriately assigned to each group and each environment to limit exposure.

Holistic Monitoring and Audit Logging

When deploying an application to a Kubernetes cluster, monitoring application metrics is not enough. You also need to monitor Kubernetes cluster health, cloud infrastructure, and cloud controllers to get a full stack graph. Intruders test access to your cluster in every possible way, so monitoring for vulnerabilities and detecting anomalies is also important.

Kubernetes provides out-of-the-box audit logging of security-related events in your cluster. You still need to collect records from various applications and monitor their status in a central location.

Kubernetes Resource Requests and Limits

In addition to scheduling and running containers, Kubernetes can limit container resource consumption in terms of CPU and memory. Resource requests and limits, which are largely ignored by Kubernetes users, are important for two reasons:

● Security—if pods and namespaces are not constrained, even a single container with a security weakness can access sensitive data in the cluster.
● Cost—when more resources are requested than are actually used, the node runs out of available resources. When autoscaling is enabled, the node pool grows, and new nodes inevitably increase cloud bills.

When resource requests are properly calculated and allocated, the entire cluster runs efficiently in terms of CPU and memory. Additionally, if resource limits are in place, a vulnerable application will limit resource usage if abused by an attacker. For example, without resource limits, a malicious container could consume almost all of a node’s resources, rendering your application unusable.

How Kubernetes Lens Improving Operational Awareness and Security of Kubernetes Clusters

Kubernetes Lens offers solutions to common challenges in Kubernetes, including:

● Configuring and deploying resources
● Troubleshooting errors in real-time
● Monitoring and managing clusters

Cluster Management

Managing Kubernetes clusters is easier with Lens because you can maintain cluster-specific context while working on multiple clusters. Lens organizes the entire cluster and provides metrics to inform editing decisions. You can add clusters to Lens by pointing the local or online kubeconfig file to Kubernetes Lens. You can then inspect all resources running in your clusters.

Metrics and Visualization

Lens provides Prometheus metrics with user-specific RBAC, so users can only see the allowed information. When configuring a Prometheus instance in Lens, it can display cluster metrics. Lens automatically detects the metrics and provides visualizations. You can preview Kubernetes manifests before applying them.

Prometheus provides real-time visualizations of usage metrics like memory, CPU, memory, and networking built into the Lens dashboard. Kubernetes Lens integrates with Helm to make installing and managing Helm charts and releases easier.

Lens Extensions

You can add new features or visualizations to accelerate the development workflow for any service that integrates with Kubernetes. You can also create custom extensions using Lens APIs to add new object details and UI elements. Extensions are publishable to npm, with a tarball link for reference by the Lens install screen.

CLI and GUI

You can execute kubectl command lines using the built-in CLI. Lens also lets you manage Kubernetes via a graphical user interface (GUI), which is faster and easier than the CLI.

The GUI lets you:

● Add clusters manually—Browse through the kubeconfig files to identify local files.
● Group clusters—Create workgroups based on how you interact with the clusters.
● Visualize the state of Kubernetes objects—Easily identify and fix issues in pods, deployments, etc.

Cluster Connect

Sharing access to Kubernetes clusters can be difficult, especially when multiple providers require specific tools. You have to access kubectl files and make them work before connecting to the target network. Often, a VPN is necessary to stay in the provider’s network.

Lens leverages Cluster Connect to enable shared cluster access while maintaining security. You can use Kubernetes Lens Spaces to send and receive access invitations to other clusters. You access clusters by downloading the Cluster Connect agent that connects to the clusters with end-to-end encryption. You don’t need a VPN.

Conclusion

In this article, I explained the basics of Kubernetes Lens and how it can boost Kubernetes security:

● Cluster management—Lens organizes the entire cluster and provides metrics to inform editing decisions.
● Metrics and visualization —Lens provides Prometheus, which shows real-time visualizations of usage metrics.
● Lens extensions—You can add new features or visualizations to accelerate the development workflow for any service that integrates with Kubernetes.
● CLI and GUI—You can execute kubectl command lines using the built-in CLI. Lens also lets you manage Kubernetes via a graphical user interface (GUI), which is faster and easier than the CLI.
● Cluster Connect—Lens leverages Cluster Connect to enable shared cluster access while maintaining security.

I hope this will be useful as you leverage Kubernetes Lens to improve Kubernetes security.

Gilad David Mayaan

Gilad David Maayan is a technology writer who has worked with over 150 technology companies including SAP, Samsung NEXT, NetApp and Imperva, producing technical and thought leadership content that elucidates technical solutions for developers and IT leadership.

Gilad David Mayaan has 53 posts and counting. See all posts by Gilad David Mayaan