Getty Images
The importance of Kubernetes vulnerability scanning
New to containerization and Kubernetes? Here's what the dev team should know about container image scanning, container file scanning and Kubernetes manifest scanning.
Software engineers know that, when a new technology is being adopted, an organization typically prioritizes the proof-of-concept work and testing, while security considerations come later. With the shift-left movement and security being top of mind for most CIOs and CTOs, engineers need to be sure they consider security right from the start.
When containers are involved, developers and testers should focus on three primary vulnerability scans:
- Container image scanning.
- Container file scanning.
- Kubernetes manifest scanning.
Implemented correctly, these efforts should mitigate security risks at the application level.
Because containers are virtualized OSes, their footprint is incredibly small. You can create one in seconds. Engineers can simply go to Docker Hub and pull a container image from an official repository, such as Ubuntu or Nginx. Engineers can orchestrate the container image with Kubernetes and deploy it via a Kubernetes manifest.
During this process, you need to ask some key questions:
- Were security best practices used?
- Are there vulnerabilities in the container image?
- If the container image was scanned, what database is being used? Is it from the National Vulnerability Database (NVD) and utilizing the Common Vulnerability Scoring System (CVSS)?
- Are the Kubernetes manifests formatted and built the way security teams are expecting from a policy-as-code perspective?
Container image scanning
It is possible vulnerabilities leak in during CI. To ensure every security point is considered, scan container images after they are built. Tools such as Checkov and Snyk enable this.
For example, use the docker scan command, which uses Snyk on the back end, to scan a container image. The value of the Secure Hash Algorithm-256 cryptographic checksum can then be checked against the container image registry to confirm that the container image being used is accurate.
Another tool to consider is JFrog Xray, which automatically scans container images that are based off the NVD and enables engineers to choose a CVSS score. Set it to scan the container multiple times per day to ensure it is secure.
Container image scanning can also benefit from Open Policy Agent (OPA), which is a general-purpose policy agent that can be used to enforce policies of individual choice. A lot of policy-as-code tools use OPA as the general standard when enforcing rules. For example, Red Hat's OpenShift Container Platform uses OPA policies for advanced cluster security.
Container file scanning with Dockerfile
As part of the security process, engineers should use container file scanning. Engineers can build container images with Dockerfiles, which typically consist of the following:
- Base container image.
- Application that's going to be embedded inside the container image.
- Specific ports and files that are needed for the application to run.
- Startup command for the application running inside of the container image.
That said, things can go wrong with a Dockerfile. To ensure the Dockerfile properly works, think: Is the base image secure? Is the application that's being used in the container image compromised in some way? Are there relevant flaws to be found in the NVD?
Tools such as Checkov and Snyk help scan Dockerfiles during the CI process of building the container image. That way, if there are any known vulnerabilities, the CI process should fail, preventing the container image from reaching the CD stage of deploying the containerized application.
Helpful tools
IT teams working with Kubernetes and containerization should look at the following tools for help in keeping their container images and files secure:
- Snyk.
- Kubeval.
- Hadolint.
- Checkov.
- Kube-score.
- JFrog Artifactory Xray.
Kubernetes manifest scanning
Orchestration comes after containerization of an application. The container image is typically used via a Kubernetes manifest, but even Kubernetes manifests can have vulnerabilities from policy-as-code, static code analysis and linting perspectives.
Kubeval, a popular linter, validates one or more Kubernetes manifest configurations. It's often used as part of the local development or the CI phase. Kubeval can also work on Helm charts.
Also, Kube-score performs static code analysis on Kubernetes manifests. There are many checks that Kube-score performs; notably, it can help with the following:
- Set container limits.
- Find where container images wrongly use the latest tag.
- Ensure readiness probes aren't identical to liveness probes.
- Check that deployments and StatefulSets have a PodDisruptionPolicy.
