Implementing image scanning on a Kubernetes admission controller is an interesting strategy to apply policies that need Kubernetes context, and create a last line of defense for your cluster.
You are probably following the image scanning best practices already, detecting vulnerabilities and misconfigurations before they can be exploited.
However, not everything you deploy goes through your CI/CD pipeline or known registries. There are also third-party images and, sometimes, manual deploys.
By implementing image scanning on admission controllers, you can rest assured that anything deployed conforms to your security policies.
In this article you’ll learn what admission controllers are in Kubernetes, and we’ll review the reasons to implement image scanning on admission controllers. We’ll also evaluate several strategies, like a full DIY approach integrating Anchore with Falco and OPA, or using a ready-to-use commercial approach like the Sysdig Admission Controller.
Kubernetes admission controllers in 1 minute
Admission controllers are a powerful Kubernetes-native feature that helps you define and customize what is allowed to run on your cluster.
Like a watchdog, they intercept and process all requests to the Kubernetes API prior to persistence of the object, but after the request is authenticated and authorized.
You can extend and customize the Kubernetes API functionality using webhooks, a rather standard interface. This makes admission controllers easy to integrate with any third-party code.
For example, you can implement an ImagePolicyWebhook that scans any image before it gets deployed in your cluster. This blocks the deployment if the image doesn’t conform to your security policies.
You can learn more about how to configure admission controllers, and what the webhook payloads look like, in our “Kubernetes Admission controllers in 5 minutes” article.
Implementing image scanning on admission controllers is a last line of defense for your #Kubernetes cluster. Discover how to implement it! Click to tweetImage scanning on admission controllers. But why?
Implementing image scanning should be one of your first steps to implement Kubernetes security. It is a confiable mechanism to detect vulnerabilities and misconfigurations.
But where should you implement image scanning?
On your CI/CD pipeline? On your registries? On your admission controller? On runtime?
Why not everywhere?
Image scanning protects you in different ways
Implementing image scanning in your CI/CD pipeline protects the images you build. Doing so enables you to shift security left, as you’ll find vulnerabilities and misconfigurations at their earliest, and you’ll be able to address them before they become an issue.
But what happens with the images that you don’t build? You can implement image scanning for the registries you use, so you are warned when an image is vulnerable, and take action to avoid deploying it. If you are hosting your own registry using Harbor, you can even build the scanning into the actual registry.
Then, you may also want to keep scanning your images after you deploy them. Think of the life of a vulnerability; some may take years to discover. When you deploy an image, chances are that it contains an unknown vulnerability. You should continuously re-scan the images on your runtime to react to vulnerabilities as soon as they are discovered.
If you do all of this, are you completely secure?
Well, you are covering many security issues related to images, but not all of them.
Image scanning on admission controllers, a last line of defense
Manual deployments can still occur. For example, you may skip protocol to perform a manual deploy in a rush, or an attacker with access to your cluster could deploy images skipping your image scanner.
There are also rules that rely on Kubernetes-specific context. For example, if you want to restrict one image to a specific namespace.
That’s where implementing image scanning on admission controllers will come in handy.
It is a last line of defense with unique context. Remember, admission controllers run before anything is persisted.
There are several approaches to implement this strategy. The common idea is:
- The Kubernetes API calls a webhook before deploying any image.
- That webhook will check your security tool to see if that image follows your security policies.
- If the image is valid, it will be deployed. If not, it will be blocked.
What will vary between approaches is how the security tool handles the validation.
What happens if the security tool goes offline? Will it block all deployments until it goes back up? Will it allow all deployments? Ideally, all policies should be cached in the webhook so you are always protected.
Are policies shared between image scanners? As they say, one with two watches is never sure of the time. If you use one scanner on CI/CD and a different one for the admission controller, you need to take extra steps to ensure they are applying the same security policies. Simplify things by using the same image scanner everywhere.
When does the scan take place? Scanning all of the images right on deploy can take too long. If you already scanned an image recently, you shouldn’t be scanning it again, right? However, not all security tools support this use case.
How are the scan results reported? The scan results are valuable information. Reporting on them can help you monitor your compliance posture, and can also help your team identify vulnerabilities in running containers that have a fix available. Look for tools that provide extra value.
Implementing image scanning on admission controller with open source
There are plenty of open source alternatives if you want to go the DIY route for Image scanning.
For example, the Anchore image scanner provides its own admission controller webhook.
As with any open source solution, this approach will give you full customization capabilities and the ability to integrate with a wide variety of security tools.
You can integrate Anchore with Falco to generate alerts if someone tries to deploy a vulnerable image.
You can also do some validation with OPA Gatekeeper. After all, you might be already using OPA to define your cluster’s policies with rego rules. OPA can access the image metadata, and block deployments of images from certain registries into specific namespaces. You will need to manually integrate OPA with an image scanner to cover all the use cases we present in this article.
Take a look at this reddit conversation for more alternatives.
Some cons of a DIY approach:
- Customization comes with the cost of integrating and maintaining the solution all by yourself.
- By default, the scans will be performed on every deployment, as the Anchore open source image scanner does not track what images are already scanned.
- You will also have to DIY extra features like managing the admission policies, monitoring the compliance position, or creating reports.
Implementing image scanning with the Sysdig Admission Controller
On Sysdig, we believe that simplicity is the best way to make a security feature mainstream.
The Sysdig Admission Controller follows that principle, and we hope it brings some inspiration for your DIY implementation or that you find it interesting enough to give Sysdig Secure a try.
This new version of the admission controller adds enforcing to detection and reporting. After a quick installation and a simple configuration on our UI, the images in your cluster will be secure by default.
What sets this admission controller apart are key details like:
Images don’t need to be re-scanned. The Sysdig backend can speed up the admission controller for faster deployments, as it centralizes all of your scan results. If an image has been scanned recently, you can skip scanning on the admission controller.
You can reuse your existing scanning policies. This ensures consistency between scans done in different steps of the image life cycle. Also, you can build admission policies with an amigable UI.
It’s failproof. If your webhook loses connection with the Sysdig backend, it can still apply the scanning policies.
And it also ships with all the trademark Sysdig perks: It is easy to install, you can map compliance controls to scanning policies, you can create vulnerability reports, and it is a single pane of glass for all of your cloud infrastructure security.
Conclusion
You need to implement image scanning in all the steps of an image life cycle to ensure the security of your Kubernetes cluster.
Image scanning on admission controller is just one more piece of the puzzle. It allows you to implement policies that rely on the Kubernetes context, and it protects you from manual deploys that bypass your controls.
There are several open source tools that you can use to implement this solution, although you will have to build some features yourself, so there’s no excuse not to implement image scanning on admission controller for your cluster.
The Sysdig Admission Controller is a simple and complete solution to this problem. It leverages Kubernetes native controls, and the power of the Sysdig platform, to give you the visibility you need to secure your Kubernetes cluster. You’ll get started in minutes. Try it now!