Container Security

Overview

Adopting a container-based platform is the primary way development teams are streamlining their work and implementing secure DevOps. Pulling down a publicly available container image saves a lot of image preparation time. Automated toolchains also enable teams to develop and deploy innovative new apps more quickly, delivering frequent updates to customers.

Safeguarding data associated with those apps is critical. While app developers may understand the general need to add safeguards, they are not necessarily security experts. Today, addressing complex security challenges means enabling developers to seamlessly build security into their creations without delaying (or derailing) the DevOps process.

Offerings

Though a public software image is convenient to re-use, you don’t know what’s in it. Trusting the uploader is a risk that is bound to compromise app data at some point. Is the time it takes to verify that a public image is free of vulnerabilities greater than the time saved in building the image yourself?

Since there’s really no substitute for scanning every image before releasing it into the DevOps pipeline proper, expect any cloud platform to provide an efficient way of doing it. IBM Cloud Container Service, for example, offers a Vulnerability Advisor (VA) scanning tool that operates on images in repositories, and in both static and live containers. Alerts are tiered and make recommendations.

VA inspects every layer of every image in a cloud customer’s private registry to help detect vulnerabilities or malware before image deployment. While that’s a good start, to catch problems like drift in from static to live containers, VA also scans running containers for anomalies.

Other VA capabilities include:

Policy violation settings
With VA, administrators can set image deployment policies based on three types of image failure situations: installed packages with known vulnerabilities, remote logins enabled, and remote logins enabled with some users who have easily-guessed passwords.
Best practices
VA currently checks 26 rules based on ISO 27000. Checks include settings such as password minimum age, minimum password length and remote logins enabled.
Security misconfiguration detection
VA flags each misconfiguration issue, provides a description of it and recommends a course of action to remediate it.
Threat rating system
VA pulls in security intelligence from five third-party sources and uses criteria such as attack vector, complexity and availability of a known fix to rate severity. The rating system (critical, high, moderate or low) helps administrators quickly understand which vulnerabilities need priority action.

Challenges

To start, containers present attackers with a larger attack surface to target. Containerization has specific structural and operational elements that require special attention, mainly the underlying shared kernel architecture of containers that beyond securing the host requires maintaining standard configurations and container profiles.

Then there is the issue of a lack of visibility which can obscure vulnerabilities and prevent proper planning for remediation activities. In containerized environments, images are constantly added to the organization’s private registry or hub, and containers running the images are spun up and taken down. This flux of alternating runtimes means that images or containers that are not in use at the time of a scan at the Kubernetes stage will be harder to identify. Therefore it necessitates performing container security scanning at earlier stages of the build process if we want to be sure that nothing is missed.

Suggestions

Working securely with containers comes as a part of a wider development and ops security strategy that looks to implement viable practices, especially as more of the development and deployment moves to the cloud.

To verify the validity of sources of images pushed to public and private repositories, we have to sign them with a digital signature. For example for Docker, you should use Docker Content Trust (DCT), while Microsoft has their Shared Access Signature (SAS).

The aim of the digital signature technology is to deploy a signing and encryption system that is reliable on both ends of the network so that security over the network is not an issue.

Running a process inside a container is quite similar to running it from within a VM. Just as you would not use a root user in an application process, the same idea is relevant to containers as well.

The general recommendation here would be to simply run the process as a user with a known uid, and not as root. This will make sure that access will be limited for that user only. Our goal here is that it is not only secure by default, but it is also easier to keep secure going forward. You can assign different permissions to different users, and make sure you have stable role-based access to your containers.

Vulnerabilities are an inevitability in software development. However, with the proper tools, the risks to your products can be tracked and managed. By performing container security scanning at all stages of the SDLC, including in the container registries and the deployment orchestration, your operations teams can gain a clear understanding of what is inside your container, providing you with a bill of materials for the container image and information on any known vulnerabilities are discovered there.

For example, in Docker hub, you can get automated insights that will improve your organization’s ability to meet your compliance requirements and prevent security breaches.