Recent high-profile software supply chain cyberattacks show just how difficult securing modern software development and assembly can be.
Most large-scale enterprise applications rely on third-party software packages with a business’s own enterprise code and sophisticated hybrid cloud configurations—assembled and orchestrated as part of continuous integration and deployment. No surprise then that Gartner predicts by next year 99% of all cloud security incidents could be the attributed to customer misconfigurations.
Understanding the authenticity and provenance of software deployment artifacts is crucial. And it’s also becoming part of regulatory compliance for critical government applications.
We want to help.
Earlier this month, our IBM Research team added a new project, k8s-manifest-sigstore to the sigstore community. Sigstore is a Linux Foundation project launched in March, aimed at easing the adoption of cryptographic software signing, allowing developers to securely sign software artifacts using an email address or some other form of identity. Signing materials are stored in an immutable log to ensure accountability.
Using cryptographic signing of artifacts is one of the foundations to building an auditable software supply chain.
Red Hat advanced cluster management provides a set of control points to enforce and verify Kubernetes resource configurations, ensuring a resource has not been modified maliciously or unintentionally before it is applied to a Kubernetes cluster. Hybrid cloud applications require cloud configuration integrity to meet financial and regulatory compliance.
Verifying cluster with Kubernetes signing
Modern software assembly often largely relies on third-party packages and artifacts, including container images, package modules, software bill of materials (SBOM), and configuration files. Many artifacts are produced throughout the software supply chain and deployment process. The origin and authenticity of those software building blocks are critical to ensure the security of the final software products.
Kubernetes applications are built and deployed with manifests that contain images, deployment configuration, ConfigMap, DaemonSet other API object descriptions.
Using automated deployment, often referred to as GitOps, is not new. What’s new is the ability to verify the origin and integrity of a Kubernetes manifest with cryptographic signing that each step of the process is accounted for. The result is an accurate and secure software supply chain.
By extending sigstore with the help of the Integrity Shield to perform cryptographic signing and verification of Kubernetes resources files, regulated cloud workloads should provide evidence of tamper-proof deployments on Kubernetes.
Our new tool uses sigstore to bundle a YAML manifest as a signed image and push it into an Open Container Initiative (OCI) registry.
The signed image is then pulled from the registry while verifying a resource. A command-line interface tool is in the form of a kubectl subcommand plugin, and the manifest in the signed image defines the expected state of resources.
By inspecting the resources on the cluster against those in the signed manifest, we check that the resources are unchanged. An administrator can then use this command to verify that the state of the cluster is as expected.
In strictly controlled clusters, the deployment to the cluster should be limited to verified manifest configurations, preventing any unauthorized changes from the signed manifest.
Integrity Shield does just that, providing preventive control based on signature verification. Integrity Shield is currently in tech preview for Red Hat Advanced Cluster Management for Kubernetes, and it will be extended to use sigstore signing in future releases.