How we differentiate ARMO Platform from Open Source Kubescape
In this blog post we will be discussing how we differentiate ARMO Platform from Open...
Sep 12, 2024
Guest post originally published on Kubescape’s blog by Oshrat Nir, Developer Advocate at ARMO and a Kubescape contributer.
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 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 logicValidatingAdmissionPolicyBinding
links the above policy to the resources it applies toThe Kubernetes team has established specific goals for Validating Admission Policies to guarantee that it aligns with the community’s requirements.:
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:
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:
After thorough testing, the Kubescape maintainers have found them to be as robust and precise as the ones written in Rego.
But that isn’t all. A common feature request for Kubescape is to be able to implement policies based on its findings and output. For example, after scanning pods for known paths to cloud credential files, users would like the ability to enforce policy that these pods should not be admitted at all.
Validating admission policies can help with this exact use case, while removing the barrier of entry creating Rego rules, which for all their flexibility create a learning curve that uninitiated users will typically seek to avoid.
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:
minikube start --kubernetes-version=1.26.1 --extra-config=apiserver.runtime-config=admissionregistration.k8s.io/v1alpha1 --feature-gates='ValidatingAdmissionPolicy=true'
To install the policies in your cluster:
# 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
:
# Create a binding kubectl apply -f - <<EOT apiVersion: admissionregistration.k8s.io/v1alpha1 kind: ValidatingAdmissionPolicyBinding metadata: name: c0017-binding spec: policyName: kubescape-c-0017-deny-mutable-container-filesystem matchResources: namespaceSelector: matchLabels: policy: enforced EOT # Create a namespace for running the example kubectl create namespace policy-example kubectl label namespace policy-example 'policy=enforced'
Now, if you attempt to create an object without specifying a readOnlyRootFilesystem, it will not be created.
# The next line should fail kubectl -n policy-example run nginx --image=nginx --restart=Never
The output shows our error: 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 next line should fail kubectl -n policy-example run nginx --image=nginx --restart=Never
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.
In this blog post we will be discussing how we differentiate ARMO Platform from Open...
Guest post originally published on Kubescape’s blog by Oshrat Nir, Developer Advocate at ARMO and a Kubescape contributer. Introduction: Vulnerability Exploitability eXchange...
We are excited to announce the preview release of Kubescape 3.0, the next generation of...