How to Secure Docker Networking for Access to External Networks and Applications

Getting container visibility and security for docker networking can be a challenge even for a pure container based application stack, or cluster. For most enterprises this challenge can be even tougher when trying to secure a hybrid environment with both container and non-container applications.

Many enterprises are in the midst of migration projects to a microservices based architecture with containers. These projects often refactor applications which gain the greatest benefit from containers or can be deployed quickly. Migrating other services such as databases or legacy systems can take a few more years, or are often not planned due to the difficulty or lack of benefit. It is very rare for large enterprises to deploy a completely containerized application without access to non-container resources.

This means that securing the environment means not only securing container to container connections but also traffic between container networks and other networks – internal, external, legacy – however they are classified. These other systems are typically VM based and can often be in a different public or private cloud infrastructure. Securing this east-west type of traffic can be a challenge itself just for containers.

Securing the L2/L3 network layers between container and non-container networks is the first security layer needed, whether its provided by IPSec tunnels, SSL VPNs, routing tables or internal firewalls. But assuming that this has been taken care of, it’s not enough for complete container network security.

A cloud-native container security system should provide docker networking visibility and security within a container cluster and between containers and all external services. In this article the term ‘external’ is used to describe any network and application service which is outside the container cluster (ie any non-container resources). These non-containerized external services can include:

• Legacy database
• VM-based REST API services
• Public internet-based services
• Applications on internal networks
• DNS services
• Authentication services
• Other platform services outside the container cluster such as logging
• Other public cloud infrastructure services such as AWS S3.

External connections from containers should be able to be clearly identified and secured, whether on ingress or egress. Ideally, the security policy should control which external connections are allowed. These policies should not be based solely on IP addresses.

The challenge with enforcing a security policy is that, like with container to container connections, a policy based on Iptables or other manually updated rules is fragile and can easily break in the dynamic container environment. Containers can be constantly launching with different IP addresses for the same service. A security policy with application protocol intelligence at Layer 7 can greatly minimize the chance of error and automate the monitoring and security tasks.

In the simple example on the left, the wordpress container needs to be able to access both a containerized mysql database as well as an external non-containerized mysql database. If the wordpress container is compromised and connections are attempted to external public networks, the violations are detected and blocked. Violations should also be detected if connections are attempted to either database using the wrong protocol.

It is critical to be able to monitor the connections between containers as well as to and from external services. While it may be simple to configure and monitor a simple deployment, enterprise applications are rarely simple and need an adaptive policy which scales up and down with container instances as application workloads change.

Below is a more complex example of container network visibility and security for multiple applications. It shows sample containerized application stacks for wordpress/mysql and nginx/node/redis. Imagine further the complexity required to monitor and secure hundreds or thousands of containers across hundreds of hosts and with access to several dozen external network services.

The node service in the example needs to access several external services, which in this simulation are an external API service over the internet and an internal database on a separate network segment. By defining the network segments and protocols allowed for these external services, NeuVector customers can  monitor all live connections to external services.

Violations of the policy can be detected by NeuVector and there are various responses possible such as logging, connection blocking or container quarantine. For example, the red lines show unauthorized connections from node3 and wordpress containers. If unauthorized connections originated from or accessed external services these would also be detected.

In a complex microservices based environment with connections between container and non-container based services it’s critical to know what’s going on at all times. Tools for visualizing specific application stacks by filtering complex networks can help to pinpoint suspicious activity. The visibility of docker networking connections can even help debug applications or misconfigured updates during testing and staging.

Hybrid container and non-container, public and private cloud, and VM and bare-metal environments are a reality that enterprises must be prepared to handle. The speed of deployment and instant scalability of containerized applications make it critical to build in networking and application intelligence to automate the monitoring and security required at run-time.