Containerization. Another one of those tech buzzwords folks love to say but often have no idea what it means. A better way to organize children’s toys? The act of bringing tupperware out to dinner to safely transport home leftovers? Another name for Russian dolls?
Containerization is, of course, none of those things. But its definition might be best captured in a quick example rather than a description:
Eliza wrote a program on her Windows PC to streamline workflow between her department, a second department within the company, and a third outside agency. She carefully configured the software to eliminate unnecessary steps and enable low-friction sharing of documents, files, and other assets. When she proudly demoed her program on her manager’s desktop Mac, however, it crashed within seconds—despite working perfectly on her own machine.
Containerization was invented to tackle that problem.
What is containerization?
In traditional software development, programmers code an application in one computing environment that may run with bugs or errors when deployed in another, as was the case with Eliza above. To solve for this, developers bundle their application together with all its related configuration files, libraries, and dependencies required to run in containers hosted in the cloud. This method is called containerization.
The goal of containerization is to allow applications to run in an efficient and bug-free way across different computing environments, whether that’s a desktop or virtual machine or Windows or Linux operating system. The demand for applications to run consistently among different systems and infrastructures has moved development of this technology along at a rapid pace. The use of different platforms within business organizations and the move to the cloud are undoubtedly huge contributors to this demand.
Containerization is almost always conducted in a cloud environment, which contributes to its scalability. While some of the most popular cloud services are known for data storage—Google Drive, iCloud, Box—other public cloud computing companies, such as Amazon Web Services, Oracle, or Microsoft Azure allow for containerization. In addition, there are private cloud solutions, in which companies host data on an enterprise intranet or data center.
The difference between containerization and virtualization
Containerization is closely related to virtualization, and it often helps to compare and contrast the two in order to get a better understanding of how containerization can help organizations build and run applications.
Containers, unlike virtual machines (VMs), do not require the overhead of an entire operating system (OS). That means containerization is less demanding in the hardware department and needs fewer computing resources than what you’d need to run the same applications on virtual machines.
Organizations could even opt to share common libraries and other files among containers to further reduce the overhead. Sharing of these files happens at the application layer level, where VMs run on the hardware layer. As a result, you can run more application containers that share a common OS.
VMs are managed by a hypervisor (aka virtual machine monitor) and utilize VM hardware (1) while containerized systems provide operating system services from the underlying host and isolate the applications using virtual-memory hardware or (2) the container manager provides an abstract OS for the containers. This method eliminates a layer and in doing so, saves resources and provides a quicker startup time, when necessary.
Why use containerization?
There are a few reasons why organizations decide to use containerization:
- Portability: You can run the application on any platform and in any infrastructure. Switch to a different cloud supplier? No problem.
- Isolation: Mishaps and faults in one container do not carry over to other containers. This means maintenance, development, and troubleshooting can be done without downtime of the other containers.
- Security: The strict isolation from other applications and the host system also results in better security.
- Management: You don’t have to think about the effects on other applications when you update, add further developments, or even rollback.
- Scalability: Instances of containers can be copied and deployed in the cloud to match the growing needs of the organization.
- And last but not least, cost effectiveness: Compared to virtualized solutions, containerization is much more efficient and it reduces costs for server instances, OS licenses, and hardware.
Security risks for containers
Since containerization started out as a means for efficient development and cost savings and quickly ballooned in adoption and implementation, security was unfortunately a low priority in its design—as it often is in tech innovation.
Yet containers have a large attack surface, as they tend to include complex applications that use components which communicate with each other over the network. To the standard vulnerabilities introduced by various application components, add other security gaps created by misconfigurations, which result in inadequate authorization issues. These vulnerabilities will not be limited to the top layer of the application.
Add to these vulnerabilities the limitations of some security vendors, whose enterprise programs may not be able to protect containers running in the cloud environment. Due to the isolated nature of the containers, some security solutions may not be able to scan inside active containers or monitor their behavior as they would when running on a virtual machine.
Containers’ security postures are further weakened by a likely lack of awareness by their users about these limitations, which might encourage less stringent oversight. However, there are already prime examples of threat actors taking advantage of containerization developers’ security indifference.
On November 26, ZDNet reported that a hacking group was mass-scanning the Internet looking for Docker platforms with open API endpoints to deploy a classic XMRig cryptominer. What’s worse is that they also disabled security software running on those instances. Containerization users must take care not to leave admin ports and API endpoints exposed online, otherwise cybercriminals can easily wreak havoc. If they were able to install cryptominers, what’s to stop them from dropping ransomware?
Security recommendations
In order to shore up containers so that applications can both run efficiently and bug-free in diverse environments and remain secure, there are a few simple pieces of advise developers and operators should keep in mind.
Probably the most important: When copying the runtime system, developers, managers, or operators will need to check whether the latest patches and updates have been applied for all components. Otherwise, programmers could copy outdated, insecure, or even infected libraries to the next container. One common piece of advice is to store a model container in a secure place that can be updated, patched, and scanned before it is copied to work environments.
Second: When migrating a container to a different environment, the operator will have to take into account the possible vulnerabilities in both the container and new environment, as well as the influence of the container’s behavior on the new environment. Despite its portability, the container might require additional demands for safety measures or configuration of the container management system.
The rest of containerization’s security efforts can be summed up in a few short bullets:
- Check for exposed endpoints and close the ports, if there are any.
- Limit direct interaction between containers.
- Use providers that can assist with security know-how, if it’s not available in house.
- Use container isolation to your advantage, but also be aware of the consequences. Configure containers to be read-only.
- If available, use your container orchestration platform to enhance and keep tabs on security.
- Consider security solutions that can scan and protect containers in the cloud working environment if your current provider is unable.
These extraneous security measures might feel counterintuitive, as developers originally set out to have standard containers that behave the same way in every environment and for every user. But they are minor, simple steps that can go a long way in protecting an organization’s data and applications.
Therefore, use containerization as it suits best, but always keep security in mind.
