Container Compliance and Security: Beyond Vulnerabilities

One trend as you look at the container market is stronger emphasis on the security of containers. Most of this emphasis is in regards to shipping software with known vulnerabilities in your container images, such as software that’s distributed as part of your Operating System. There have been a few different studies performed, one over a year old that showed 80% of official images contain a vulnerable piece of software, and a more recent (and smaller study) that shows 24% of official images contain vulnerable software. For obvious reasons, this is a troubling trend. Couple this with with a more recent survey that shows 80% of companies aren’t even scanning images for problems, and you definitely have a situation where companies are opening themselves up to problems in the future.

One thing lost in this talk of vulnerabilities is that vulnerability assessment is just one aspect of security. You can deploy software with zero known vulnerabilities and still open yourself up to problems by shipping software that is misconfigured. Even if you’ve minimized your operating system footprint in your container, you still want to ensure that you are following the recommended practice for configuring the software that runs your applications.

We recently published a blog post that showed how you can check your docker hosts for misconfiguration with Chef’s open source project InSpec. As we mentioned in that post, you can also scan your Docker containers for misconfiguration as well. Chef publishes a variety of different profiles for you to get started with on the Chef Supermarket. Here are some easy things you can begin checking with InSpec to improve your container security hygiene.

Shipping Build Tools

Believe it or not shipping build tools (gcc, make, etc) is still a common problem when building containers. While your attack surface is very different when running containers, it’s still a good idea to decouple your application build from the run. At the very least, you’ll reduce the size of your container and avoid shipping software you don’t need. On the extreme side, you won’t be leaving tools around that could help an attacker once they are in your environment. InSpec provides resources for checking for installed packages.

pkgs = [ ‘gcc’, ‘make’, ‘g++’]

pkgs.each do |pkg|

 describe package(pkg) do

   it { should_not be_installed }

 end

end

Misconfigured SSL

You might think your data is automatically secure in transit because you’ve enabled SSL, but are you still using old versions of SSL or TLS protocols that have been declared insecure? Are you using weak ciphers that may make it easier to decrypt your data? If you’re shipping an application that leverages SSL, you’ll want to check your configuration before shipping to production. OWASP provides a handy guide on how to secure SSL, and Chef provides an InSpec profile that that helps you get started securing SSL.   

Shipping Credentials

While it should be obvious why you shouldn’t ship credentials embedded in a container, it still happens, especially in an organization where containers are new to them. You can help your developers by using InSpec to check their configuration files, directories, etc to ensure that credentials don’t accidentally leak into a container. You can also use InSpec to insure that credentials aren’t being set in environment variables, another common new user mistake.

Shipping Insecure Configurations

InSpec has built in support to parse many common configuration file formats. This is useful to verify that your application is configured correctly, and you’re not accidentally turning off things like authentication for your database. You can find the full list of configuration files InSpec supports in the InSpec documentation.

InSpec provides many resources to verify your applications in your containers are configured correctly, and securely. It’s easy to incorporate InSpec into your container image build process, and have it run to verify your container images before you ship them. Even if you haven’t added in a full container image scanning tool into your container build pipeline, incorporating InSpec can provide some basic level of confidence in the container images you’re shipping.