Containers: Benefits, Vulnerabilities and Security Measures
About UsConferencePartner With Us
CIOREVIEW >> Virtualization >> NEWS

Containers: Benefits, Vulnerabilities and Security Measures

CIO Review

Approach towards implementing virtualization was traditionally based on creating VMs on top of hypervisors that allocated hardware resources. Hypervisor based virtualization imparts the ability to host multiple Operating Systems (OS) on a single server without the need to modify the OS or applications to run on the virtual environment. This approach wherein the guest OS and the host OS run their separate kernel (program that constitutes the central core of the OS) provides a strong level of isolation and security. However, when organizations do not have the need to run different types of OSs a top of a single platform, the Hypervisor approach would constrain virtualization performance.

For Instance, duplicating 100 identical OSs’ on the same hardware would mean generating 100 separate copies of kernel and other root software stack to run the guest OS which evidently translates to wastage of time and resources in terms of RAM and CPU cycles. Containerization aka OS based virtualization removes this ‘barrier’ by enabling to share the kernel with the host OS resulting in almost zero performance overhead. Unlike VMs, containers use the OS's system call interface. Miles Ward, Global Head of solutions for Google's Cloud Platform, says “containers can boot up in one-twentieth of a second. Containers thus enable packing a lot more applications into a single physical server than a VM making it all the more easier for application deployment and testing.” Google, for running search operations launches about 7,000 containers every second, which amounts to about 2 billion every week. Container environments like Kubernetes, Docker, Rocket, Core OS, Joynet and LXC(Linux Containers) to name a few, makes it simpler to create and manage containers and are getting better through every release and update.

Stay ahead of the industry with exclusive feature stories on the top companies, expert insights and the latest news delivered straight to your inbox. Subscribe today.

Comparing Containers and Virtual Machines

Owing to their resource-saving approach as opposed to hypervisor/VM, containers are booming in popularity among organizations and market trends now indicate a large scale migration from VMs to containers. The interest towards container technologies have seen a sharp increase in general owing to their advantages, and popularity which in parts can be attributed to its value as well as hype. It is estimated that two out of every three firms that try containers proceed to adopt it, with Docker being the most popular choice of container environment.

The relatively new container technologies are yet to gain a level of maturity as that of VMs/Hypervisors. Just as any new entrant in the tech scene they too have faced limitations in the availability of tools needed to monitor and manage them which over the years have been rectified vastly. Containers could never render the former approach obsolete (at least as of now). Choosing between containers and VMs thus depends on the type of process. Take testing for instance, Hypervisors approach may be suited for checking cross platform compatibility where as a container approach is more suitable for testing various versions of the application on the same platform.

Applications offering micro services tend to be more suitable to run on containers as opposed to hefty monolithic applications. However, Google’s multi-container management system which now forms the open source Kubernetes Project helps build a cluster to run containers, providing networking and a container-naming system that enables managing many containers at once which allows running big applications in multiple containers across many computers without the need to know all the ins and outs of container cluster management. It is up to the enterprise to identify a suitable virtualization approach by experimenting on both.

Security Concerns

Containers function in the form of layers created on top of base images which may be created by anyone and shared across repositories. Layering helps to easily rollback changes by simply switching to the old layers with almost no overhead. However, the container architecture makes it possible for malicious code to escape from a container and gain access to host OS or other containers in the system. Container images may be created by anyone and shared across official and unofficial repositories. Poisoned images or those tampered by attackers are a security concern for containers. If a container image has full user privileges, intruders can break through from the containerized environment to the underlying platform and retain privileges. According to BanyanOps, a container technology company, more than 30 percent of containers distributed in the official repositories have high priority security vulnerabilities and jumps to about 40 percent outside official repositories.

Another concern that may root from the framework of container technology is Denial of Service (DoS) wherein if one container (manipulated by attacker or otherwise) could monopolize access to certain resources–including memory or user IDs, it can starve out other containers on the host resulting in legitimate users being unable to access part or all of the system.

Containing Container Vulnerabilities

From a security perspective, it is strongly recommended not to set enhanced privilege for virtualization containers. If at all containers require privileges to be raised, it has to be ensured that they are reverted. For instance, majority of containers do not need root privileges as services that require them should already be running outside of the container as part of the underlying platform. Running containers with reduced privilege is in turn a protective measure as it causes the container to deny any mount requests, deny file creation or attribute change activities, prevent module loading. Enabling abstraction using specialized namespaces is another method of container isolation. They should also be provided with their own network stack avoiding any privileged access across different containers to physical ports. APIs being integral parts of containerized environments calls for API management and monitoring tools; small errors in API calls could as well pave way for intrusion.

