Improve Kubernetes Security with Signed Artifacts and Admission Controllers
Control which images get deployed in Kubernetes by configuring an admission controller to admit only those which have been signed by Endor Labs.
Control which images get deployed in Kubernetes by configuring an admission controller to admit only those which have been signed by Endor Labs.
Control which images get deployed in Kubernetes by configuring an admission controller to admit only those which have been signed by Endor Labs.
Control which images get deployed in Kubernetes by configuring an admission controller to admit only those which have been signed by Endor Labs.
Control which images get deployed in Kubernetes by configuring an admission controller to admit only those which have been signed by Endor Labs.
Kubernetes admission controllers are used to enforce policy decisions on whether deployments are admitted to a Kubernetes cluster. Instituting this type of launch control helps prevent “shadow deployments” and malicious deployments by enabling your admission controller to identify trusted artifacts and revoke permission to launch specific artifacts. Unsigned container images can pose significant security risks as they lack verification of their source and integrity, increasing the potential for malware introduction and non-compliance with regulatory standards.
However, traditional approaches to artifact signing are complex due to the challenges of secure identity establishment, certificate management, and ensuring a secure and auditable signing process. Endor Labs simplifies this by using your existing identity system linked via OpenID Connect or SAML to establish identity, providing simple signing options and maintaining a private tamper-proof log of all signed artifacts, making signing more accessible.
Let’s walk through an example of how to configure an admission controller to deploy just the images which have been signed using Endor Labs, ensuring unsigned artifacts are not admitted to production environments. Artifact signing ensures the integrity and authenticity of software binaries and configurations, safeguarding against unauthorized modifications.
Watch this short video for a walkthrough of the tutorial and check get resources for the tutorial in GitHub.
Requirements
To complete this tutorial, you need the following:
- Administrative access to a Kubernetes cluster to deploy resources including namespaces, pods and secrets (such as minikube)
- An installation of kubectl, configured for your cluster
- API key from Endor Labs with the "Code Scanner" permissions
- If you’re not an Endor Labs customer, you can complete this tutorial using a free, 30-day trial.
- A Docker registry to store the webhook server container image
Step 1: Build and Deploy the Controller
Assuming you don’t already have a Kubernetes admission controller in a test environment that you want to use for this tutorial, you must begin by building and deploying a simple admission controller. The admission controller you’ll build in this step is designed as a demonstrative example and is not intended for production use.
This controller (a webhook server) is deployed to a hardcoded namespace called "endorlabs-tutorial." It monitors a namespace called “production” in the Kubernetes cluster to decide what to admit. The controller only validates images which have been signed within a GitHub pipeline using OIDC authentication. Deployment images must include the hash (tags are not supported), therefore container images should be in the format IMAGE_NAME@sha256:SHA.
Build the container and push to your preferred container registry:
- For a single architecture build run:
docker build -t your-repo/your-image:0.1 - For multi-architecture build run:
docker buildx build --platform linux/arm64,linux/amd64 -t your-repo/your-image:0.1 - Push to your preferred container registry, e.g. for Docker Hub:
docker push your-repo/your-image:0.1
To deploy the controller, first make a copy of webhook_server.template.yml named webhook_server.yml, then:
- Modify the
image: to match your repo/image/version on line 20 - Modify the Endor
NAMESPACEvalue on line 42 - If you're not signing in a GitHub action, modify the
CERTIFICATE_OIDC_ISSUERvalue on line 44
Make a copy of secrets.template.yml named secrets.yml then:
- Add your base64 encoded Endor API Key on line 8
- Add your base64 encoded Endor API Secret on line 9
Run the script ./deploy.sh which performs the following functions:
- Generates TLS certificates to securely communicate with the Kubernetes API server
- Creates Kubernetes secrets using your Endor API credentials
- Creates the webhook server in a namespace called "endor"
- Deploys the admission controller webhook to verify if images are signed in a namespace called "production"
Step 2: Signature Validation
Once deployed and configured, the admission controller automatically validates deployments, ensuring that:
- Each container image in the deployment specifications includes a digest (
IMAGE_NAME@sha256:SHA); and - The image was signed using the Endor Labs API, and is valid, which meanssome text
- A trusted identity was used to sign
- The certificate was issued by a CA that we trust
- The signature was made using a valid, one-time use certificate and it was done during the certificate’s validity (5 minutes)
- The signature has been verified using the certificate’s public key
- The signature was not revoked
If a deployment does not meet these criteria, it is rejected with a message indicating the reason.
To test whether the admission controller is working as expected, we attempt two images: one with a signature and one that is unsigned. If your admission controller is working as expected, the signed image should deploy successfully, as evidenced by deployment.apps/<your image name> created.
The unsigned artifact should cause a failed deployment with a response indicating that it was unable to verify because there was no matching signature.
Error from server: error when creating "examples/nginx-unsigned-image.yml": admission webhook "deployment-validation.endor.svc" denied the request: Container image signature verification failed for the image <your image>, with reason: API request failed: {"code":13, "message":"Unable to verify certificate: no matching signatures", "details":...
Build a CI/CD Security Program with Endor Labs
Endor Labs provides a secure, transparent, and accessible solution to signing, verifying, and protecting software artifacts to enhance the security of software supply chains.
In addition to artifact signing, Endor Labs CI/CD includes:
- CI/CD Discovery: Get visibility into tools used in pipelines across your org, understand security coverage, and find policy violations.
- Repository Security Posture Management (RSPM): Detect repo misconfigurations, best practices, and risks with over 50 out-of-the-box policies.
Book a demo to discuss your use cases or start a free trial where you can explore the Endor Labs Software Supply Chain Security platform on a pre-populated demo environment and with your own projects.