Mastering Kubernetes Security #2: Container Vulnerability Management

Blog Author
Abhinav Mishra

When you run cloud-native workloads, vulnerabilities are always found, whether a certain vulnerable package or a known exploit. You could have thousands or even hundreds of thousands of vulnerabilities at any time. Multiply that by the number of container assets and images, and you have a big challenge of figuring out where to start.

In my previous blog, I dove deep into how one could operationalize valuable guides such as the Kubernetes NSA Hardening Guide by leveraging  Uptycs' unified CNAPP and XDR platform for visibility across your cluster fleet, continuous monitoring and scanning, and detailed evidence and remediation steps.

 

Now, we’ll dive into vulnerability management and how to implement shift left controls to prevent any vulnerabilities, malware, or secrets from entering your SDLC and supply chain.

 

Top Kubernetes and container vulnerability management challenges

Here are some of the challenges we see when it comes to vulnerability management for Kubernetes and containers today: 

 

  • Vulnerability prioritization and key performance indicator (KPI) based measurement: With all the noise and scale of ephemeral workloads such as containers and pods, SecOps admins many times have to go through a lot of noise to get at the heart of the issues, such as which vulnerabilities are most critical or which ones need the most fixing based on their specific environments. Moreover, a lack of KPIs means that vulnerability management solutions today are good with information but not good with providing actionable insights to operationalize vulnerability fixing at scale. 

  • Insecure/fragmented security across the software development life cycle (SDLC): Without a secure DevOps pipeline, customers must be more reactive in remediating vulnerabilities. No images with known vulnerabilities leaking credentials or containing malware should ever be promoted into a position where they could easily or accidentally be deployed to production systems. In addition, SecOps admins also have to use disparate tooling to catch vulnerabilities in their CI versus their registry, which can lead to blind spots and more time spent evaluating results versus taking action!

  • Lack of flexible controls to fit your developer needs: While critical vulnerabilities may be important to be aware of, there may not be a fix available. It's also beneficial to differentiate between dev-test and production environments. While always enforcing rules in production, consider only auditing in dev-test, ensuring CI image builds aren't halted, and keeping developers unhindered. 

Let’s see how Uptycs unified CNAPP and XDR security platform enables you to solve these challenges while providing a single solution for all your Kubernetes/containers vulnerability management from code to cloud.

Step 1: Vulnerability prioritization and KPI measurement

Container vulnerabilities dashboard in the Uptycs platformFigure 1 – Container vulnerabilities dashboard in the Uptycs platform

 

The Uptycs platform gives you a single place to start for anything and everything on your Kubernetes and containers vulnerability management! Specifically, the dashboard empowers SecOps admins to do the following:

 

  • Prioritize what is important: Uptycs does intelligent prioritization for you by leveraging key, actionable metrics such as: 
    • Whether a fix is available or not
    • Whether the vulnerability is exploitable or not
    • CVSS Score 
    • Number of assets affected 

By starting here you can instantly cut the noise down and start with what is most  important!  

 

  • Operationalize daily/weekly triages: Through metrics such as what are your new daily vulnerabilities or net new this week - SecOps admins now have an easy way to see what is most relevant now and assign a JIRA ticket or add to an exception list with one single click. 

  • Continuously measure and improve: Using metrics such as average close time, CISOs and SecOps admins can continuously track and measure their overall velocity when fixing vulnerabilities and improving continuously. The Uptycs platform gives you a resolved vulnerability view to measure and audit your vulnerability fixes, including specific package updates.

Resolved vulnerabilities shown in the Uptycs platformFigure 2 – Resolved vulnerabilities shown in the Uptycs platform

Step 2: Implementing shift left controls across your SDLC

Next, in order to be more proactive in fixing your vulnerabilities earlier in the SDLC, Uptycs offers CI and Registry scanning capabilities that are extremely easy to onboard, allowing you to secure your innovation pipeline from code to cloud.

 

FiguSecure your innovation pipeline from code to cloudFigure 3 - Secure your innovation pipeline from code to cloud

 

 

Capability
Supported Platforms

CI Scanning