Running containers on top of a hypervisor/VM is an option worth considering as it would establish a secure boundary for containers whilst avoiding conflicts and enhancing redistribution. But as intriguing as it may sound, it is regarded a rather complex set up to maintain and sure comes with a minor performance penalty which include a setback to container’s higher hardware density and auto scaling features.

Addressing security and policy compliance, Docker has recently added the capability to sign container images using a hardware device, to scan container images for vulnerabilities, and to set up separate user namespaces to isolate environments which apparently circumvents through previously mentioned security challenges that container technology pose.

A Note on Container Environments

Although it is one among similar offerings, Docker has become synonymous with container technology. IBM has partnered with Docker for building and running applications on the IBM Cloud. On June 8th 2016 Microsoft announced that Docker now could be used natively on Windows 10 with Hyper-V Containers, to build, ship and run containers utilizing the Windows Server 2016 Technical Preview 5 Nano Server container OS image. Google has also offered adding in support for Docker containers on its Google Cloud Platform.

On the down side of Docker, a movement to boycott Docker is underway on grounds that it masks plenty of loop holes which apparently cause unsuspecting clients to end up in situations like vendor lock-in and slewed network. The movement lays down points to argue that much of the Docker platform is hyped and the reality is barren. Details about an ongoing case against Docker are also laid out. In such a state of uncertainty, especially among enterprises looking to ‘try out’ the technology, we encourage thorough research on other offerings. Choosing between containers and VMs is not an either-or proposition but an ‘if-this-then-that’ strategy; ironical to the if-else/do-while statements in programming languages.

More in News

