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.
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
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.
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.
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.
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”.
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.
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 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 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.
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:
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 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:
# Create a bindingkubectlapply-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 examplekubectlcreatenamespacepolicy-example
kubectllabelnamespacepolicy-example'policy=enforced'
Now, if you attempt to create an object without specifying a readOnlyRootFilesystem, it will not be created.
# The next line should failkubectl-npolicy-examplerunnginx--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://hub.armosec.io/docs/c-0017)
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:
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.
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.
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.
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.
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.
