Container security has been a hot topic since the advent of Docker and the rise of containers as the core building block of cloud-native architectures. One of the issues that we grapple with, for those of us who speak and write on this topic, is the multi-faceted nature of container security. When we talk about container security, key topics include issues like process isolation, container runtimes, operating system features, images, and a secure supply chain from code to binaries. And what about the hosts themselves? They can play a significant role in container security. While we have all of these different aspects of a secure container, they have been discussed at length. The one topic that hasn’t been covered extensively by others is network security.
As we proliferate containers throughout our application deployment by using microservice-based architectures and using network accessible APIs as the glue, the network becomes a key linchpin on which a secure container architecture rests. In this blog post, I’ll introduce the concepts around network security for containers. Some aspects of container network security are long-standing concepts that apply to any approach to network security.
Basic components of network security
For the sake of this introductory level discussion, we’ll break down network security into three key components: Secure communications, secure identity/authorization, and secure isolation.
The use of TLS for encrypted network traffic is becoming more commonplace, including in everyday computing with our web browsers preferring the “green lock,” free services like Let’s Encrypt, and a more concerted effort to enforce and require secure communications in tools like messaging and email.
How we approach secure communication is similar to how we approach cloud-native application development and deployment. We expect our control plane (container runtimes and orchestrators) to use secure communication in their distributed components and we need to expect that our microservices will also expose and communicate over TLS-enabled endpoints. Service mesh components, such as Istio, are making this easier for developers by providing certificate management and automatic sidecar-managed fully encrypted communication with other services.
While identity and authorization can be related to secure communication, this component includes the concept of network policy beyond the identity that is inherent in TLS-based communication. In our cloud-native and microservice-based world, network policy should be used to determine who gets to talk to whom. With clearly defined roles in a microservice-based architecture, there is no reason to leave the network as a wide-open free for all, with a service being able to connect to any other service. Given the potential for malicious activity, we can reduce the blast radius by keeping specific components limited to talking to a limited set of other services and endpoints. Network policy (including identity and “approved” paths between services) prevents both malicious and potentially buggy intra-service traffic from inadvertent impacts to services.
Within this realm of secure identity and authorization, service mesh and orchestration technologies can offer us the tools to make it possible to create and disseminate network policy within an arbitrarily complex application.
Isolation is also interrelated with our discussion of network policy, but we separate it as a topic to note some key aspects that are unique. When we speak of isolation, we note two things. For one, our network can be partitioned in ways that reduce the risk of being impacted by intentional malicious activity as well as failure cases where a microservice misbehaves. Secondly, we can consider that some services need no egress path to the broader network or Internet, and again, we reduce the potential for malicious or harmful network traffic and/or bandwidth use when we block the capability for traffic to occur (which we never needed anyway in our application architecture).
Traditionally network firewalls, both hardware and software, use specific routing rules to provide isolation via partitioning, traffic restrictions, and port blocking. In the container world, the manipulation of these rules is handled within container runtimes and orchestrators, providing the basis for network security policy. As our distributed systems become more complex, service meshes in this space provide a more nuanced view of secure container isolation and policy.
Achieving container network security
So how do we achieve these network security and policy requirements? There are a mix of open source projects, third-party vendor offerings, and inherent features in base Linux that can provide these capabilities at various levels. We won’t have time in this introductory-level discussion to describe each one in detail, but stay tuned for future code patterns and how-tos here on IBM Code.
Istio and security
At IBM, we spent a significant amount of time working with Google and Lyft around the Istio open source project. Istio provides a broad set of capabilities that are both cloud-native and Kubernetes supported; these capabilities provide operators of a distributed application with a “swiss army knife” full of tools, if you will. Istio’s design utilizes the Envoy proxy, a CNCF member project, which exposes many of the network features of the underlying Linux kernel that can be used in an API-driven cloud-native architecture.
Istio and Envoy are not the only players in this space, and another CNCF project, Linkerd, provides similar functionality and was created by Uber. Also check out Spire, another CNCF project that targets the service identity space, providing a SPIFFE-implementing cross-cloud API and is in the early stages of development.
Stepping away from cloud-native open source, several container security vendors provide network security and policy capabilities within their product offerings. Aqua, Weaveworks, Sysdig, Twistlock, and NeuVector all have offerings and capabilities in this space. Attend any cloud-native conference and you will find even more vendors providing visualization, policy, and alerting around container network isolation and security.
We acknowledge that many of these core aspects of container security have been discussed at length around the industry. However, the topic of network security rarely gets as much focus but is just as important to the overall security posture of a container-based architecture.
- Envoy Proxy: An open source edge and service proxy, designed for cloud-native applications
- Using Istio to improve end-to-end security
- What is Istio and why is it important to container security?
- Istio: An open platform to connect, manage, and secure microservices
- Microservices, Kubernetes and Istio — a great fit!
- Security for IBM Cloud Kubernetes Service