Distributors can have plenty of inventory across their network and still struggle to meet demand at individual branches. Stock sitting in one warehouse does little good when customers need it elsewhere, while keeping every location stocked for its highest historical demand can tie up unnecessary capital. With thousands of product and location combinations to manage, purchasing teams cannot review every decision manually. Executives evaluating demand forecasting software need to know whether it can improve local product availability without driving up inventory costs across the business. Network-wide averages can easily hide costly gaps at individual locations. Past sales provide a useful starting point, but irregular buying patterns can make forecasting difficult. Slow-moving products may not generate enough transactions to produce a reliable forecast on their own. Seasonal spikes can also skew averages long after demand has returned to normal. Buyers should look at whether the software can draw insights from related products and distinguish recurring demand from unusual orders. External factors such as weather may also help improve predictions, but their value needs to be demonstrated for the products concerned rather than assumed across the entire catalog. Knowing what customers will buy is only half the equation. Buyers also need to know when to reorder. Changing supplier lead times can make it difficult to act on even an accurate demand forecast, while order frequency and minimum purchase quantities affect how much stock needs to be kept on hand. Software should account for actual purchase order history rather than rely solely on fixed lead times. Safety stock should also reflect how individual products sell at each location. Applying the same buffer everywhere can leave fast-selling products out of stock while slower-moving items pile up. “Lantern refreshes recommendations weekly and lets buyers compare suggested stocking levels with existing settings before approving or overriding them.” The way forecasting software works with existing ERP systems is another important consideration. If recommendations sit in a separate dashboard, buyers may still have to enter them manually into their purchasing systems. They should establish whether the software can read transactions from their existing ERP and feed approved stocking parameters or purchase orders back into it. Buyers also need to understand why the system recommends a particular change. When a business wins a new account or a branch receives an unusually large order, experienced staff should be able to override a forecast without having to work outside the system. Forecast accuracy matters, but it does not tell the whole story. Lower inventory means little if it leads to stockouts and unhappy customers. In some cases, holding more stock may be the right decision if those products sell consistently. Buyers should look at how the software affects product availability, inventory turns and the capital tied up in excess stock. Testing its recommendations against past transactions can also show where they differ from existing purchasing practices before a wider rollout. Buyers should also account for the work involved in preparing historical data and managing exceptions once the system is in place. Lantern builds a custom machine learning forecasting model for each distributor, using historical ERP data and business-specific purchasing practices. It combines demand forecasts with projected supplier lead times to recommend order timing and safety stock at the item-location level. Lantern refreshes recommendations weekly and lets buyers compare suggested stocking levels with existing settings before approving or overriding them. Approved purchase orders or stocking parameters can be written back into the ERP. Its models also examine relationships across products, supporting forecasts where individual sales histories are sparse. Distributors with large catalogs spread across multiple branches, especially those balancing excess inventory against missed sales, are the relevant buyers for this model. ...Read more
Enterprise imaging purchases rarely fail because a scanner cannot create a digital file. Trouble starts when document volumes and legacy applications collide with downstream workflows that were built around older processes. A platform may handle clean, standardized forms well, yet slow down when incoming files vary substantially or demand different routing rules. Executives, therefore, need to examine how completely a proposed environment can absorb the real document mix without forcing extensive manual preparation or creating new bottlenecks elsewhere. Capture architecture deserves close attention as the front end determines how much work remains after scanning. Useful systems should support classification, optical character recognition, data extraction and validation in ways that match actual document types and exception rates. Human review also matters. Automated recognition is valuable when confidence is high, but buyers should understand where validation screens enter the process and how questionable fields are routed before information reaches a database or content repository. Hardware choices belong in the same discussion. Desktop scanning and high-volume production work impose very different demands, and forcing both through a single equipment model can inflate costs or limit throughput. The proposed design should reflect actual preparation effort, peak intake volumes and the physical scanning environment rather than nominal device speed alone. Scanner flexibility also matters where several departments process different document sets at substantially different volumes. “EDAC Systems provides first-line support across the hardware and software it sells, reducing the need for customers to separate faults among multiple providers.” Legacy compatibility is equally consequential. Many enterprises still depend on older capture software and long-standing repositories while retaining scanners embedded in established processes. Replacing everything at once can increase implementation risk and budget pressure. A stronger proposal should account for migration and configuration from the outset, with integration planned around how existing records move into the new environment and how the changeover will be tested. Buyers should also examine whether the architecture can adjust when document volumes increase or automation requirements change without requiring a wholesale rebuild. That flexibility becomes more important when an organization expects its capture requirements to shift over several budget cycles. Security and records requirements can narrow the field quickly, particularly in government or regulated environments. Encryption and records-management controls need to be resolved against approved deployment conditions before installation, rather than treated as post-deployment configuration. Procurement teams should verify that both hardware and software satisfy applicable requirements and that the provider can work within on-premises or approved hosted environments when needed. Support after go-live is another practical separator. Document imaging environments combine scanners, capture software, connectors and repositories, which can leave customers coordinating multiple suppliers when something fails. Contract review should establish who owns first-line troubleshooting and whether hardware and software issues are handled through one support path. Availability of on-site assistance also matters when remote fixes are insufficient. EDAC Systems designs document imaging and data capture environments around each customer’s document types, workflow, existing technology and budget constraints. Its approach can combine Ricoh or OPEX scanning hardware with capture software and Doxis-based document or records management, depending on the application. It also handles migration, configuration, testing and training during implementation. It provides first-line support across the hardware and software it sells, reducing the need for customers to separate faults among multiple providers. For enterprises with mixed legacy environments, compliance requirements or varied document volumes, the breadth of design and support makes EDAC Systems a practical vendor to consider. ...Read more
Moving from Google Workspace or legacy Exchange to Microsoft 365 involves more than transferring mailboxes. File structures may not translate cleanly, account permissions can change and an overlooked dependency can interrupt access after cutover. Executives comparing migration providers must establish how thoroughly each one investigates the existing environment before committing to a transfer schedule. A technically completed migration offers little reassurance when employees cannot retrieve the information they previously used. Pre-migration assessment establishes the boundaries of the work. User inventories should account for inactive accounts and shared mailboxes, while file assessments must identify naming restrictions, excessive path lengths and permission structures that Microsoft 365 handles differently. Tenant-to-tenant transfers introduce additional complications around identity mapping and existing collaboration spaces. Providers should document these differences before migration begins rather than discovering them during execution. Compliance requirements can alter the migration design considerably. Retention policies and access restrictions may determine where information resides after transfer or which users can retrieve it. An assessment that concentrates exclusively on data volume risks overlooking controls that governed the original environment. Procurement teams benefit from examining whether the provider produces a documented migration scope connecting technical dependencies to the organization's internal requirements. “RyanTech incorporates Microsoft Defender and Purview into tenant planning, allowing security requirements to shape the destination environment before users begin working in it.” Cutover scheduling exposes a different set of risks. DNS propagation may take longer than anticipated, while network interruptions can delay synchronization during a planned transition. Promises of zero downtime leave little room for these external dependencies. A credible migration approach includes contingency procedures, defined escalation responsibilities and a cutover window that reflects the organization's working patterns. The provider should explain what happens when an expected transition does not occur on schedule. Business continuity also depends on what employees encounter after the switch. Missing shared files or unfamiliar permissions can generate support requests even when mailbox transfers succeed. Validation should establish that users can access the resources required for their work, not merely confirm that data reached its destination. Clear responsibility for resolving post-cutover issues reduces the burden on internal IT teams. Security configuration cannot be deferred until employees have settled into Microsoft 365. A newly provisioned tenant may introduce unfamiliar exposure through identity settings or insufficiently configured data protection policies. Microsoft Defender, Intune and Purview provide controls that can be incorporated into the destination design. Providers differ in whether they configure these protections during migration planning or treat them as later projects. Licensing decisions also influence which controls are available and whether organizations purchase functionality they will actually use. Support arrangements become particularly relevant once the migration specialists have completed their assignment. Changes to compliance requirements or user access may expose decisions made during the original transfer. Continuity between migration and support personnel helps retain that context. RyanTech conducts Microsoft 365 migrations through an initial environment audit that establishes customer requirements and informs a documented transfer plan. Its migration team prepares for DNS delays and other cutover interruptions, scheduling transitions around business requirements rather than promising uninterrupted service. RyanTech incorporates Microsoft Defender and Purview into tenant planning, allowing security requirements to shape the destination environment before users begin working in it. Its project and support teams subsequently address configuration changes, user adoption and evolving compliance requirements. Experience spanning Google Workspace, on-premises Exchange and tenant-to-tenant migrations informs its handling of differing source environments. Organizations consolidating disparate systems into Microsoft 365 while requiring security configuration and continuing technical support are particularly suited to this approach. ...Read more
The management of cloud environments involves the proper coordination of infrastructure, access rights and resource allocation as companies expand their operations digitally. In Latin America, organizations adopting cloud-based systems must account for regional data protection requirements, varying infrastructure capabilities and the complexity of overseeing multiple service providers. Cloud management is an effective tool that enables the IT professionals to control the workloads, ensure the standard configuration, resource consumption and detect the possible disruption of services that could impact critical business operations. Clear governance policies, automated monitoring and well-defined access controls can help businesses maintain reliable cloud environments while managing operational complexity. How Does Cloud Management Benefit Businesses? Cloud management makes it possible for companies to have more options when dealing with varying loads without making significant investments in infrastructure. Organizations can scale computing capacity to match project demands, support remote teams and deploy digital services across different locations. For companies operating in Latin America, this flexibility can help accommodate expansion into new markets while allowing technology resources to evolve alongside business requirements. The other significant benefit relates to visibility in finances. Centralized oversight helps organizations understand spending across cloud services, identify underused resources and select suitable service plans. These insights support more informed budgeting and reduce the likelihood of paying for capacity that delivers little practical value. Businesses can also evaluate service usage against departmental needs to allocate technology budgets more effectively. Cloud management can be an important tool to improve the continuity and collaboration of business operations. Backup planning, recovery procedures and coordinated service administration help organizations prepare for unexpected outages and restore essential applications when disruptions occur. Shared digital workspaces and accessible business applications can further support collaboration among distributed teams. For businesses in Latin America, these capabilities can help maintain consistent operations across regional offices while supporting day-to-day productivity. What Are the Emerging Trends in Cloud Management? Artificial intelligence is reshaping cloud management through intelligent analytics, predictive monitoring and automated decision-making. These tools can help IT teams identify unusual performance patterns, anticipate capacity demands and investigate potential technical issues before they escalate. In Latin America, growing interest in AI-enabled infrastructure management is creating opportunities for businesses to simplify complex technology environments while improving the speed and precision of routine IT operations. The other emerging trend is the increasing adoption of hybrid and multi-cloud solutions, which combine private infrastructure with public clouds and services offered by several different providers. FinOps approaches are another area where enterprises are increasingly focusing, which involves financial decision-making around cloud usage, along with security methods that keep a check on the risks to which access is exposed. For businesses in Latin America, these developments highlight the need for cloud strategies that balance technical flexibility, cost transparency, regulatory requirements and evolving cybersecurity risks. Together, these approaches are shaping a more intelligent and adaptable future for cloud management.  ...Read more