Kubescape

Kubescape Node Agent Now Works on GKE Autopilot Clusters

slashben — Thu, 15 May 2025 00:00:00 +0000

Kubescape Node Agent Now Works on GKE Autopilot Clusters

The Kubescape community is excited to share that Kubescape’s node agent now supports GKE Autopilot clusters, thanks to Google Cloud’s newly introduced Workload Allowlisting capability.

This is a significant milestone that opens the door for full runtime observability and Kubernetes-native security on fully-managed GKE environments.

A Quick Background: Why It Wasn’t Possible Before

Historically, GKE Autopilot enforced strict constraints on workloads requiring privileged permissions, like those needed by Kubescape’s node agent. This made it impossible to get visibility into system-level activity — something many security-conscious users rely on for runtime protection, vulnerability tracing, and compliance enforcement.

But with the rollout of Google Cloud’s Autopilot partner workload support, this has changed. Users can now explicitly allow trusted workloads through a declarative AllowlistSynchronizer configuration. Kubescape is among the first open-source tools to make use of this capability.

👉 Learn more about Google Cloud’s Allowlisting mechanism

Why It Matters

By running Kubescape’s node agent on GKE Autopilot, users can finally get deep runtime visibility and Kubernetes-native security without needing to manage the underlying nodes themselves.

This means:

Access to real-time anomaly detection from inside your container and host environment
Support for seccomp and network policy insights, including smart suggestions
Seamless vulnerability prioritization with in-use and reachable package analysis
Compliance scanning and misconfiguration detection with behavioral remediation insights

How to Enable It

Make sure your cluster is running GKE Autopilot version 1.32.2-gke.1652000 or newer
Use Kubescape Helm chart version 1.27.5 or newer
Create an AllowlistSynchronizer object to sync the allowlist for Kubescape:

