The Open Source Kubernetes Common Configuration Scoring System

By Julien Sobrier, Head of Product, Octarine

With over 30 security settings under the control of every single developer, you need to be a Kubernetes expert to understand if the final configuration introduces a high risk to your cluster. With a single change to a single file you can open your entire Kubernetes cluster to privilege escalations, attacks, leak secrets, risk confidential data, or accidentally give public access to private services.

Octarine is on a mission to make DevSecOps simple to infuse into cloud native organizations and workflows. This means that security best practices need to shift all the way left to the developers, and this begins with the configurations of Kubernetes themselves. Today we have released two new open source projects that specifically address the issue of misconfigurations in Kubernetes to make them easier to understand and address, and give end users a clear path to remediation: the Kubernetes Common Configuration Scoring System (KCCSS), and kube-scan.

KCCSS is a new framework for rating security risks associated with misconfigurations. kube-scan is a workload and assessment tool that is based on KCCSS and scans Kubernetes configurations and settings to identify and rank potential vulnerabilities in applications within minutes.

A standard way to determine risky workloads due to configs

KCCSS is similar to the Common Vulnerability Scoring System (CVSS), the industry-standard for rating vulnerabilities, but instead focuses on the configurations and security settings themselves. Vulnerabilities are always detrimental, but configuration settings can be insecure, neutral, or critical for protection or remediation. KCCSS scores both risks and remediations as separate rules, and allows users to calculate risk for every runtime setting from 0 to 10, with 10 being the most at risk, then calculates the global risk of the workloads overall.

The scoring formula as well as the risk and remediation rules are open-source, and available on github. The list of rules can be easily expanded to include vendor-specific remediations, risks and remediations for different Kubernetes distributions or cloud providers, or risks and remediations for additional tools installed (Service Mesh, Helm server, etc.). We want to build a community around KCCSS and we encourage any kind of contribution, review of existing rules, new rules, better formulas, and so on.

KCCSS shows the potential impact of risky configuration settings in three areas:

  • Confidentiality: exposure of PII, potential access to secrets, PII, etc.
  • Integrity: unwanted changes to the container, host or cluster such as being able to change the runtime behavior, launch new processes, new pods, etc.
  • Availability: exhaustion of resources, Denial of Service, etc.

Then, KCCSS takes into account the blast radius (risk is limited to the container, or can affect the entire cluster), the ease of exploiting the risk, and whether an attack would require local access—or can be done remotely—to rate the risk. It combines all of the security risks associated with a workload, along with the required remediations, to attribute an overall risk score to the workload.

A common language across teams

KCCSS makes it easy to talk about security across teams in your organization. DevOps teams can track the high risk workloads. Developers see what settings are impacting the security of their services, and can decide to either change those settings, or bring down the risk level to an acceptable level. Compliance or Business teams get a clear understanding of the potential impact of the risk and can decide whether it is acceptable or not.

Add your own rules

We designed KCCSS to be easily expanded by others, whether they are security vendors, open-source developers or Kubernetes users. You can easily add rules to represent risks or remediations brought by different Kubernetes tools and services to ensure you have a comprehensive view of your security posture. We welcome all contributions from the community and other vendors, so please join us to make improvements to existing rules, create new generic Kubernetes rules, vendors rules, etc.

We have additional documentation in the github project that explains how the rules are created, the meaning of the different fields and the formula to compute each score. We will be adding more tools and more documentation in the coming days.

Try KCCSS with kube-scan

Kube-scan is now open-source and has been updated to include all the KCCSS rules. It’s the easiest way to run KCCSS on your clusters to identify your most risky workloads. Check out the github page to download the latest version and install it today.

Get in touch with us:

Want security tips from the pros?
Get the DevSecOps simplified newsletter.

* indicates required

Please select all the ways you would like to hear from Octarine:

You can unsubscribe at any time by clicking the link in the footer of our emails. For information about our privacy practices, please visit our website.

We use Mailchimp as our marketing platform. By clicking below to subscribe, you acknowledge that your information will be transferred to Mailchimp for processing. Learn more about Mailchimp's privacy practices here.