Cloud Native Security Best Practices: Using Kubernetes Admission Controller for Image Assurance
With cloud native technologies quickly evolving and with their high adoption rate, security practices are falling behind, are not being fully applied, and in some cases, applied too late. As a result, customers pay a high, albeit avoidable price. Aqua Cloud Native Security Platform uniquely addresses these challenges and in this blog we will discuss a critical Aqua CSP feature in securing the application pipeline, the Aqua Kube Enforcer.
As a solutions architect, I often talk to customers and prospects about their digital transformation. Nowadays, cloud native applications, containers and Kubernetes are top of mind to most customers, because they need to rapidly develop, ship, and run applications. Customers want to control where their applications are running and to be able to easily switch between infrastructures and cloud providers, or to release updates within seconds or multiple times a day.
As with traditional applications, it is important to apply and enforce security policies and standards as organizations move to cloud native approaches. However, traditional security solutions do not cut it any more for cloud native, and the processes are not optimized for the new unknowns. This is why security teams need to be involved in the development process long before the applications are deployed.
Frequently, I find customers only focused on vulnerability scanning. While this is a good start, without automatically enforcing a policy that determines which images are allowed to run, based on the scanning results, those results might remain “for information only” and the risk they present will not be addressed.
There are numerous security aspects that need to be considered and addressed by a complete cloud native security solution, such as Aqua CSP. In this blog I will discuss a core Aqua CSP component—the Aqua Kube Enforcer.
kube-enforcer: Aqua CSP’s Admission Controller
The Kube Enforcer is Aqua CSP’s Admission Controller. The Kube Enforcer ensures that only scanned, non-compromised or compliant images are used in your environment.
You may ask, “how do I define compliant and non-compliant images?” This is a great question, and the answer is the Aqua image assurance policy.
The Aqua Image Assurance covers the first part of the container lifecycle: image development and deployment. The Image Assurance component detects, assesses, and reports security issues in your images. Next, Aqua provides different forms of risk management, based on your preferences:
- Aqua can block the deployment of containers based on images with security issues
- Alternatively, it can help you mitigate the risk of deploying such containers that are based on images with known risks
Image Scanning with Aqua CSP
During the image scanning process, the product scans for vulnerabilities in operating system packages and programming language files. Once identified, compare the vulnerabilities against the threat intelligence of known open-source vulnerabilities. Additionally, the product scans for malware, detects sensitive data such as private keys, and certificates and also enables you to define custom compliance checks. The results are then compared against the Image Assurance policies for compliance. Think of the image assurance policies as a compliance gate that includes multiple control options, for example, Sensitive Data, Malware, Approved Base Images, OSS Licenses Blacklist/Whitelist, Required Package version and custom compliance checks. When the scan is complete, you know exactly if an image is in compliance with the assurance policies, and if vulnerabilities were identified, you can review the relevant vendor and NVD information, and learn how to fix it. Learn more about Best Practices for Vulnerability Management.
As well as scanning images and providing a detailed, actionable summary report, Aqua CSP also assigns a unique identifier to the images when they are instantiated. The unique identifier ensures the Admission Controller can verify the images are compliant with the assurance policies and that they are the same images scanned earlier in the pipeline.
Aqua CSP Admission Controller leverages a built-in capability in Kubernetes. Read more about the Kubernetes admission controller.
The following is an example of the validating webhook configuration that registers Aqua CSP’s Admission Controller with Kubernetes API server.
Hint: Aqua CSP offers a layered security approach with multiple enforcement gates. If you are not using Kubernetes as the orchestrator to block unregistered or non-compliant images, the Aqua Enforcer will block non-compliant containers on the container runtime level.
Aqua CSP Admission Controller in Action
Now, let’s see Aqua CSP’s Admission Controller in action. In my example, I’m using a PostgreSQL9.5 image, that contains sensitive information such as the ssl-cert-*.key.
First, I scan the image and check the findings against my Docker Hub Image Assurance Policy.
In the Docker Hub Image Assurance Policy I have activated the sensitive data control option.
After the scan process is complete, I receive a detailed report with all the relevant information of the identified risks.
I can see detailed information about the risk and where it was found.
Next, I define a runtime policy and activate the “Block Non-Compliant Images” control option.
Now that the runtime policy is enabled, I will attempt to deploy a non-compliant image, using the postgres.yaml file.
Aqua CSP blocks the deployment, as expected.
Aqua CSP’s Admission Controller blocks the deployment, returns an error in the CLI and logs a detailed audit event. You can also forward events to SIEM and analytics tools like Splunk, Elasticsearch, and much more.
Let’s take a look at what takes place behind the scenes. First, Aqua CSP’s Admission Controller receives the request from the Kubernetes API Server via Webhook Config, which is authenticated and authorized. Next, the component checks the status of the image for compliance, as specified in the postgres.yaml file, and blocks the deployment of the non-complaint image.
In summary, here are the key learnings we have covered for the Aqua CSP Admission Controller:
- Aqua CSP Kube Enforcer is a component that intercepts requests to the Kubernetes API server prior to persistence of the object, and after the request is authenticated and authorized
- Aqua CSP Kube Enforcer is an optional enforcement point for Aqua CSP. It is implemented as a Kubernetes Admissions Controller, and inspects Kubernetes commands against assurance policies in Aqua
- Aqua CSP Kube Enforcer sits on the cluster, listening for calls from the Kubernetes API Server
- Aqua CSP Kube Enforcer stops the creation or updates of pods, if they contain images that are not registered, or non-compliant with the image assurance policies
- Aqua CSP Kube Enforcer requires no special permissions as it is a web server that runs in a non-root user context