Overview
I spent some time in the security field, focusing on what the industry calls “intrusion prevention.” But, honestly, prevention is somewhat of an optimism since intrusion is almost a given. As a real-world perspective, at a major IT vendor I worked at what was the largest datacenter complex in the world at that time. There, I discovered a crucial fact – manual errors can enable circumvention of even the most sophisticated systems. In fact, IBM’s annual security reports detail that around 59% – 80% of security breaches – where sensitive data is provably obtained by hackers – are due to manual error[i,ii].
So, assuming that a point intrusion is likely to occur at some point, the corollary goal is to prevent hackers from being able to run amok in your systems once they get inside. For example, in one well-publicized intrusion of the New York Times, a team of hackers developed malware on the newspaper’s computers to penetrate more deeply and widely throughout the organization. The intrusion was systematically expanded over a four-month period before it was stopped[iii].
To prevent “east-west” penetration attempts within the datacenter, a number of Isolation techniques are used, including building silos of applications and services, all separated by firewalls and other security measures. However, these isolation techniques increase complexity and complexity leads to increased manual errors. And, these increases expand the Exposure Surface that hackers can attack. To reduce the Exposure Surface, more Isolation is typically architected. As depicted below, it’s a vicious cycle that can compromise overall security.
Figure 1: Security measures can synergize to compromise overall security
Docker Security and Docker Networking
You are probably thinking “Sounds right, but what does this have to do with Docker?” To put the above discussion into a Docker framework, Docker differs from virtual machine architectures in terms of both security and networking. Since many Containers can be supported by a single copy of a Host Operating System (Host OS), Docker minimizes server vulnerabilities that can be exploited. This is essentially an isolation efficiency. But, this efficiency can be offset if not worsened through utilization of multiple services per Docker server. As a result, some Docker implementations can exhibit the same or even much higher complexity than the equivalent using virtual machines.
Further, there are multiple Docker networking approaches being developed. As an example, one approach is an Open Source project called Weave. Weave will create a virtual network for interconnecting Docker containers across hosts. Applications treat all services as if they were connected to the same switch. Docker services can be made available both to the outside world and internally. This approach maximizes ready interconnection of Containers over isolation. Other approaches that we’ve seen seem to be variants on this theme.
In summary, the Docker networking approaches that we’ve seen to date are designed for a default of interconnection rather than isolation. When combined with increased complexity, the joint effect is to multiply the size of the Exposure Surface. At enterprise or service provider scale, the Exposure Surface grows beyond even my graduate-level math abilities. (It makes my head hurt just to think about it!)
Why Docker Customers and Partners Called Us
Turns out that a number of early adopters of Docker – customers and partners – contacted Nuage Networks for help. And, here’s how we handle Docker networking at scale with better security than any other approach that we’ve seen to date.
The Nuage Networks Virtualized Services Platform (VSP) provides Software Defined Networking that is policy-driven, secure, automated, and highly scalable. A key component of Nuage Networks VSP is the Nuage Networks Virtual Routing and Switching (VRS) module. Nuage Networks VRS can run in a variety of form factors, including in an Operating System, within a Virtual Machine, within an intelligent switch, and within some Customer Premise Equipment (CPE) devices.
Figure 2: Micro-segmentation at the “service level” for Docker
Looking at the figure above, Nuage Networks VRS operates as a virtual switch within the Host OS of the Docker server. The virtual switch enables reliable, efficient networking among services and between a service and the outside world.
Using a “Zero Trust” security model, only explicit connections – such as between Services in a given application and between a trusted connection and the application – are allowed. By securely isolating each Container (“micro-segmentation”), a key security exposure is addressed. Should one service be compromised, hackers cannot easily traverse to other services in the same Container, other Containers, the Host OS, or resources on the server.
Nuage Networks VRS also masters complexity via intelligent interpretation of declarative policies at the very first attachment point to the network – within the Host OS. Declarative policies, unlike explicit policies (e.g. Access Control Lists or ACLs), are location-independent. For example, a declarative policy is “App 1 Service 1 can communicate with App 1 Service 2.” Were App 1 Service 2 to be moved to a different Container, the declarative policy would still be effective without modification. It would be evaluated intelligently at the new endpoint and communication would be allowed.
How Nuage Networks Strengthens Docker Security
Looking at the figure below, these factors synergize to improve Docker security. Default isolation keeps vulnerabilities from being exploited by simply preventing any unauthorized access to the Host OS, Container, and Service. Mastery of complexity helps counter the “manual error” effect that often compromises security. Specifically, replacing unwieldy, manually defined ACLs with intelligent policies and automation provides not only simplicity in terms of specifying security parameters but also freedom from manual errors.
Figure 3: How actions taken to improve network security can synergize with each other
Both isolation and simplicity synergize to minimize the overall exposure surface. For the example above, the exposure surface is only that required to communicate among named services and among named server resources. A minimized exposure surface improves security since hackers have very limited avenues that they can attempt to exploit for an entry intrusion as well as east-west intrusions.
Adding Hypervisors, IP-based Networks, and WANs to the Mix
In short, the approach outlined above is exactly the same for a Hypervisor vSwitch, an IP-based network, or a MPLS WAN. Isolation is enforced by default. The same declarative policies would be intelligently, consistently, and universally applied at the very first network connection point – within the hypervisor for virtualized resources, within the server rack switch for bare metal resources, or within the Customer Premise Equipment for a WAN. So, workload mobility – whether in a Docker Container, a virtual machine, or a bare-metal server – is frictionless since security is applied consistently and automatically across the entire network.
What This Means for Our Customers
Taking these capabilities as a whole, the majority, if not all, of initial intrusions will be prevented. Follow-on east-west intrusions will also be hindered if not prevented as well. Since a single SDN approach encompasses the entire IT environment, including virtualized, Docker-ized, and bare metal resources, both security and efficiencies are maximized. That’s a net gain, so to speak, within datacenters and all the way out to the WAN!
Learning More
To learn more, see our Network Security Brief.
[i] https://www-935.ibm.com/services/us/en/it-services/security-services/2014-cyber-security-intelligence-index-infographic/
[ii] https://www-935.ibm.com/services/us/en/security/infographic/cybersecurityindex.html
[iii] https://www.computerworld.com/article/2495061/cybercrime-hacking/new-york-times-computer-network-breached-by-chinese-hackers–paper-says.html