Aqua is committed to help the container ecosystem deliver better and more secure code. We dedicate some of our resources to create and maintain open-source projects, as well as contribute to existing ones, including Moby and Kubernetes.
The CIS benchmark document is over 200 pages long, so it would be impractical to run through it all by hand. It includes tests that check the parameters on running Kubernetes executables, and permissions and ownership on config files, looking for settings that would leave a cluster vulnerable to attack.
kube-bench is written in Go, and takes YAML files for the test definitions so that it’s easy to customize the test suite if required. It can generate output in JSON format if required so that it’s easy to integrate into other automation tools.
Example of Kube-Bench results
Kube-hunter hunts for security weaknesses in Kubernetes clusters. The tool was developed to increase awareness and visibility for security issues in Kubernetes environments. You should NOT run kube-hunter on a Kubernetes cluster you don't own!
Run kube-hunter on any machine (including your laptop), select Remote scanning and give the IP address or domain name of your Kubernetes cluster. This will give you an attackers-eye-view of your Kubernetes setup.
You can run kube-hunter directly on a machine in the cluster, and select the option to probe all the local network interfaces.
You can also run kube-hunter in a pod within the cluster. This gives an indication of how exposed your cluster would be in the event that one of your application pods is compromised (through a software vulnerability, for example).
To get shareable, formatted reports, you can use our kube-hunter minisite - example below:
Trivy is easy to use - you only need to specify an image name for it to be scanned. You can also integrate Trivy into your CI tool (Jenkins, Bamboo, Travis CI, Circle CI, etc.) to embed vulnerability scanning as a step in your build.
Trivy provides exceptionally accurate results on Alpine, RHEL and CentOS. It also detects vulnerabilities in application dependencies (Bundler, Composer, Pipenv, Poetry, npm, yarn and Cargo).
Some metadata - like the build date, Git commit of the source code, or author - is available at the point where you build a container image, but there is other information - for example a vulnerability scanning report, contact details for the team, or QA status reports - that can change throughout the lifetime of the image after it has been built.
Manifesto stores metadata in the container registry alongside the image, so that you don’t have to set up a separate database or information store. For more info, read a step-by-step explanation on our blog.
Limiting the ability of a container to use up disk space is a useful performance and security capability, preventing the container from hogging disk space and interfering other container activity, which is sometimes referred to as a "noisy neighbor" scenario. For example, if the following is part of the code inside a container:
fallocate -l 5GB acme.iso
the container will attempt to get 5GB of disk space blocked. With no controls in place, this might cause serious deterioration or crash of the underlying host.
Implementing a quota prevents this from happening. The implementation utilizes XFS project quotas to set a hard limit on the disk usage of a container directory.