Like most trends in our industry is, first we fall in love with how much faster or smarter they allow us to get things done. It is only later after we are hooked that we remember to implement security measures that will keep our products secure. Containers have been one of the hottest trends in recent years, yet it is only recently that container security scanning is starting to be raised as a necessity to be integrated.
However, containers do come with their own challenges to security that need to be addressed if we want to use them effectively and securely in our development.
The lightweight software packages that hold our code and its dependencies, containers are beloved for their interoperability across environments, making it far easier to build, test, and deploy from one stage to the next. A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries, and settings.
In the age of DevOps, containers are playing a significant role in making the flow of software through the development life cycle a smoother process, eliminating the bumps in the road that can cause unnecessary friction. Due to their independence from the confines of one operating system or the other, their self-sustained nature makes them a breeze to move from one environment to the next. They are also significantly less resource heavy, allowing teams to run more of them without the need for additional CPU power.
Often a game of inches, containers offer a few advantages on the security front that developers appreciate. As the default isolation capabilities are more advanced, containers are considered to have better security than say VMs. Applications in containers are essentially “locked” on their own, giving them a kind of segmentation by default so that the weaknesses in one application should not weaken applications in other containers.
However, these protections are far from foolproof. There is still a possibility of issues in one application interfering with another through their shared OS. Just to get a perspective on how impactful a vulnerability in an application can be, Docker uses resource isolation features of the Linux kernel such as cgroups and kernel namespaces to allow independent “containers” to run within a single Linux instance.
The reliance on Linux is not without its issues as well. In 2018, 180 vulnerabilities were found in the Linux Kernel alone. Such vulnerabilities can have devastating results for containers if security scanning is not carried out as part of your standard practices.
Below are some of the primary challenges that are important to consider.
Despite the advantages offered by containers, their use comes with challenges that need to be taken into account.
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.
Add to the mix the speed of DevOps, often without the necessary precautions of DevSecOps being implemented. According to a recent report by Hewlett Packard Enterprise, while automation and team integration could lead to greater adoption of application security in the future, the current state is that most organizations are not implementing container security scanning within their DevOps programs.
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.
In the interests of providing actionable steps that you can get started on, we have pulled together our top tips.
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.
As a general reminder, the best way to ensure that your container development processes are covered security-wise is to stick to the tried and true DevSecOps approach of automation. You should utilize automation to detect builds with issues and to trigger rebuilds, reducing some of the peskier of manual tasks that can hold up your deployment.