yamlapiVersion: auto.gke.io/v1kind: AllowlistSynchronizermetadata: name: kubescape-allow-listspec: allowlistPaths: - ARMO/armo-kubescape-node-agent/1.27/*

Apply it to your cluster:

bashkubectl apply -f kubescape-allowlist.yaml

Confirm it's synced:

bashkubectl get WorkloadAllowlist

Install Kubescape with Helm:

bashhelm upgrade --install kubescape kubescape/kubescape-operator \ --set nodeAgent.gke.allowlist.enabled=true \ --set nodeAgent.gke.allowlist.name=armo-kubescape-node-agent-1.27

Verify the node agent is running:

bashkubectl get pods -n kubescape

What’s Next?

Kubescape continues to evolve with community input and contributions. Supporting GKE Autopilot is part of a broader goal: making Kubernetes security accessible, powerful, and fully open — no matter where or how you run your workloads. We're excited to see this feature land and look forward to seeing what the community will build with it.

If you are missing a feature or have feedback, please let us know on GitHub or Discussions.

Introducing a Visual Way to Explore Kubernetes Security: the Kubescape Plugin for Headlamp

oshratn — Wed, 30 Apr 2025 00:00:00 +0000

Introducing a Visual Way to Explore Kubernetes Security: the Kubescape Plugin for Headlamp

Managing security in Kubernetes can feel like navigating a maze. With countless vulnerabilities, policies, and best practices to juggle, it’s easy for developers to get overwhelmed and hard to know where to start. Reporting on your security posture adds another layer of complexity-especially when many open-source tools are highly technical and not user-friendly for the average Kubernetes user.

That’s where Headlamp comes in. Headlamp is an open-source Kubernetes UI that provides an intuitive, visual way to explore and manage your clusters. It helps users of all experience levels understand what’s happening in their environments, surfacing insights that would otherwise require deep command-line expertise.

Announcing the Kubescape Plugin for Headlamp

We’re excited to share the new Kubescape plugin for Headlamp, a game-changer for anyone looking to simplify Kubernetes security management! As Viktor Farcic noted at KubeCon NA 2024, “What Kubescape needs is a GUI.”

This plugin bridges the gap between robust security scanning and accessible, actionable insights. By reading reports from Kubescape, it brings security and compliance data directly into the Headlamp interface. Now, you can view and manage your cluster’s security posture without switching between tools or deciphering command-line outputs.

What Can You Do with the Kubescape Plugin?

The Kubescape plugin enhances Headlamp with dedicated pages and features for:

Configuration Scanning: Instantly see compliance and configuration scan results, making it easier to spot and address misconfigurations.
Vulnerability Scanning: Get clear insights into vulnerabilities and CVEs (Common Vulnerabilities and Exposures) affecting your clusters and images.
Network Policies Viewer: Visualize and manage network policies to strengthen your cluster’s security boundaries.
Admission Policies Playground: Test and validate admission policies as recommended by Kubescape. The playground leverages WASM to evaluate CEL expressions in real-time, empowering you to experiment safely.
Multi-Tenant Support: Enjoy namespace-specific views for multi-tenant clusters, so teams can focus on what matters to them.

![Source: Kubescape plugin for Headlamp PoC](headlamp-compliance.png){ width="600" }

Source: Kubescape plugin for Headlamp PoC

Getting Started: How to Install the Kubescape Plugin

Ready to try it out? Here’s a quick guide to getting the Kubescape plugin up and running in Headlamp.

Kubescape

Follow the Kubescape operator installation procedure and make sure you enable continuousScan --set capabilities.continuousScan=enable and network observability --set capabilities.networkPolicyService=enable.

Headlamp Desktop App

If you are using Headlamp as a desktop app (Windows, Mac, or Linux), go to the Plugin Catalog (available from the sidebar when in the home view), then look for the Kubescape plugin from the list, click it to see its details, and then click the install button. After the plugin is installed, use the notification to reload Headlamp.

Headlamp Web app

If you are deploying Headlamp as a web app (running in-cluster), you need to add the plugin files to the plugins folder of the headlamp-server. The Helm chart of Headlamp allows you to add an init container that will download the plugin. Please check the instructions at Kubescape plugin for Headlamp.

Acknowledgements & Future

A huge thanks to the Headlamp team for providing an extensible multi-cluster K8s dashboard experience, and Kubescape team for building such a powerful tool for security posture management.

The Kubescape plugin for Headlamp is currently in beta and ready for you to test. We’re eager to hear your feedback and ideas let us know what you think!

With this new integration, Kubernetes security is more accessible than ever. Dive in, explore your clusters visually, and take control of your security posture today!

Kubescape Now Supports CIS Kubernetes Benchmark v1.10

oshratn — Thu, 06 Mar 2025 00:00:00 +0000

Kubescape Now Supports CIS Kubernetes Benchmark v1.10

We're happy to announce that Kubescape has upgraded it's securiy controls to align with the latest CIS Kubernetes Benchmark v1.10. Thus, helping you strengthen your cluster security posture with industry-recognized standards.

What's New in CIS Kubernetes Benchmark v1.10?

The CIS Kubernetes Benchmark v1.10.0 delivers significant enhancements to address the evolving security landscape:

Comprehensive security recommendations tailored to counter emerging threats
Broader component coverage across your Kubernetes infrastructure
Clearer control documentation to improve implementation accuracy

Key Improvements Include:

Automated Assessment Content (AAC): Full integration with AAC and expanded compatibility with Kubernetes versions 1.30 and 1.31, streamlining your compliance verification process.

Enhanced Recommendations: 27 recommendations have undergone thorough revision to their audit and remediation procedures.

Upgraded Cryptographic Standards: Modernized cipher specifications that enforce more robust encryption requirements

Refined Security Context Variables: Updated terminology around 'securityContext' variables to facilitate proper security configuration

How Kubescape Empowers Your Compliance Journey

With Kubescape's implementation of CIS v1.10, you can:

Perform detailed compliance assessments against the latest benchmark
Quickly identify compliance gaps between previous and current requirements
Follow clear, practical remediation guidance to address vulnerabilities

Take Action Today

Ready to strengthen your Kubernetes security posture? Try Kubescape now to run your first CIS v1.10 compliance scan. See how your clusters measure up against the latest security standards.

Our community forums and documentation are available to support your implementation journey. Join us in making Kubernetes environments more secure, one cluster at a time.

Join the Kubescape community

We welcome your feedback and ideas for improvement. We hold community meetings on Zoom, on the first Tuesday of every month, at 14:00 GMT.

Thanks to all our contributors! Check out our CONTRIBUTING file to learn how to join them.

Feel free to pick a task from the good first issue list and suggest a design
Open an issue: we aim to respond to all issues within 48 hours
Join the CNCF Slack and then our users or developers channel
Don’t forget to leave a star on our repository: it means the world to us!

The Kubescape project follows the CNCF Code of Conduct.

Kubescape's Journey to Incubation: Celebrating our Community and a Secure Kubernetes Future

oshratn — Tue, 25 Feb 2025 00:00:00 +0000

Kubescape's Journey to Incubation: Celebrating our Community and a Secure Kubernetes Future

We are thrilled to share that Kubescape has officially been accepted as a CNCF Incubating project. This milestone is a significant achievement for the project. Kubescape began in 2021 as a fun project to scan for compliance with NSA-CISA Kubernetes hardening guidelines. What started as a security scanner, helping Devlopers and DevOps teams implement better Kubernetes security practices, evolved into a full security platform. Still helping security Kubernetes environments 😉

From the very beginning, Kubescape was built with the cloud-native community in mind. It started as a simple CLI tool designed to check cluster configurations against NSA-CISA Kubernetes Hardening Guidance. Over time, with the support of a rapidly growing community, Kubescape has evolved into one of the most complete open-source solutions for Kubernetes security. We are proud to have contributed to its development alongside contributors in the Kubescape community, and to see so many adopters leveraging Kubescape in their day-to-day workflows.

The Kubescape community has been a driving force behind this success. It’s not just the maintainers and contributors that we celebrate but the many users who have adopted and integrated Kubescape into their environments. Companies like Intel, AWS, Bitnami, ARMO, and Energi Danmark are just a few of the organizations using Kubescape. Some use Kubescape to secure their Kubernetes clusters. Others leverage it for educational purposes. Other use cases that go beyond what we imagined when we made our first commit. We are grateful for the trust that these adopters, along with hundreds of others, have shown in Kubescape.

As we look toward the future, the Kubescape project is poised for even greater growth. Our roadmap is not just about adding more features, but about continuing to improve usability and optimizing the performance of the platform. We are excited to welcome new contributors and users into the fold as we continue on the hamster-wheel of Kubernetes security.

The Kubescape community is our foundation, and we are committed to fostering a collaborative and inclusive environment where all contributions are valued. With the incredible support of the Cloud Native Computing Foundation (CNCF) and the broader Kubernetes community, we are determined to demonstrate sustained growth, strong governance, and broad adoption on our journey toward CNCF graduation. We believe that this is just the beginning, and we are eager to see where the future takes us.

Together, with the support of these vibrant communities, Kubescape will continue to evolve and grow, offering better security, deeper insights, and an ever-expanding set of features. We invite everyone - whether you are an adopter, contributor, or newcomer - to join us in shaping the future of Kubernetes security.

Join the Kubescape community

We welcome your feedback and ideas for improvement. We hold community meetings on Zoom, on the first Tuesday of every month, at 14:00 GMT.

Thanks to all our contributors! Check out our CONTRIBUTING file to learn how to join them.

Feel free to pick a task from the good first issue list and suggest a design
Open an issue: we aim to respond to all issues within 48 hours
Join the CNCF Slack and then our users or developers channel
Don’t forget to leave a star on our repository: it means the world to us!

The Kubescape project follows the CNCF Code of Conduct.

CEL and Kubescape: Transforming Kubernetes Admission Control

oshratn — Sun, 04 Aug 2024 00:00:00 +0000

CEL and Kubescape: Transforming Kubernetes Admission Control

Introduction

Admission control is a crucial part of the Kubernetes security, enabling the approval or modification of API objects as they are submitted to the server. It allows administrators to enforce business logic or policies on what objects can be admitted into a cluster. Kubernetes RBAC is a scalable authorization mechanism, but lacks the fine grained control over different Kubernetes objects. This creates the need for another layer of control which is Admission Policies. To enhance this capability, Kubernetes introduced dynamic admission control webhooks in version 1.7. Despite its benefits, adoption of admission controllers for policy enforcement faces challenges, namely scalability challenges. Maintaining webhook infrastructure as a production service is complex, and handling webhook failures can either reduce cluster availability or undermine policy enforcement. Additionally, the network hop and evaluation time involved in admission control can introduce significant latency, particularly in "serverless” environments where pods are rapidly spun up in response to network requests.Kubernetes 1.30 has brought a significant development to the table with the introduction of the Common Expression Language (CEL) for admission control. This new feature offers an alternative to validating admission webhooks for enforcing custom policies, with a focus on policy enforcement capabilities and CRD validation rules that were previously in beta.The introduction of CEL for admission control enables administrators to define complex and tailored policies, improving the overall security of Kubernetes clusters. This is significant for organizations with complex security requirements, as it allows them to create finely tuned policies that precisely match the security needs of different applications and environments.In this blog post, we'll explore the benefits of Validating Admission Policies, its goals, and how Kubescape maintainers have leveraged it to create a robust and precise cel-admission-library.

Validating Admission Policies Short Primer

The first part of this blog post explains what ValidatingAdmissionPolicies are and explain why they were added and their benefits. If you have been following the development of KEP-3488, through alpha in Kubernetes 1.26, beta in Kubernetes 1.28 and GA in the aforementioned Kubernetes 1.30 and you just want to get started with them, feel free to skip to Using the Kubescape CEL library in your cluster.If you are reading this and thinking: “I already have OPA Gatekeeper or Kyverno up and running to solve this”.

![Admission control meme](/assets/admission-meme.jpg){ width="600" }

Please join us to get a better understanding of this Kubernetes native feature, what it seeks to achieve and what the benefits of using it are. Also, take into account that this functionality will become the de-facto standard, similar to what happened with OpenTelemetry and GatewayAPI.

Introduction to ValidatingAdmissionPolicies

ValidatingAdmissionPolicies are: A declarative, in-process alternative to validating admission webhooks. They use the Common Expression Language (CEL) to define the policies.

They consist of two main resources:

ValidatingAdmissionPolicy describes the policy logic
ValidatingAdmissionPolicyBinding links the above policy to the resources it applies to

The Goals of Validating Admission Policies

The Kubernetes team has established specific goals for Validating Admission Policies to guarantee that it aligns with the community's requirements.:

Alternative to Webhooks: Validating Admission Policies aims to provide an alternative to webhooks for the majority of validating admission use cases.
In-Tree Extensions: The feature intends to offer the in-tree extensions required to build policy frameworks for Kubernetes without relying on webhooks.
Efficient Type Checking: Validating Admission Policies aims to make good use of CEL type checking, even when considering that CRD schemas can be changed at any time, and not all fields of built-in types exist in older Kubernetes versions.
Polyfill Implementation: The Kubernetes organization plans to provide a polyfill implementation that offers enhancement functionality to Kubernetes versions where this feature is not available.
Core Functionality as a Library: Validating Admission Policies intends to provide core functionality as a library, enabling use cases like GitOps, CI/CD pipelines, and auditing to run the same CEL validation checks as the API server.Having said that, Polyfill Implementation and Core Functionality as a Library (points 4 and 5 above) have yet to be implemented, and we should keep an eye out for them in the future.

The Benefits of Validating Admission Policies

The Validating Admission Policies functionality offers several advantages over webhooks, making it a more attractive choice for policy enforcement:

No Infrastructure Requirement: Validating Admission Policies doesn't require you to build infrastructure to host the admission webhook, simplifying the process.
Reduced Latency: By eliminating the need for an additional network hop, Validating Admission Policies helps reduce latency, ensuring smoother and faster operations.
Increased Reliability and Scalability: In-process webhooks used by Validating Admission Policies are less prone to failure than webhooks with extra infrastructure dependencies, enhancing the overall reliability. Beyond this, the in-process admission decision makes the Kubernetes control plane more scaleable since it doesn't depend on an external component.
Lower Operational Burden: Cluster administrators responsible for the observability, security, and release/rollout/rollback plans for webhooks will experience a lower operational burden with Validating Admission Policies.

Kubescape's Cel-Admission-Library

When Validating Admission Policies was first introduced in beta in version 1.26, the maintainers of Kubescape were eager to utilize it. They created the cel-admission-library based on Kubescape controls originally written in Rego. The library includes the following 27 admission controls:

Using the Kubescape CEL library in your cluster

This section originally appeared in Kubernetes Validating Admission Policies: A Practical Example on the Kubernetes blog.Policies are provided as Kubernetes objects, which are then bound to certain resources by a selector.Minikube is a quick and easy way to install and configure a Kubernetes cluster for testing. To install Kubernetes v1.26 with the ValidatingAdmissionPolicy feature gate enabled:bash minikube start --kubernetes-version=1.30.2 --extra-config=apiserver.runtime-config=admissionregistration.k8s.io/v1alpha1 --feature-gates='ValidatingAdmissionPolicy=true'

To install the policies in your cluster:```bash

Install configuration CRD

kubectl apply -f https://github.com/kubescape/cel-admission-library/releases/latest/download/policy-configuration-definition.yaml

Install basic configuration

kubectl apply -f https://github.com/kubescape/cel-admission-library/releases/latest/download/basic-control-configuration.yaml

Install policies

kubectl apply -f https://github.com/kubescape/cel-admission-library/releases/latest/download/kubescape-validating-admission-policies.yaml```

To apply policies to objects, create a ValidatingAdmissionPolicyBinding resource. Let’s apply the above Kubescape C-0017 control to any namespace with the label policy=enforced:```bash

Create a binding

kubectl apply -f - <<EOTapiVersion: admissionregistration.k8s.io/v1alpha1kind: ValidatingAdmissionPolicyBindingmetadata: name: c0017-bindingspec: policyName: kubescape-c-0017-deny-mutable-container-filesystem matchResources: namespaceSelector: matchLabels: policy: enforcedEOT

Create a namespace for running the example

kubectl create namespace policy-examplekubectl label namespace policy-example 'policy=enforced'```

Now, if you attempt to create an object without specifying a readOnlyRootFilesystem, it will not be created.```bash

The next line should fail

kubectl -n policy-example run nginx --image=nginx --restart=Never```

The output shows our error:bash The pods "nginx" is invalid: : ValidatingAdmissionPolicy 'kubescape-c-0017-deny-mutable-container-filesystem' with binding 'c0017-binding' denied request: Pods having containers with mutable filesystem not allowed! (see more at https://kubescape.io/docs/controls/c-0017/)

Configuration

Policy objects can include configuration, which is provided in a different object. Many of the Kubescape controls require a configuration: which labels to require, which capabilities to allow or deny, which registries to allow containers to be deployed from, etc. Default values for those controls are defined in the ControlConfiguration object.To use this configuration object, or your own object in the same format, add a paramRef.name value to your binding object:bashapiVersion: admissionregistration.k8s.io/v1alpha1kind: ValidatingAdmissionPolicyBindingmetadata: name: c0001-bindingspec: policyName: kubescape-c-0001-deny-forbidden-container-registries paramRef: name: basic-control-configuration matchResources: namespaceSelector: matchLabels: policy: enforced

Conclusion

The introduction of Validating Admission Policies in Kubernetes 1.30 is a game-changer, offering a more efficient and reliable way to enforce custom policies. With its numerous benefits and well-defined goals, Validating Admission Policies is set to make a significant impact on the Kubernetes landscape. The cel-admission-library created by Kubescape maintainers is a testament to the potential of this new feature, and we encourage you to try it out using Kubescape.We are happy to contribute this library to the Kubernetes community and will continue to develop it for Kubescape and Kubernetes users alike. We hope it becomes useful, either as something you use yourself, or as examples for you to write your own policies.As for the validating admission policy feature itself, we are very excited to see this native functionality generally available on Kubernetes.

Enhancing Bitnami Helm Charts Security: A Kubescape Case Study

agarcia-oss — Tue, 16 Jul 2024 00:00:00 +0000

Enhancing Bitnami Helm Charts Security: A Kubescape Case Study

Introduction

CVEs get all the press when it comes to secure software supply chain, and for good reason: vulnerabilities in open source code cost the global economy billions of dollars per year. However, even the most secure applications with the best supply chain provenance can be accidentally misconfigured in such a way that leaves insidious security holes lurking in your environment.

Much of the value that Bitnami adds in packaging open source software is in the configuration. Our Helm charts, for example, are loved because they are very thorough in exposing the “knobs and dials'' that are unique to each open source application you deploy to Kubernetes. Developers and IT admins alike also appreciate that we are constantly checking and improving the default configuration we ship in our charts to ensure they are as secure as possible. That’s why, when we recently discovered an open-source Kubernetes security project called Kubescape, we saw an opportunity to thoroughly check our software against industry best practices and close any gaps that existed.

Why did we choose Kubescape?

Kubescape is a flexible tool that analyzes Kubernetes software in different ways: it can check Helm charts and artifacts like Dockerfiles in your source code repository, or it can scan the software running in your Kubernetes clusters. We decided to try Kubescape because it covers a wide variety of best practices. Its controls can be tailored to meet specific requirements, ensuring a fine-tuned approach to security. The tool identifies misconfigurations by comparing OSS configurations to industry recognized security best practices from organizations such as NSA-CISA and CIS.

When we ran Kubescape against Bitnami and Tanzu Application Catalog Helm charts, it identified meaningful changes we could make to further secure our software. This discovery led us to include Kubescape in our automated build pipelines to programmatically implement preventative, detective, and corrective measures against any security or quality defects that may be introduced into our software.

We now use Kubescape in several ways to improve our overall security posture and deliver a great user experience for our community users and Tanzu Application Catalog customers.

We continuously implement security improvements based on Kubescape's risk analysis and security compliance scanning.
We created an Open Source Health Assessment service where users can upload their Kubescape scanning reports and receive actionable insights.
We integrated Kubescape into the Bitnami catalog through a Kubescape CLI image, enabling users to initiate OSS health assessments locally using a simple Docker run command.

Bitnami Helm chart security improvements

So what were those meaningful improvements we could make to our catalogs, thanks to Kubescape? Here are a few of the most important:

Eliminated group root dependency: One of the major improvements was enabling containers to function without group root. Previously, Bitnami charts used user 1001 and group root (following OpenShift standards). The new changes made 1001 the default runAsGroup, eliminating the need for group root and improving security.
Configured immutable filesystems: Using immutable filesystems is a mandatory requirement of security checklists such as NSA or MITRE. This configuration helps enforce an immutable infrastructure strategy; the container only needs to write on the mounted volume that persists the state. An immutable root filesystem is also capable of preventing malicious binaries from writing to the host system.
Significantly reduced misconfigured resources: The OSS health assessment report showed that after implementing its suggested improvements, the percentage of misconfigured resources dropped from 54.55% to 17.39%. This indicates a substantially better security posture for Bitnami Helm charts. The improved charts now address common security concerns such as unnecessary privilege escalation rights, root privileges granted to applications, and issues with ingress and egress configurations.
Improved compliance with security frameworks: Kubescape's ability to detect compliance with multiple frameworks (including NSA-CISA, MITRE ATT&CK®, and the CIS Benchmark) helped ensure that Bitnami Helm charts align better with industry-standard security practices.
Enhanced OpenShift compatibility: When implemented, the configuration changes suggested by Kubescape enabled Bitnami Helm charts to function within OpenShift's restricted-v2 Security Context Constraints (SCC), which was not possible before.

These enhancements further aligned Bitnami and Tanzu Application Catalog Helm charts with industry standards and provide users with greater confidence in their deployments.

For organizations looking to assess their own Kubernetes environments, the VMware Tanzu OSS Health Assessment tool, which integrates Kubescape, offers comprehensive reports on misconfigurations and security vulnerabilities within OSS dependencies. It also provides insights using your own data about how upgrading from the community Bitnami Application Catalog to the enterprise Tanzu Application Catalog can save you time and effort in improving your security posture.

![Tanzu OSS Assessment](oss.png){ width="600" }

VMware Tanzu OSS Health Assessment

Final considerations

This case study demonstrates how leveraging tools Kubescape can significantly enhance the security of Helm charts and, by extension, the overall security posture of Kubernetes deployments. As the Kubernetes ecosystem continues to evolve, such initiatives will play a crucial role in maintaining the balance between innovation and security in cloud-native environments.

Patching Image Vulnerabilities with Kubescape & Copa

anubhav06 — Sun, 14 Jul 2024 00:00:00 +0000

Patching Image Vulnerabilities with Kubescape & Copa

In this article, we’ll learn how can we patch vulnerabilities in our container images using Kubescape & Copa.

What is Kubescape? 🔍

![image-1](image-1.png){ width="200" }

Kubescape is an open-source Kubernetes security platform. It includes risk analysis, security compliance, and misconfiguration scanning. Targeted at the DevSecOps practitioner or platform engineer, it offers an easy-to-use CLI interface, flexible output formats, and automated scanning capabilities. It saves Kubernetes users and admins precious time, effort, and resources.Kubescape is a Cloud Native Computing Foundation (CNCF) incubating project.

What are Image Vulnerabilities? 💀👾

![image-2](image-2.gif){ width="600" }

Container images can contain security vulnerabilities that can be exploited by attackers. These vulnerabilities can include outdated software versions, unpatched vulnerabilities, or weak encryption protocols. Container image vulnerabilities can be identified through vulnerability scanning tools that analyze container images and their dependencies.

On a broad scale, we can divide image vulnerabilities into 2 categories:

OS-Level Vulnerability: These are vulnerabilities because of the underlying OS in your image. It is unrelated to your application code. For example: You are using alpine as the base image in your container image.
Application-Level Vulnerability: These are vulnerabilities due to the source code of your application. For example: A SQL injection error in your code or an outdated python library/package which you are using in your software.

What is Image Patching? 🩹

![image-3](image-3.gif){ width="600" }

Kubescape can “patch” or “fix” the vulnerabilities in your image with the help of Copa, by updating the packages to their applicable fixed-in versions.

Below is the architecture diagram of how Copacetic can patch images:

![image-4](image-4.png){ width="600" }

Architecture of copa

Parses the needed update packages from the container image’s vulnerability report produced by a scanner like Kubescape.
Obtains and processes the needed update packages using the appropriate package manager tools such as apt, apk, etc.
Applies the resulting update binaries to the container image using buildkit.

How does it work? ⚒️🤔

![image-5](image-5.gif){ width="500" }

Below is a small flowchart I made, to help you understand the Kubescape image patching process:

![image-6](image-6.png){ width="600" }

Kubescape image patching process

The user inputs the image which needs to be patched
Kubescape scans the image for vulnerabilities using Grype as its engine
Kubescape then uses the scanned image information to analyze the vulnerabilities and passes the report further to the patching process.
Kubescape then reads the vulnerability report and patches the applicable vulnerable packages in the image using Copacetic.
Kubescape re-scans the patched image for vulnerabilities using Grype as its engine.
In the CLI output, we have the vulnerability summary report and a patched image exported to our local Docker Server

Demo 🧑‍💻 👀

![image-7](image-7.gif){ width="600" }

Let’s see the working in action.

Run the following command to scan the “nginx:1.23” image for vulnerabilities:

bashkubescape scan image nginx:1.23

We get the following output:

![image-8](image-8.png){ width="600" }

Kubescape image scan output

As we can see there are 265 vulnerabilities which Kubescape has found in this image.

Let’s run the patch command on this image now:

bashkubescape patch -i nginx:1.23

We get the following output:

![image-9](image-9.png){ width="600" }

Kubescape image patch output

As we can see, we have a new image called “nginx:1.23-patched” and the total vulnerabilities has reduced to just 198 from 265!

Now, you might wonder — Why weren’t all the vulnerabilities patched and why do we still have 198 vulnerabilities which are not fixed? The answer lies in how image scanning and image patching works.

If you are familiar with any of the popular image scanning software like Grype/Trivy/Docker etc., it lists the following:

The particular package in your image which has a certain vulnerability. For example: libcurl4
The current version of the package which is being used in your image. For example: 7.74.0–1.3+deb11u7
The package version in which the vulnerability has been fixed. For example: 7.74.0–1.3+dev11u10

If we update the package to the fixed-in version, the vulnerability will be fixed. However, there are certain packages which do not have a fix known yet. These are the vulnerabilities which security researchers are actively working on to find a fix. Therefore, these left vulnerabilities are those vulnerabilities which no one has a fix yet for.

Conclusion

We needed the ability to patch containers quickly without going upstream for a full rebuild. As the window between vulnerability disclosure and active exploitation continues to narrow, there is a growing operational need to patch critical security vulnerabilities in container images so they can be quickly redeployed into production. Kubescape & Copa can help you patch those OS-level vulnerabilities in your image quickly.

If you are interested in knowing how I added this integration & support between Kubescape & Copa, checkout my other story.

Kubescape: The 1st Open Source project to support VEX Generation

oshratn — Thu, 07 Dec 2023 00:00:00 +0000

Kubescape: The 1st Open Source project to support VEX Generation

Introduction

Vulnerability Exploitability eXchange (VEX) is a vulnerability document designed to complement a Software Bill of Materials (SBOM). It informs users of a software product about the applicability of one or more vulnerability findings.

Security scanners will detect and flag components in software that have been identified as being vulnerable. Often, software is not necessarily affected as signaled by security scanners for many reasons.

For example:

The vulnerable component may have been already patched,
The vulnerable component may not be present
The vulnerable code is not actually executed.

The extreme transparency brought by SBOMs into how software is composed will most likely increase the number of these kinds of false positives, requiring an automated solution to avoid an explosion in the false positive rate of security scans. Hence VEX.

Using VEX is a way to turn down the noise, and give security practitioners a good strong signal, a scanner may consume VEX data from the software supplier. However, it is time-consuming to write a VEX document and since it is imperative these documents stay current, it is a never ending task.The solution to this must come via automation.

!!! note "Are you running Kubescape? Want to help us get to incubation in the CNCF? Please help us by filling in our three-question survey!"

VEX and vulnerability scanners

The adoption and support of VEX documents represent a major shift in how security practitioners address software vulnerabilities. Primarily, VEX is designed to assist these professionals in determining which vulnerabilities require immediate attention and remediation. This targeted approach is crucial in a landscape where prioritizing security efforts is overwhelming due to the sheer volume of reported vulnerabilities.

Grype and Trivy are two popular open source vulnerability scanners. Their newest versions allow them to ingest VEX documents. Thus, giving clearer results of vulnerability scans, with a better signal-to-noise ratio. Leading to more actionable results, since users of VEX based scans have a good understanding of the vulnerabilities that can hurt them now.

However, one big stumbling block remained - the sourcing of reliable and accurate VEX documents.

The ideal providers of VEX documents are the software vendors themselves. They possess the most in-depth understanding of their products and are best positioned to evaluate which vulnerabilities are genuinely exploitable. Despite this, expecting a swift and universal adoption of this practice appears optimistic, particularly in the short term. The creation of VEX documents demands considerable effort from software vendors. While the initial technical evaluation may be something that can be achieved, VEX documents need to be continuously updated to reflect the evolving threat landscape. This requires considerable effort from the software vendors.

This need poses an even greater challenge for open-source projects, which often operate with limited resources and rely heavily on community contributions. The expectation that these projects will regularly produce detailed VEX documents is probably unrealistic, at least in the near future. Therefore, while the concept of VEX documents is a step in the right direction for cybersecurity, its practical implementation, especially across diverse software ecosystems, remains complex.

Enter Kubescape

he Kubescape project, a Kubernetes security platform, is a CNCF incubating project. It has made significant progress in cybersecurity with its latest feature: the generation of reliable Vulnerability Exploitability eXchange (VEX) documents. Kubescape is the first project to provide this functionality. One of Kubescape's functions is to scan Kubernetes workload images for vulnerabilities, a task crucial for monitoring the security posture of containerized environments.

A standout feature of Kubescape is its "Reachability" capability. This functionality uses eBPF technology to detect which software packages are loaded into memory from a container image during runtime. It then automatically categorizes vulnerabilities associated with unloaded packages as unreachable. This distinction is crucial as it distinguishes between theoretical vulnerabilities and those that pose an actual risk in the given container environment.

Leveraging this reachability feature, Kubescape Operator (version 1.16.2 and up), has started producing VEX documents and storing them as Kubernetes API objects. This approach is a game-changer in vulnerability management. It involves marking reachable vulnerabilities as "affected" and unreachable ones as "not affected," providing clear and actionable signaling for vulnerability prioritization and management.

Using the information it generates, Kubescape can also produce meaningful VEX documents for the images running in a Kubernetes cluster. It flags (logically) vulnerabilities as "affected" based on whether the package that the vulnerability belongs to is loaded into the memory during the runtime of the container. Packages not loaded into memory are left as "not affected" when not loaded to the memory.

The VEX output of Kubescape uses the OpenVEX specification, described below.

These Kubernetes API objects containing VEX information can be easily downloaded and integrated into workflows that use Trivy or Grype (or any other tool that supports OpenVEX). This integration simplifies the vulnerability management process significantly. In many cases, over 80% of the vulnerabilities in an image are marked as "not affected," thus saving practitioners substantial time and effort.

Generating VEX Documents with Kubescape

A prerequisite to using Kubescape to generate a VEX document is that you install the Kubescape operator. For details, you can check out Kubescape documentation or the Kubescape GitHub repo.

To produce a VEX document, Kubescape needs to see a workload running the given image from its start. In other words, it needs to see containers from start.

Now that all the prerequisites have been fulfilled, the following steps will lead to the auto-generation of a VEX document.

The following example uses a NGINX deployment to demonstrate the generation of a VEX document.

| kubectl apply -f https://k8s.io/examples/application/deployment.yaml || -- |

Wait for the VEX objects using this command:

| kubectl -n kubescape get openvulnerabilityexchangecontainers.spdx.softwarecomposition.kubescape.io -w || -- |

It takes 2 minutes of monitoring time (by default) to produce the first version of the VEX for the image in the above deployment, it can take more if the processing queue is busy.

To get the VEX document as a JSON file locally you can use jsonpath to extract the .spec field that contains the VEX itself:

| kubectl -n kubescape get openvulnerabilityexchangecontainer $(kubectl -n kubescape get openvulnerabilityexchangecontainer -o jsonpath='{.items[0].metadata.name}') -o jsonpath='{.spec}' > nginx.json || -- |

this stores the JSON format in nginx.json

Here is an example to see how many vulnerabilities are affected:

| $ jq "." nginx.json | grep -c "\"affected\""

| 58 || -- |

$ jq "." nginx.json | grep -c "\"not_affected\""

| 338 || -- |

Now that we have a VEX document in hand, how do we feed it to a scanner?

Let’s take Grype as an example scanner:

Grype will take into account the VEX information when calculating results for the image nginx:1.14.2 . Grype will ignore all vulnerabilities that were marked as "not_affected".

Note: the following flow was run and tested on Grype 0.71.0

Here is how to run it:

| grype nginx:1.14.2 --vex nginx.json || -- |

This produces the following output (note the 338 ignored vulnerabilities!):

![VEX Output](output.png){ width="600" }

VEX output via Grype

VEX formats

While VEX can be applied to any software, it is very effective within Kubernetes environments to communicate the exploitability of vulnerabilities in containerized applications. As such, it is now gaining traction in the open source and cloud-native communities.

There are three main formats for VEX today:

CycloneDX VEX:

Integrates seamlessly with the CycloneDX Software Bill of Materials (SBOM) standard.
Leverages existing SBOM data for product and component identification.
Provides a dedicated VEX BOM specifically focused on vulnerability exploitability.
Allows independent VEX documents for dynamic updates without affecting the SBOM.
Offers tight integration with CycloneDX tools and BOM-Link for deep linking.
Works well with other SBOM formats like SPDX, but with less tight integration.

CSAF VEX:

Follows the Common Security Advisory Framework (CSAF) format.

Focuses on vulnerability information and mitigation guidance.
Can be combined with SBOM data through references or embedded within a CSAF document.
Offers wider adoption and familiarity due to CSAF's established presence.
May require additional data mapping for integration with SBOMs.

OpenVEX

That being said, the open source community, namely the Linux Foundation, are working on a standard called OpenVEX. OpenVEX is an implementation of VEX that is designed to be minimal, compliant, interoperable, and embeddable. The specification is available in the OPENVEX-SPEC.md file of the OpenVEX GitHub repository. OpenVEX documents are minimal JSON-LD files that capture the minimal requirements for VEX as defined by the VEX working group organized by CISA. The OpenVEX Specification is owned and steered by the community.

Staying up-to-date

If you’ve reached this point then you probably understand that VEX documents play a critical role in communicating the true risk posed by vulnerabilities within software products. However, the effectiveness of VEX hinges on one crucial factor: regular updates and refreshes.

Here's why keeping VEX documents up-to-date is essential:

Dynamic Vulnerability Landscape: Vulnerabilities are constantly evolving. New information about exploitability emerges, patches get released, and attack techniques change. Outdated VEX documents based on old data can lead to:

Misinformed decision-making: Basing critical security decisions on inaccurate information about exploitability.Misdirected efforts: Wasting time and resources patching vulnerabilities that are no longer exploitable.
Unpatched critical vulnerabilities: Leaving actual exploitable vulnerabilities unaddressed, increasing security risk.

Evolving Threat Landscape: Attackers constantly refine their techniques to exploit vulnerabilities. Keeping VEX documents current ensures you're aware of the latest exploitability information and can prioritize patching accordingly. This minimizes the window of opportunity for attackers and helps you stay ahead of evolving threats.

Improved Collaboration: Regular updates keep all stakeholders in the software supply chain on the same page. This facilitates better communication, coordination, and collaboration on vulnerability remediation efforts. Sharing accurate and timely VEX information fosters trust and transparency within the ecosystem.

Better Risk Management: Accurate VEX data empowers you to make informed decisions about risk mitigation strategies. You can allocate resources efficiently, prioritize patches based on actual exploitability, and focus on the vulnerabilities that pose the greatest immediate threat. This proactive approach minimizes potential damage and reduces overall security risk.

Refreshing VEX documents regularly can be automated using Kubescape and integrated into existing vulnerability management processes. This ensures a continuous flow of accurate information, enabling proactive risk management and informed decision-making.

Remember, VEX is only as valuable as its data. Keep it fresh, keep it accurate, and stay ahead of the changing vulnerability landscape

Conclusion

In this post we introduced the concept of VEX and that some open source scanners can use VEX to give more precise vulnerability scan results. Results that help lighten the load of figuring out which vulnerabilities need to be patch now.

However, to date, VEX adoption is still slow, due to the fact that generating VEX documents, especially those using the OpenVEX standard, is not yet straightforward or automated.

Kubescape is the first open source project that supports auto-generation of VEX documents. These documents can be used in the Kubescape scanner itself, or ingested by other open source scanners, like Grype and Trivy.

So, next time your vulnerability scanner spews an endless list of vulnerabilities whose dependencies you now need to investigate, try Kubescape to lighten the load.

To follow additional developments in open source Kubernetes security, check out the Kubescape GitHub repo, follow us on X (formerly known as Twitter), or join the community channels (#kubescape, #kubescape-dev) on the CNCF Slack.

Join the Kubescape community

We welcome your feedback and ideas for improvement. We hold community meetings on Zoom, on the first Tuesday of every month, at 14:00 GMT.

Thanks to all our contributors! Check out our CONTRIBUTING file to learn how to join them.

Feel free to pick a task from the good first issue list and suggest a design
Open an issue: we aim to respond to all issues within 48 hours
Join the CNCF Slack and then our users or developers channel
Don’t forget to leave a star on our repository: it means the world to us!

The Kubescape project follows the CNCF Code of Conduct.

Kubescape 3.0: The Capabilties System & Continuous Scanning

vladklokun — Mon, 06 Nov 2023 00:00:00 +0000

Kubescape 3.0: The Capabilties System & Continuous Scanning

Kubescape 3.0 is laden with new functionality. In this blog post, we will introduce you to two new and complementary features.

The new Capabilities system
The Continuous Scanning feature

Watch a short video for a demonstration of these features in action, or read on.

What’s new and how to?

The Capabilities System

The Capabilities system allows you to customize Kubescape's functionality according to your needs. You can enable or disable specific features such as Vulnerability and Configuration scanning, Relevancy, and Continuous Scanning. To do so, you just need to edit the values.yaml file and set the corresponding keys to enable or disable.

![Capabilities](capabilities.png){ width="600" }

Example of capabilities YAML

Continuous Scanning

One of the features you can enable with the Capabilities system is Continuous Scanning. This enables Kubescape to monitor your cluster's security posture continuously. Whenever a new resource is added to the cluster, Kubescape will automatically trigger a security scan and report the results. This way, you can always have the most up-to-date information about the state of your cluster's security.

To use Continuous Scanning, you need to install Kubescape and set the continuousScan key to enable

```yaml

capabilities:

continuousScan: enable # Make sure this is set to "enable"

```

Once enabled, the Continuous Scan feature will only scan according to additional capabilities defined by you. In the example below, we have enabled all the capabilities for the continuous scan.

```yaml

capabilities:

relevancy: enable

configurationScan: enable

vulnerabilityScan: enable

nodeScan: enable

After installing Kubescape with Continuous Scanning enabled, you can access the scan results as Custom Resources with the Kubernetes API. You can list all the scan results in your cluster by running the following command:kubectl get workloadconfigurationscans -n default```To view a specific scan result in more detail, you can run this, more specific, command:

kubectl get workloadconfigurationscans -n default {YOUR_RESOURCE_NAME} -o yaml | lessWith these commands, you can see how Kubescape evaluates your cluster's security based on the best practices from NSA and MITRE.

Conclusion

Kubescape 3.0’s new Capabilities system and Continuous Scanning feature are powerful tools that offer customization and continuous monitoring of your cluster’s security posture. By enabling specific capabilities, you can tailor Kubescape to your needs and ensure you always have the most current information about your cluster’s security.

The ability to access scan results as Custom Resources with the Kubernetes API, will increase your understanding of how Kubescape evaluates your cluster’s security based on the best practices from leading frameworks, such as, NSA-CISA and MITRE ATT&CK. We encourage you to explore these features and share your experiences with us. Stay tuned for more updates and keep your clusters safe and secure with Kubescape.

Please feel free to raise any issues in the Kubescape GitHub project or ask questions in our Slack channel.

Are you enjoying Kubescape? Please fill in our user survey!

Kubescape 3.0: Introducing Workload Scanning

vladklokun — Mon, 23 Oct 2023 00:00:00 +0000

Kubescape 3.0: Introducing Workload Scanning

Kubescape 3.0 introduces workload scanning, which allows you to comprehensively report on the security posture of individual workloads running in a Kubernetes cluster. This includes both misconfiguration and vulnerability scanning. This scan results in information that gives a 360° assessment of your workload’s security posture.

Watch a short video for a demonstration of workload scanning and its benefits, or read on.

What’s new and how to?

To scan a workload, simply run the following command:

kubescape scan workload -n <namespace> <kind>/<name>

For example, to scan a Deployment named "my-deployment", you would run the following command:

kubescape scan workload Deployment/my-deployment

Workload configuration scanning

At the top of the scan results, you will see the configuration scan results. These results are grouped by specific areas of concerns, such as security, networking, and secrets.

Kubescape also provides links to documentation for each misconfiguration, so that you can easily learn more about the issue and how to fix it.

![WL config scan results](wl-config-scan-results.png){ width="600" }

Configuration scan results in the Kubescape CLI

Workload vulnerability scanning

In addition to configuration scanning, Kubescape 3.0 also scans the images that your workloads run. This is important because container images are often the weakest link in the security chain.

If Kubescape finds any vulnerabilities in the images that your workloads run, it will display the results in the "Vulnerabilities" section of the scan results.

![Vulnerability summary](vulnerability-summary.png){ width="600" }

Image scan results in the Kubescape CLI

A helping hand

Security scan results can be overwhelming and confusing. To lighten this cognitive load and ensure that you make the greatest security impact with your work, Kubescape also provides a "What Now?" section. It provides concrete steps on how to improve the security of the workload. For example, Kubescape may suggest running a more detailed image scan or reviewing the documentation for a particular control.

![What now](what-now.png){ width="600" }

Guided next steps in the "What now?" section

Benefits

Comprehensive scanning: Kubescape scans workloads for both misconfigurations and vulnerabilities, giving you a complete view of their security posture with a single command.
Easy to use: Kubescape's CLI is simple and intuitive to use, making it easy to scan workloads and understand the results.
Actionable insights: Kubescape provides clear and concise explanations of each issue, as well as links to documentation on how to fix it.
CI/CD integration: Kubescape can be easily integrated into CI/CD pipelines to stop broken images from being deployed.

Conclusion

Workloads are at the heart of what you do. They hold the business value you bring your customers. They should be secure. A holistic view of your workload security, with clear guidelines on how to patch security issues and which issues to address first is key. Make the most of your security engineering time with Kubescape workload scanning. Try Kubescape today!

Please feel free to raise any issues in the Kubescape GitHub project or ask questions in our Slack channel.

Are you enjoying Kubescape? Please fill in our user survey!

Kubescape 3.0: Introducing Image Scanning

vladklokun — Thu, 12 Oct 2023 00:00:00 +0000

Kubescape 3.0: Introducing Image Scanning

In previous versions, Kubescape supported vulnerability scanning inside a cluster. We’ve brought this feature to the Kubescape command line in 3.0.

Watch a short video for a demonstration of image scanning from the Kubescape CLI and its benefits, or read on.

What’s new and how to?

Scanning an image in the Kubescape CLI

To scan an image, simply run the following command:

kubescape scan image

Kubescape will then scan the image for vulnerabilities and show you the results.

![Image scan](image-scan-results.png){ width="600" }

Result of image vulnerability scanning in Kubescape

The results include the following information:

The most pressing vulnerabilities in the image
The most vulnerable components
A link to the documentation for each vulnerability

If you would like to see all the vulnerabilities, regardless of severity, you can run the command in verbose mode with the -v flag.

kubescape scan image --verbose

The initial scan can take a while, as it is a comprehensive scan of everything. Subsequent scans are much quicker, so you can easily scan your images as part of your CI/CD pipeline.

Adding scans to your CI/CD pipelines

Having said that, the use case for security in CI/CD pipelines is not only about speed. To support this we extended our severity threshold flag to support image scanning. Just indicate the severity you would like to fail on, and Kubescape will fail your runs on them.

kubescape scan image my-image:latest --severity-threshold high

We believe that image scanning is an essential part of any Kubernetes security strategy. We encourage you to try it out and see for yourself how it can help you keep your images safe.

Conclusion

Image scanning is key to maintaining a tight security posture. It is now available on Kubescape and can be run via the CLI or embedded into your CI/CD pipelines. To learn more, please visit the Kubescape documentation.

Feel free to raise any issues in the Kubescape GitHub project or ask questions in our Slack channel.

Are you enjoying Kubescape? Please fill in our user survey!

Kubescape 3.0: CLI improvements

vladklokun — Sun, 01 Oct 2023 00:00:00 +0000

Kubescape 3.0: CLI improvements

In the latest release of Kubescape, we completely overhauled the CLI experience to make it easier and faster for you to improve the security of your clusters.

Watch a short video for a demonstration of the new CLI and its benefits, or read on.

What’s new?

Cluster overview scan

The new cluster overview/baseline security scan is designed to lessen the shock of being overrun by an overwhelming number of compliance and vulnerability errors identified by Kubescape. It helps you focus on the most important information.

The results are now structured in a way that presents you with the highest-value information from the get-go: your compliance score against the most popular security frameworks as well as the steps to safely go down the security rabbit hole without getting lost.

The overview scan performs some key security checks and then shows you the number of resources which have certain permissions. You are then able to set up risk acceptance rules to allow for things which are deliberately installed or configured about your cluster.

For example, malware in a cluster will often attempt to create a cluster admin role, or a role with permissions that approximates that. With the Kubescape overview scan, you can identify which roles you have installed that should have these permissions, and then easily see, or be notified, when the configuration changes from your secure baseline.

![New CLI output](kubescape-3-0-cli-showcase.png){ width="600" }

Kubescape’s new default CLI output is the cluster overview/baseline scan.

Before the quick summary sections are summary tables for each security concern of your cluster: controls related to the workloads running in the cluster, your cluster’s networking, secrets, access control and control plane behaviors.

![Examples of cluster overview scan summary tables per concern](summary-tables-per-concern.png){ width="600" }

Examples of cluster overview scan summary tables per concern

Quick pointer to highest-stake workloads

To help you focus on what matters most, Kubescape provides you with a quick pointer to your highest-stake workloads – those posing the highest risk AND providing the highest reward for remediation – as well as a Kubescape command to immediately investigate them.

![List of highest stakes workloads in the cluster overview scan](highest-stakes-workloads.png){ width="600" }

List of highest stakes workloads in the cluster overview scan

Ready-made commands for deep exploration of failed controls

For sections other than the Control Plane, Kubescape provides you with ready-made commands to continue to explore the failed control.

If you’re concerned about one of your results and would like to investigate it further, just run the command Kubescape gives you and scan for the control in question. These commands appear in the “View details” column in the summary tables, as depicted in the screenshot above.

Image scanning

To make Kubescape a complete one-stop shop for Kubernetes security, we introduced image scanning to the command line tool.

Image scanning allows you to scan your container images for vulnerabilities, even if they are not running in a cluster. This is a valuable feature for ensuring that your images are secure before you deploy them to your clusters.

To use image scanning, simply run the following command:

kubescape image scan <image>

Kubescape will then scan the image for vulnerabilities and provide you with a report.

![Result of image vulnerability scanning](image-scan-results.png){ width="600" }

Result of image vulnerability scanning

Conclusion

The new functionality in the Kubescape 3.0 CLI will make it easier and faster for you to improve the security of your Kubernetes clusters. Try it out today and let us know what you think!

Please feel free to raise any issues in the Kubescape GitHub project or ask questions in our Slack channel.

Are you enjoying Kubescape? Please fill in our user survey!

Introducing Kubescape 3.0

craigbox — Tue, 19 Sep 2023 00:00:00 +0000

Introducing Kubescape 3.0

We are excited to announce the preview release of Kubescape 3.0, the next generation of the CNCF Kubernetes security posture management tool.

Kubescape 3.0 will add:

Compliance and container scan results stored as Kubernetes resources inside the cluster
Scanning container images for vulnerabilities from the CLI
Reporting on the vulnerabilities of all the images in a cluster
A new overview security scan, which helps you set a baseline for cluster security
Highlighting of high-risk workloads: those that could do the most damage if they are compromised
Improved display output
A new capability-based Helm chart
Per workload, per namespace and per cluster Prometheus metrics
Alerting through Prometheus Alertmanager
Sending data outside the cluster to hosted services

Most of these features have landed already, with some being finished over the next few weeks.

!!! note "Are you running Kubescape? Want to help us get to incubation in the CNCF? Please help us by filling in our three-question survey!"

How we got here

Kubescape launched in September 2021 as a tool for validating a cluster against the NSA hardening guidance that had been issued under a month before. As Kubescape’s original creators ARMO built out their hosted offering, the maintainers added features to Kubescape to support that product, including vulnerability scanning and analysis of access control rules. That data was only available through ARMO’s commercial product.

The Kubescape project was donated to the Cloud Native Computing Foundation in 2022. Now, as a CNCF project, we’ve brought key functionality in-cluster, exposing security data in a Kubernetes-native format and enabling more DevOps-focused use cases.

New features

Configuration scan results stored in-cluster

Kubescape can scan running clusters in two ways: with an in-cluster agent installed via a Helm chart, or “agent-free” using the command line tool. In previous versions, the result data from in-cluster scans was only available to be sent to the ARMO service.

In Kubescape 3.0 we have added in-cluster storage for scan results. With the Kubescape in-cluster components installed, you will be able to see your scan results in ConfigurationScanSummary and WorkloadConfigurationScanSummary objects . Watch for enhancements in this area, including continuous scanning, where results are updated as resources change.

Vulnerability scanning, in-cluster and in the CLI

In previous versions, Kubescape supported vulnerability scanning inside a cluster. We’ve brought this feature to the Kubescape command line in 3.0.

![Scanning a single image in Kubescape 3.0](/blog/introducing-kubescape-3/scan-image.png){ width="600" }

The UX for scanning a single image in Kubescape. Output can be in tabular or `VulnerabilityManifest` JSON format

Bringing our image scanning to the command line unlocks many great use cases. You can scan a manifest file in a CI pipeline, and flag or reject it based on the number and class of vulnerabilities in the containers that will be installed. You can also use the CLI to scan an individual image and get output in the same JSON format as the in-cluster objects.

Our in-cluster agent previously had support for scanning the images in a Kubernetes cluster. We have extended that support to include exposing these results in-cluster with VulnerabilityManifestSummary objects, with full SBOM and vulnerability information in related VulnerabilityManifest objects. including software bills of materials (SBOMs) for each container, and filtered output using the Kubescape relevancy engine.

yaml{ "apiVersion": "spdx.softwarecomposition.kubescape.io/v1beta1", "kind": "VulnerabilityManifestSummary", "metadata": { "annotations": { "kubescape.io/image-id": "nginx@sha256:6926dd802f40e5e7257fded83e0d8030039642e4e10c4a98a6478e9c6fe06153", "kubescape.io/status": "", "kubescape.io/wlid": "wlid://cluster-docker-desktop/namespace-default/deployment-nginx-deployment", "kubescape.io/workload-container-name": "nginx" }, "creationTimestamp": "2023-09-18T08:37:38Z", "labels": { "kubescape.io/context": "non-filtered", "kubescape.io/image-id": "nginx-sha256-6926dd802f40e5e7257fded83e0d8030039642e4e10c4a98a6", "kubescape.io/image-name": "nginx", "kubescape.io/workload-api-group": "apps", "kubescape.io/workload-api-version": "v1", "kubescape.io/workload-container-name": "nginx", "kubescape.io/workload-kind": "Deployment", "kubescape.io/workload-name": "nginx-deployment", "kubescape.io/workload-namespace": "default" }, "name": "Deployment-nginx-deployment-nginx", "namespace": "default", "resourceVersion": "1", "uid": "3aea854d-8eea-4b8b-8a99-6472d3bc0521" }, "spec": { "severities": { "critical": { "all": 0, "relevant": 0 }, "high": { "all": 4, "relevant": 0 }, "low": { "all": 4, "relevant": 0 }, "medium": { "all": 23, "relevant": 0 }, "negligible": { "all": 72, "relevant": 0 }, "unknown": { "all": 10, "relevant": 0 } }, "vulnerabilitiesRef": { "all": { "kind": "vulnerabilitymanifests", "name": "nginx-e06153", "namespace": "default" }, "relevant": { "kind": "", "name": "", "namespace": "" } } }, "status": {}}

New scan modes

We have introduced a new cluster overview/baseline security scan, which performs some key security checks and then shows you the number of resources which have certain permissions. You are then able to set up risk acceptance rules to allow for things which are deliberately installed or configured about your cluster.

For example, malware in a cluster will often attempt to create a cluster admin role, or a role with permissions that approximates that. With the Kubescape baseline scan, you can identify which roles you have installed that should have these permissions, and then easily see, or be notified, when the configuration changes from your secure baseline.

If you would like to preview the new security scan mode, update Kubescape to the latest version (2.9.x) and try kubescape scan --view=security.

This scan will become the default behavior of kubescape scan in the coming weeks. You can access the previous default by running kubescape scan framework allcontrols,nsa,mitre.

![The new overview security scan](/blog/introducing-kubescape-3/security-scan.png){ width="600" }

The new overview security scan. Use Kubescape's risk acceptance feature to get all the scores down to 0, and then anything above this represents an issue worth investigating.

Enhancements to monitoring and alerting

Now we have data in the cluster regarding the configuration and vulnerability status of your environment, we can make this available through Prometheus. Our wonderful LFX mentorship students Tejas Jamdade and Yash Raj Singh have been building a Prometheus exporter and dashboards. These will allow you to look at control failures and vulnerabilities at a workload, namespace or cluster level, as well as setting up Alertmanager to inform you when security problems exceed a configurable threshold.

Third-party cluster data services

Good security practice is to store security information regarding a cluster outside of that cluster, so that it cannot be altered in the event of an attack.

As part of our commitment to vendor neutrality as a CNCF project, we have updated support for submitting data outside the cluster it is collected from. Previously, this feature was tightly coupled to the service operated by Kubescape’s creators. With Kubescape 3.0, we are fully documenting the APIs required for operating a Kubescape-compatible service, and allowing submission to any URL that is running a compliant service.

Capabilities-based in-cluster installation

With all our new in-cluster features, we’ve made it easy to enable and disable them in our Helm chart. You can now configure configuration scanning, vulnerability scanning, relevancy, and the node scanner in the values.yaml file:

yamlcapabilities: relevancy: enable configurationScan: enable continuousScan: disable vulnerabilityScan: enable nodeScan: enable

Other new features

distroless base images for added security
New eBPF engine, for lower resource consumption and improved kernel compatibility
Experimental support for patching container images (thanks to LFX mentorship student Anubhav Gupta)
Much nicer color and table output (thanks to contributor Anant Vijay)
Improvements for empty scans and scanning deleted resources

Kubescape 3.1 and beyond

We’re certainly not done here! For the rest of the year we will be finishing off our compliance and vulnerability scanning roadmap, including an in-cluster UI for better visualization of the saved results.

![Kubescape 3.1 UI preview](/blog/introducing-kubescape-3/ui-preview.png){ width="600" }

A work-in-progress look at what we’re building for the in-cluster UI. The final UI will probably be much different (and much better!)

Join the Kubescape community

We welcome your feedback and ideas for improvement. We hold community meetings on Zoom, on the first Tuesday of every month, at 14:00 GMT.

Thanks to all our contributors! Check out our CONTRIBUTING file to learn how to join them.

Feel free to pick a task from the good first issue list and suggest a design
Open an issue: we aim to respond to all issues within 48 hours
Join the CNCF Slack and then our users or developers channel
Don’t forget to leave a star on our repository: it means the world to us!

The Kubescape project follows the CNCF Code of Conduct.

Happy second birthday, Kubescape!

slashben — Thu, 14 Sep 2023 00:00:00 +0000

Happy second birthday, Kubescape!

What do you get a piece of software for its second birthday? A brand-new blog, of course! And cake. More on the cake later.

Kubescape is an open-source Kubernetes security platform that helps you identify and fix security risks, misconfigurations and vulnerabilities in your Kubernetes clusters. It is a powerful tool that can save you time and effort, and help you keep your Kubernetes deployments secure.

I co-founded ARMO, the creators of Kubescape, with the idea of bringing runtime security to Kubernetes deployments. As security engineers, we went to CISOs and security teams at enterprises and asked them what they needed. They told us that the Kubernetes deployments were the responsibility of the DevOps teams, and we should go talk to them.

The DevOps teams we spoke to had a whole different set of problems than the one we set out to solve. They were concerned by the hundreds of configuration options available in Kubernetes. They wanted tools to manage their security posture, reduce the amount of work to engineer and validate secure applications, and validate that their environments were compliant with industry best practices. They also emphasized the importance of these tools being available for immediate download, being open source, and being part of the larger Cloud Native community.

We heard you loud and clear, and in September 2021 we launched Kubescape. That means we’re now two years old!

The initial version of Kubescape let you validate your cluster against the then-recently published NSA and CISA Kubernetes hardening guidelines. Further releases added support for the MITRE ATT&CK framework and CIS benchmarks, and the security library now includes over 230 controls to validate your security posture.

We also added support for vulnerability scanning, allowing you to check for CVEs in your running containers or in a container registry, and recently added a capability to help users prioritize vulnerability detection by using eBPF to detect which packages are loaded at runtime.

Kubescape joined the Cloud Native Computing Foundation (CNCF) in December 2021, becoming the first and only open source, CNCF-hosted tool for Kubernetes security posture management. With almost 9,000 stars in GitHub, and users doing almost a million scans per month, it has become one of the most popular tools in this space.

ARMO has bet its business on open source, offering a comprehensive Kubernetes security platform powered by Kubescape. However, this same engine is available to anyone, and we’re delighted to see companies like Jit building their Kubernetes support on top of Kubescape.

Oh, and did we mention cake? The ARMO team celebrated Kubescape's second birthday by decorating some cakes. Congratulations to Amir, Yiscah and Rina, our winning team.

We are excited to tell you about some of the new features in our upcoming version. Keep an eye on our new blog in the next few days.

Kubescape

Kubescape Node Agent Now Works on GKE Autopilot Clusters

Kubescape Node Agent Now Works on GKE Autopilot Clusters

A Quick Background: Why It Wasn’t Possible Before

Why It Matters

How to Enable It

What’s Next?

Introducing a Visual Way to Explore Kubernetes Security: the Kubescape Plugin for Headlamp

Introducing a Visual Way to Explore Kubernetes Security: the Kubescape Plugin for Headlamp

Announcing the Kubescape Plugin for Headlamp

What Can You Do with the Kubescape Plugin?

Getting Started: How to Install the Kubescape Plugin

Kubescape

Headlamp Desktop App​

Headlamp Web app​

Acknowledgements & Future

Kubescape Now Supports CIS Kubernetes Benchmark v1.10

Kubescape Now Supports CIS Kubernetes Benchmark v1.10

What's New in CIS Kubernetes Benchmark v1.10?

Key Improvements Include:

How Kubescape Empowers Your Compliance Journey

Take Action Today

Join the Kubescape community

Kubescape's Journey to Incubation: Celebrating our Community and a Secure Kubernetes Future

Kubescape's Journey to Incubation: Celebrating our Community and a Secure Kubernetes Future

Join the Kubescape community

CEL and Kubescape: Transforming Kubernetes Admission Control

CEL and Kubescape: Transforming Kubernetes Admission Control

Introduction

Validating Admission Policies Short Primer

Introduction to ValidatingAdmissionPolicies

The Goals of Validating Admission Policies

The Benefits of Validating Admission Policies

Kubescape's Cel-Admission-Library

Using the Kubescape CEL library in your cluster

Install configuration CRD

Install basic configuration

Install policies

Create a binding

Create a namespace for running the example

The next line should fail

Configuration

Conclusion

Enhancing Bitnami Helm Charts Security: A Kubescape Case Study

Enhancing Bitnami Helm Charts Security: A Kubescape Case Study

Introduction

Why did we choose Kubescape?

Bitnami Helm chart security improvements

Final considerations

Patching Image Vulnerabilities with Kubescape & Copa

Patching Image Vulnerabilities with Kubescape & Copa

What is Kubescape? 🔍

What are Image Vulnerabilities? 💀👾

What is Image Patching? 🩹

How does it work? ⚒️🤔

Demo 🧑‍💻 👀

Conclusion

Kubescape: The 1st Open Source project to support VEX Generation

Kubescape: The 1st Open Source project to support VEX Generation

Introduction

VEX and vulnerability scanners

Enter Kubescape

Generating VEX Documents with Kubescape

VEX formats

CycloneDX VEX:

CSAF VEX:

OpenVEX

Staying up-to-date

Conclusion

Join the Kubescape community

Kubescape 3.0: The Capabilties System & Continuous Scanning

Kubescape 3.0: The Capabilties System & Continuous Scanning

What’s new and how to?

The Capabilities System

Continuous Scanning

Conclusion

Kubescape 3.0: Introducing Workload Scanning

Kubescape 3.0: Introducing Workload Scanning

What’s new and how to?

Workload configuration scanning

Headlamp Desktop App

Headlamp Web app