Containerization and Allied Security Issues

By CIOReview | Wednesday, April 19, 2017

Containers save a great deal for developers as they make available essential functionalities without launching a Virtual Machine (VM). With access to libraries and settings, containers allow developers to create applications in isolated environment and remove their dependence on non-pertinent pieces of operating environment. Containers trump VMs on many counts such as speed of application development and testing, ease of sharing, less management overhead, and zero dependence on hardware. Containerization also allow deployment of the applications physical devices, VMs, and bare metal servers.

Do Containers have Achilles Heel?

Primarily, the perception of developer community is that containerization is one of the secured ways to conduct application development. The developer community has faith in the level of security provided by the containers as there is zero linkage of applications to hardware and other parts of OS. However, developers should not overlook a scenario in which attackers gain leverage over one container and use it to eventually control other containers. Orchestration of chained attack is not the remotest possibility and the probability gives rise to a situation in which the attacker can gain access to data in target containers. To encounter these attacks, businesses must give utmost importance to maintain workload isolation. Containers can be prone to leakage prompting attackers to easily gain information about the state and operation of other channels. The attacker can break into the system further and access memory pages and subsequently the cryptographic keys.

In containers, APIs handle workload lifecycle management and utilize memory pages or device buffers. Usually, strict protocols are implemented to define access management, but any flaw in access management mechanism or lacunae in protocols can provide easy gateway for hackers and ill-intent users. The challenges grow further due to preference for cloud migration that leads to difficulty in maintaining the trustworthiness of container images. In an attempt to develop enterprise grade solutions, which are cloud native, implementing security measures remains a challenge. Finally, containers rely on the same OS Kernel, and thus, attackers can corrupt kernel and subsequently control hardware.

Containers hit a security roadblock when the companies are focused on releasing applications quickly. However, businesses can avoid security catastrophe if they adopt several measures that include isolation of file-systems, devices, and networks. They can also define resource consumption for each container and set their performance metrics.

Businesses adhere to several practices that range from network and endpoint security, but large enterprises find the implementation of security measures daunting.

The level of security offered by today’s container offerings

The saga of containers is incomplete without Docker. With numerous security features that safeguard information and processes via intrinsic security of the kernel, Docker provides support for namespaces and cgroups (Control groups). Namespaces are primary providers of isolation. Docker assigns separate network stack for each container and avoids access to the sockets or sockets of another container. Control groups are accountable for resource accounting, limiting and managers of memory, CPU, disk I/O. They also restrain every container from causing system crash due to over utilization of the previously stated resources. 

Next steps to be taken by the businesses

The container software arena is witnessing growing number of solutions aimed at improving container efficiency and security. Businesses should strategize solution deployment after thoroughly determining their requirements. They should calibrate threats that can arise from containerization and how they have been addressed by the offerings. The final call should be based on prudent examination of the business case of containerization.