K8s image authenticity validator
Image signing and image signature verification is an important countermeasure against security threats. While image signing happens in the automated CD workflow, Warden realizes image signature verification happening in the k8s cluster.
Warden allows for configuring a target notary service (via Helm values) and utilizes the Kubernetes label selector mechanism to look for protected namespaces (namespaces.warden.kyma-project.io/validate: enabled
).
If an image was not signed by the configured notary service, and it is used to schedule a pod in the protected namespace, the pod admission will be rejected.
You must have a Kubernetes cluster to run against. You can use kind to get a local cluster for testing or run against a remote cluster.
Warden realizes image verification by its two components:
Warden admission - intercepts scheduling of any pods into the protected namespaces and rejects it if notary service indicates that the image was not signed at all or signing is invalid. If the signature cannot be verified at that stage, the verification status is set to PENDING
.
Warden operator - a controller that watches already scheduled pods and verifies their signature if the signature status has not been determined (for example, because of a temporary downtime of notary service).
Install Helm charts:
make install
Install Helm charts on the k3d instance with locally built images:
make install-local
Uninstall Helm charts:
make uninstall
If you are editing the API definitions, generate the manifests such as CRs or CRDs using:
make manifests
NOTE: Run make help
for more information on all potential make
targets.
More information can be found via the Kubebuilder Documentation
Run unit tests
make verify
Start the k3d instance locally and run integration tests
make k3d-integration-test
If you have the k8s instance with Warden installed already, run integration tests with the following command:
make run-integration-tests
In this project we follow git flow. Every minor release is maintaned in its separate branch.
If you want to patch a version, cherry pick all fix commits into the release branch.
If you want to create a new release, create a new branch from main for the release.
Run a create release
action providing the release name (semantic version x.x.x
; no v
prefix) and selecting release branch.
See the Contributing Rules.
See the Code of Conduct document.
See the license file.