As containers evolve into the default foundation for modern applications, IT leaders must expertly secure workloads while ensuring that they’re easy to manage and designed to withstand failure.
IBM has been a pioneer of containers as a service within a cloud environment since the very early days of Docker. Here are two ways IBM Container Service is supporting users at every step.
Any organization that’s committed to a container strategy will inevitably have containers running as a distributed system within a public cloud environment (likely as part of a hybrid cloud strategy spanning both on- and off-premises cloud resources). Security is always a major concern in those circumstances, especially considering that container use is still relatively new.
One perceived risk is that another customer’s container could break out and gain access to your data. How can users protect themselves from these types of security issues?
Some vendors will suggest that you must run containers within VMs to ensure isolation. This is simply not true in all cases.
You could deploy highly secure containers on the IBM Container service. We manage and secure the underlying hosts for you, ensuring you get the highest level of security without the burden of securing the hosts yourself. IBM developed the support for namespaces in Docker containers, which are used actively in the IBM Container service to ensure that tenant containers appear to be running as root. Really, they are running in a protected and limited access namespace. We have also implemented monitors and tools to protect against denial-of-service attacks. There are many more host level settings to protect tenants and ensure the highest level of security.
There are other vulnerabilities that may result from the software packaged into your containers. Any application can get hacked. That’s just a reality of the technology. The question becomes: what can be done to ensure that your container isn’t hacked?
That’s where the IBM’s Vulnerability Advisor comes into play. Vulnerability Advisor actively scans all images pushed to the image registry hosted in the IBM Container service. Every tenant gets his or her own isolated, private image registry as part of the service. Scan results are published in the IBM Bluemix catalog with your images so you can easily view violations that were detected. Vulnerability Advisor goes one step further and provides a policy management capability that enables the admin of the organization to set runtime policies. For example, the admin may decide to block any image from being deployed as a container. Such policy enforcement actions further improve your application security profile.
When we talk about containers and orchestration, we must look at two different facets. There’s scheduling of containers onto hosts, and then there’s orchestration of the containers themselves.
Many Docker tutorials start by teaching you how to run containers on your laptop. This is a great educational approach, but the reality is that all production-level systems will run as multiple containers across many hosts. It may seem obvious, but it’s worth noting that deploying and managing containers across many hosts is a more complex endeavor than running containers on a single host. Having multiple hosts provides greater computing power to scale your solution and run numerous containers.
When you have multiple hosts, you have to deal with scheduling those containers on the hosts (i.e., placing containers on the hosts within your pool). It seems simple, but you must ensure that the placement takes into account resource allocation across hosts to avoid overburdening a single host. You should also take into account the proper scheduling of containers when hosts are added or removed from the pool.
Once you’ve determined where to place your containers for the utmost efficiency in your host environment, you must determine how you’ll automate the deployment of your containers. Many customers deploy multi-container systems (especially for production systems).
With any highly distributed system, there is an automated orchestration utility that will manage the deployment and configuration of the individual components. Containers are no different. In a distributed container system, there is generally an orchestration system to deploy each of the containers and manage configuration settings. For example, Docker Compose is a utility to orchestrate the deployment and configuration of individual containers to an endpoint. Other utilities, such as configuration automation tools Ansible and SaltStack or the vendor-specific IBM UrbanCode Deploy, can also be used.
The IBM Container service is a critical participant in your container orchestration solution. Since it is a fully managed containers-as-a-service system, the service provides full orchestration and scheduling of containers onto hosts to ensure that workloads avoid conflicts and overloading of individual hosts. Thus, users spend all of their time working directly with containers rather than managing the underlying hosts.
The IBM Container service enables orchestration at the container level by supporting the Docker and Docker Swarm APIs. You can use the IBM Container service as a remote Docker endpoint for any tools that support Docker APIs including Docker Compose. This enables users to focus on what’s most important: their application, not the management of the infrastructure.
Want to learn more about IBM Container Service? Get started on IBM Bluemix today to orchestrate resilient and secure cloud-native applications using Docker containers.
The cybersecurity marketplace is crowded. There are hundreds of vendors with an amazing array of solutions flooding the space, yet many organizations still struggle to stay ahead. In many companies, everyone is working as hard as they can to plug holes, but there is still a lack of knowledge about how to manage and understand […]