Jenkins, GitHub, GitLab, Travis CI, AWS CodeBuild

Registry Scanning

JFrog Artifactory, Private Docker, Amazon ECR, Azure ACR, Google GCR 

 

What sets Uptycs apart?

We can uniquely scan images across CI and Registry for vulnerabilities, malware, and secrets - ensuring your code is always at its safest.

Ready to elevate your Kubernetes and container security? Explore how Uptycs can empower your strategy at Uptycs Containers & Kubernetes.

 

CI Image scanning in the Uptycs platformFigure 4 – CI Image scanning in the Uptycs platform

 

When you start with CI Scanning, the Uptycs platform shows you the security results and passed and failed image builds so that you can correlate your security findings to your SDLC. 

You also get the same view with registry scanning, allowing admins to filter by a given CVE vulnerability and check on what parts of their SDLC, CI Registry, and Runtime that vulnerability is present. 

 

Figure 5 – Registry scanning in the Uptycs platformFigure 5 – Registry scanning in the Uptycs platform

 

As you start to prioritize fixes of images across your SDLC or look at your most vulnerable images, you get a single pane of glass view of your image security across the SDLC to answer key questions such as: 

 

  • Did the developer image go through the security controls across the SDLC? If not, what was missed?

  • Did the image get deployed from a trusted registry? Images should only be pulled from trusted registries that are ideally being scanned for vulnerabilities. 

  • Did the developer bypass/not use the enterprise registry and instead deploy from registries such as DockerHub? 

These insights can be key to ensuring your development teams and business units follow the right process while ensuring you have end-to-end security controls across your developer pipeline.

 

Image traceability through the SDLCFigure 6 – Image traceability through the SDLC

Step 3: Enabling developer-friendly guardrails

While you may want to enable guardrails in runtime, a delicate balance must be achieved in the SDLC to ensure you have security controls in place while not hindering developer velocity. 

In order to facilitate this, Uptycs offers key capabilities as part of the CI Scanning capabilities, such as the following: 

Grace Periods: Users may configure a vulnerability "Grace Period," which allows a vulnerability, once first detected, to remain within an image for a set amount of time. If the vulnerability remains within an image once the Grace Period has elapsed, then builds will fail until the vulnerability is no longer detected. This grants developers time to remediate the newly detected vulnerabilities without immediately interrupting their task when the vulnerability was first discovered.

Policy Configurations: What if you wanted to ignore vulnerabilities with no fixes as part of your CI Scanning? Or only fail based on a set of critical CVEs or even ignore certain vulnerabilities? As part of your Uptycs CI Scanning configuration, you can enable certain policy configurations and flags to tailor your vulnerability management to your business needs.

 

# Configure vulnerability scanning.

vulnerabilities:

    fatal_cvss_score: 7 # Configure the maximum allowable CVSS score.

    ignore_no_fix: true # Ignore any detected vulnerabilities for which there are no known fixes.

 

Image Admission Controller: With the image admission controller (Fig. 6), you can implement secure guardrails by blocking images coming from registries scanning in Uptycs and with critical or high vulnerabilities from being used in runtime. This gives SecOps admins confidence that critical or high vulnerabilities will never make it into their container and Kubernetes runtime environments while allowing developers the necessary time to fix the image vulnerabilities earlier in the SDLC.

 

Image 7 - Image Admission ControllerFigure 7 – Image admission controller in Uptycs platform

Conclusion

Navigating vulnerabilities in Kubernetes and container environments is complex. As these vulnerabilities mount, challenges arise in prioritization, securing the SDLC, and ensuring developer flexibility. Uptycs unified CNAPP and XDR is designed to meet these challenges head-on. By offering intelligent vulnerability prioritization, seamless integration with the SDLC through CI and Registry scanning, and developer-centric guardrails, Uptycs ensures businesses can effectively manage risks while fostering innovation.

 

More from this series:

Mastering Kubernetes Security Part 1: NSA Hardening Guide

Mastering Kubernetes Security Part 3: Runtime Admission Controls

Mastering Kubernetes Security Part 4: Authorization, Access & Secrets

Mastering Kubernetes Security Part 5: Incident Response with Detections