Securing the ‘New Network’
Network security is a different undertaking with today’s new network
In today’s business environment, containers and microservices have enabled organizations to meet constantly changing and increasing demand, but they have also changed the very nature of the network. Further, the near-ubiquity of mobile computing and the adoption of software defined networking (SDN) have pushed the network edge beyond previous limits, forcing organizations to rethink what the network is. The trouble is, some organizations are not rethinking how to secure this “new network,” and old network security solutions are leaving companies vulnerable.
Some of the primary challenges of modern network security are due to a key characteristic of Kubernetes container orchestration—that the environment is ever-changing, while network security teams are used to a much more static environment. These dynamic deployments enable automatic scaling and resiliency. While this orchestration provides great value to the business, it also makes it difficult to trace traffic, and many of the tools network security professionals use for managing physical networks aren’t available in this space.
To address this, Kubernetes’ pluggable SDN architecture provides a framework on which SDN providers can compete with functional and interaction differences to secure the dynamic network communications required. In addition, a service mesh, such as Istio, can be used as another layer to manage and report on the traffic between services. Kubernetes and the Istio service mesh can be used —and in the future used in tandem—to address common microservices architecture issues such as secure communications, load balancing and traffic routing.
To address the concerns related to modern network security, there are three main areas organizations need to make sure are properly secured, and these fall at the network edge, inside the SDN and networking between services.
At the Network Edge
The first line of defense in network security is controlling and limiting who can access the cluster, and what actions they are allowed to perform. Securing access to the Kubernetes master, the control plane, is particularly important. Since Kubernetes is driven by APIs, the first step is integrating tools to encrypt API traffic from and to the master with transport layer security (TLS), and to provide API authentication and authorization.
To secure egress and ingress traffic for services deployed on Kubernetes, a cluster administrator should allocate a number of static IP addresses to a specific node at the host level. They can then configure an egress IP for each project from the developer’s project to ensure that the traffic from the pod originates from the host using the pre-allocated static IP address. This helps with security because it allows an administrator to secure an external database so that only specific pods can talk to a service (the egress router), which proxies the traffic to the database. Further, using an egress firewall allows organizations to enforce the acceptable outbound traffic policies, so that specific endpoints or IP ranges are the only acceptable targets for dynamic endpoints to talk to.
Inside the SDN
SDN is quickly required for deploying containers at scale for modern cloud-native and hybrid environments, especially those based around Kubernetes and containers. While the upstream Kubernetes project does not come with a default network solution, Kubernetes has developed a Container Network Interface (CNI) to allow network providers to integrate their own SDN solutions.
SDN brings the benefits of abstraction from the underlying networking hardware, providing increased visibility and agility, through a centralized controller. A wide variety of SDN solutions that work with Kubernetes CNI are available. Traditional network implementations adopt a zoning model, in which different networks or zones are dedicated to specific purposes, with very strict communication rules between each zone.
Depending on your use case, a flat SDN network may be sufficient. However, most enterprises will benefit from an SDN that supports multi-tenancy. A multi-tenant SDN plug-in allows you to segment the traffic in a single cluster to isolate different users, teams, and applications within that cluster. Pods from different projects (namespaces) cannot send packets to or receive packets from pods and services of a different project by default. The limitation of this is that it operates at the level of the entire project, and the traffic allowed is always bidirectional. That is, if you can access a service in a project, you can access every service in that project, and you shouldn’t necessarily be granted access to all of your project’s services.
If more fine-grained control is desired, you want an SDN that works with the Kubernetes Network Policy feature, which improves the way pod isolation policies are defined, and provides fine-grained configuration of allowable traffic between pods in different projects. Network pPolicy allows configuration of isolation policies at the level of individual pods. It is not bidirectional and applies only to ingress traffic of pods, providing a way to define fine-grained traffic isolation policies between containers in different pods and projects.
Networking Between Services
The Istio service mesh injects a container that runs as a sidecar proxy (in this case, Envoy Proxy) and forces all traffic that ingresses or egresses a pod to go through that proxy. Istio connects individual instances of Envoy throughout a cluster using mutual TLS certificates, ensuring nothing gets in or out of the cluster without Envoy seeing it, and no traffic goes between two pods without being encrypted. It also helps to ensure that the user knows the remote endpoint they are talking to is the right one. Kubernetes APIs such as the Role-Based Access Control (RBAC) can also be used to control user access and permissions. New tools, including distributed tracing tools, such as Jaeger, can address this gap and help to provide visibility, fine-tune traffic and prevent latency.
Without a service mesh, developers have to manually build in these rules for communication. While some of these can be set in the SDN, the user needs to have project admin privileges at the minimum, and in some cases cluster admin privileges. Further, service meshes also have the benefit of being language agnostic, meaning developers no longer have to define language-specific communication paths.
These features help to isolate attack vectors for network security, and helps prevent against attacks such as last year’s Equifax breach.
When dealing with ingress traffic, Istio again comes into play. A specialized mechanism called the Istio Gateway, a load balancer operating at the edge of the mesh that receives incoming HTTP/TCP connections, performs layer 7 type policy checks on inbound traffic into the cluster. This acts as a policy engine for manipulating layer 7 traffic, including the ability to deny access to services, or to route it to a specific location.
For traditional network security practitioners, a “new network” approach to keeping applications secure doesn’t have to be as daunting as it may seem. Though it may mean dealing with a new set of tools, there are actually a lot of conceptual similarities in setting up secure network policies for container and microservices-based applications, and there are even security improvements that can be made that were never possible before.
