Deploying and running Docker container-based software in the public cloud requires special security considerations in addition to those that apply when you run Docker on your own infrastructure. The usual Docker security analysis is still relevant, but there are some other things to bear in mind when using a CaaS (Containers-as-a-Service) provider, such as Amazon’s ECS, Microsoft’s Azure Container Service, or Oracle’s Container Cloud Service.
This article explains the special security elements you should keep in mind when using CaaS providers. I discuss the rapid provisioning, scaling, and updates requirements of containerized applications, and explain how to develop a dynamic set of security policies for running containers on a CaaS.
Docker Container Security Overview
Whether running on private infrastructure or the public cloud, the same Docker security scrutiny still applies. This includes keeping Docker up-to-date; using the latest patched software platforms (e.g. the Java VM, Python runtime, and so on); careful use of third-party and open-source libraries; defining security policies that govern network access, registries, filesystem monitoring, system call analysis, etc.; inter-container linkage rules, and user roles and activity logging, etc.
Containers-as-a-Service Security Considerations
When it comes to public cloud-based container services, many of the security challenges and risks are the same as with private Docker installations. However, there are additional security risks for large scale, cloud-based container deployments, especially in terms of the application and administration, which you should examine. Let’s review these now.
Host OS and Virtual OS Security
Containers are tightly integrated with the Linux OS. It’s therefore important to ensure security at that layer regardless of how you’re deploying containers. Understand your options when it comes to operating systems offered by your cloud provider. This includes both the host OS—the one running on the physical server—and the virtual OS images that run on top. Different Linux distributions and their versions have their own security considerations and available settings. Choose a vendor that offers a choice of the most secure and updated host and virtual OS images.
Additionally, take into account the hypervisor that runs on top of the OS as well. Make sure your host provider has enabled integrated security settings between the host OS and its hypervisor to eliminate attack points. If your cloud provider supports it, install third-party security and automation tools to eliminate human error in this area.
Docker Installation Security Settings
Basic cloud-level security is the first step when implementing a secure Docker installation. The use of security groups and network access control lists within AWS, for example, allow you to control inbound and outbound network access. Additionally, limiting IP address ranges and the use of virtual private cloud settings help, especially when connecting CaaS resources to other cloud instances, or in hybrid cloud scenarios. If supported, you can achieve further container isolation by distributing your container instances across your cloud provider’s server cluster.
Host-level Container Isolation
Docker containers offer some isolation via control groups and namespaces, but these are not hard boundaries. Therefore, make sure your provider implements container isolation at the host level as well. For instance, without multi-tenant support, you’ll be sharing all of the same resources without boundaries, and container-level security may not be assured. Even with host-level isolation, Docker instances share the same virtual kernel and resources, and all virtual OS’s share the same resources as well. Knowing this and ensuring you run your containers with the right user accounts and privileges will help guard against inter-container attacks.
Limiting container-level resource usage (i.e. quotas) helps to isolate the damage from an infected container. Choose a cloud provider that implements resource limits at a basic level in case other cloud neighbors aren’t as careful. Additionally, know where and how your container-based application data is being persisted. Although containers come and go, which helps make them more difficult to attack, one strategy is to attack and infect the data that persists in between. Data is highly coveted by cybercriminals. Using a read-only file system may help ensure that the damage is limited in case of a breach.
Release Orchestration Security
Even the most hardened server or cloud environment is easily compromised if you hand over the keys to operate to the criminals, so to speak. Installing new container images via release orchestration with security is just as important as your container cloud security settings. First, ensure secure access to your container instances (i.e. via SSH) using a public/private key combination. Upload your own SSL certificates to ensure you’re the only one who has access to update the actual images. Then, only users and computers with the private key will be able to access and update images in the cloud, which is where the public key is placed.
The tools and processes that get your image to the container need to be secure and reliable as well. Know how images are scaled to other instances, and whether shared resources are involved. For example, are the containers cleanly brought up, or is there a chance a container could have remnants from a previous tenant? If possible, ensure that all provisioned cloud service VMs are restarted before and after your private key and/or software is uploaded.
Service Repository Considerations
Instead of pulling images from a known internal source, with a CaaS solution, your images are typically stored and deployed to a new service instance on demand. Procedures need to be in place to ensure that your images are in the same state as when you created them, without being altered or compromised. Turn on or otherwise implement image scanning within your cloud environment to make sure your images remain unaltered. As mentioned earlier, you may also be able to put the file-system into read-only mode after images are updated to protect against attacks.
CaaS Patches and Upgrades
Know your provider’s policies on applying security updates and Docker upgrades to cloud service instances. How long do they take to propagate? Do they get updated across all regions equally, or are some geographies delayed due to legal, compliance, or political reasons? If your cloud provider gives you the option to control updates, that may be a better choice, since it gives you a level of control. On the flip side, if the provider’s update frequency is acceptable and documented in a service-level agreement, it may be more prudent to outsource this activity.
Container Monitoring and Alerts
Your CaaS security strategy should include knowing when you’re at risk through comprehensive monitoring and alerts. Although your service is running in the cloud, CaaS solutions such as Amazon ECS allow you to query the complete state of your Docker server cluster, and access many familiar security features such as security groups, user and access roles, inter-container linkage rules, and so on.
Some cloud providers such as AWS allow you to install additional security monitoring tools to enhance monitoring, log management, and intrusion detection. This enables the use of powerful security and monitoring dashboards (see Figure 1), which provide critical vulnerability and compliance information at a glance.
Conclusion: CaaS Requires a New Paradigm in Security
Containers in general, and especially those running in a public container cloud service, require specialized security considerations and tools. Because of the nature of containers, with rapid provisioning, spinning up and scaling out, and frequent updates to the applications within, a more dynamic set of security policies with support tools is required. Vendors such as Twistlock understand this and offer new paradigm security solutions for container-based applications in the cloud. Enterprises that already embrace modern cloud-native deployments of containers will benefit most from a more dynamic security environment for their applications, with fewer risks, and their users will benefit as well.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Cloud Platform Discovery: Identifying All Your Cloud Native ServicesRead the Blog
Using Twistlock to Secure Workloads on Pivotal Cloud FoundryRead the Blog
Twistlock, Azure Container Instances, and AKS virtual nodesRead the Blog
Twistlock 18.11 Release NotesRead the Blog
5 Questions to Ask When Choosing a Cloud Native Security Platform for DevOpsRead the Blog