Policies are a core component of a Kubernetes cluster story that involves security, compliance and consistency.
Being this process an iterative one, it’s common for new policies to potentially reject operations that we might be issuing today in our production clusters.
As an example, we might have decided that it’s not possible to change certain annotations on existing resources after the fact. In this case, we don’t want to revoke UPDATE rights completely, but just to define an inalterable set of annotations after the resource has been created.
With recent releases, the Kubewarden stack supports verifying the integrity and authenticity of content using the Sigstore project.
In this post, we focus on Kubewarden Policies and how to create a Secure Supply Chain for them.
Sigstore? Since a full Sigstore dive is not within the scope for this post, we recommend checking out their nice docs.
In short, Sigstore provides an automatable workflow to match the distributed Open Source development model.
Recently a severe CVE in the CRI-O container engine come to public. The flaw in CRI-O allows bad actors to gain root access and run arbitrary code in the host machine.
A fix for the issue is already available and you should update your cluster to avoid any headache in the future. But if you cannot do that right away, use Kubewarden to mitigate the impact of this issue. It’s possible to prevent pods with sysctl configuration to run in the cluster with the policy sysctl-psp available in the Policy Hub.
Up till now, the only way to define a policy in Kubewarden was to use the ClusterAdmissionPolicy resource that would be applied to cluster-wide resources across all namespaces.
That’s why we’re thrilled to announce the new AdmissionPolicy resource. This new resource is created inside a namespace and the policies will only process the requests that are targeting the namespace where the AdmissionPolicy is defined. Except from being a “namespaced” resource, AdmissionPolicy works exactly the same as the ClusterAdmissionPolicy.
The Kubewarden team is glad to announce that in the spirit of helping Policy Authors and Cluster Administrators, the project is now officially multiplatform.
The list of supported platforms as of now are:
Policy Server, as a container image:
linux/amd64 (with the musl libc) linux/arm64 (with the musl libc) kwctl, as a standalone binary:
darwin (x86_64) linux (aarch64, with the musl libc) linux (x86_64, with the musl libc) windows (x86_64, with MSVC) We have prioritized the usage of the same dependencies and toolchain on platforms where we were able to do so.
The Kubewarden team worked tirelessly to create equivalent Kubewarden policies for all the deprecated Pod Security Policies (PSP). In order to reach this very important milestone, the team wrote the policies with the same validations available in the Kubernetes PSPs, and we counted on the community help to map and validate the policies.
This will allow our users to replace deprecated PSPs while continuing to enforce their security rules.
The Kubewarden policies which replace all the Kubernetes PSPs, are available in the Policy Hub, and you can find them by typing the keyword “PSP”.
We recently got notified that the policy-server was crashing in an aarch64 environment. The moment in which it got a request from the API server, it crashed immediately with a SIGSEGV signal.
We figured out that this was only happening when the request was a TLS one, and that the problem was related to the OpenSSL stack and the way we were producing the final image of the policy-server with the OpenSSL stack.
Year 2021 is almost over. Let’s take that as a chance to look back at what has been achieved during the 1st year of life of the Kubewarden project.
Finally, I’ll also talk about what we plan to do during the next one.
2021 Highlights Project Announcement The Kubewarden project has been introduced to the masses for the 1st time during KubeCon Europe 2021. During this presentation, Rafael and I explained what lead us to rethink how Kubernetes policies could be written and distributed.
Policies are regular programs. As such they often have the need to log information. In general, we are used to make our programs log into standard output (stdout) and standard error (stderr) outputs.
However, policies run in a confined WebAssembly environment. For this mechanism to work as usual Kubewarden would need to set up the runtime environment in a way that the policy can write to stdout and stderr file descriptors, and upon completion, Kubewarden can check them – or stream log messages as they pop up.
We are pleased to announce a new architecture for the Kubewarden stack, in line with its journey to maturity:
The introduction of a PolicyServer Custom Resource Definition (CRD) which allows users to describe a policy-server Deployment, together with binding ClusterAdmissionPolicies to a specific PolicyServer instance.
These 2 changes are accompanied by a multitude of improvements to make Kubewarden more comfortable for Kubernetes Administrators, such as validation for Kuberwarden Custom Resources, improvements in Helm Charts, Status and Conditions for ClusterAdmissionPolicies.