loading...

Kubernetes – Image repositories

Vulnerability management is a critical component of any modern day IT operation. Zero-day vulnerabilities are on the rise and even those vulnerabilities with patches can be cumbersome to remediate. First, application owners must be made aware of their vulnerabilities and potential patches. Then, these patches must be integrated into systems and code, and often this requires additional deployments or maintenance windows. Even when there is visibility to vulnerabilities, there is often a lag in remediation, often taking large organizations several months to patch.

While containers greatly improve the process of updating applications and minimizing downtime, there still remains a challenge that’s inherent in vulnerability management. Especially since an attacker only needs to expose one such vulnerability, making anything less than 100% of the systems patched is a risk of compromise. 

What’s needed is a faster feedback loop in addressing vulnerabilities. Continuous scanning and tying into the software deployment life cycle is key to speeding up the information and remediation of vulnerabilities. Luckily, this is exactly the approach that’s being built into the latest container management and security tooling.

Continuous vulnerability scanning

One such open source project that has emerged in this space is clair. clair is an open source project for the static analysis of vulnerabilities in appc (https://github.com/appc/spec) and Docker (https://github.com/moby/moby/blob/master/image/spec/v1.md) containers.

You can visit clair at the following link: https://github.com/coreos/clair.

clair scans your code against Common Vulnerabilities and Exploits (CVEs). It can be integrated into your CI/CD pipeline and run as a response to new builds. If vulnerabilities are found, they can be taken as feedback into the pipeline, even stop deployment, and fail the build. This forces developers to be aware of and remediate vulnerabilities during their normal release process.

clair can be integrated with a number of container image repositories and CI/CD pipelines.

clair can even be deployed on Kubernetes: https://github.com/coreos/clair/blob/master/Documentation/running-clair.md#kubernetes-helm.

clair is also used as the scanning mechanism in CoreOS’s Quay image repository. Quay offers a number of enterprise features, including continuous vulnerability scanning (https://quay.io/).

Both Docker Hub and Docker Cloud support security scanning. Again, containers that are pushed to the repository are automatically scanned against CVEs, and notifications of vulnerabilities are sent as a result of any findings. Additionally, binary analysis of the code is performed to match the signature of the components with that of known versions. 

There are a variety of other scanning tools that can be used as well for scanning your image repositories, including OpenSCAP, Twistlock, Aqua Sec, and many more.

Image signing and verification

Whether you are using a private image repository in-house or a public repository such as Docker Hub, it’s important to know that you are only running the code that your developers have written. The potential for malicious code or man-in-the-middle attacks on downloads is an important factor in protecting your container images.

As such, both rkt and Docker support the ability to sign images and verify that the contents have not changed. Publishers can use keys to sign the images when they are pushed to the repositories, and users can verify the signature on the client side when downloading for use.

This is from the rkt documentation: 

“Before executing a remotely fetched ACI, rkt will verify it based on attached signatures generated by the ACI creator.”

For more information, visit the following links:

  • https://github.com/rkt/rkt/blob/master/Documentation/subcommands/trust.md
  • https://github.com/rkt/rkt/blob/master/Documentation/signing-and-verification-guide.md 

This is from the Docker documentation:
“Content trust gives you the ability to verify both the integrity and the publisher of all the data received from a registry over any channel. “

For more information, visit https://docs.docker.com/engine/security/trust/content_trust/.
This is from the Docker Notary GitHub page:

“The Notary project comprises a server and a client for running and interacting with trusted collections.”

For more information, visit https://github.com/docker/notary.

Comments are closed.

loading...