The Changing Landscape of Network Security Policy Enforcement: Part I

Part I: The Changes in Compute Infrastructure and Application Architecture

Evolution of compute infrastructure and application architecture

The architecture of applications and the compute infrastructure that supports them have evolved significantly over the past 15 years or so. These changes have also had a large impact on the networks that support them. With all these changes, the network approach to securing these applications has also evolved. Going forward, the adoption of Continuous Integration/Continuous Development (CI/CD) application deployment strategies and microservices-based applications require new approaches to securing applications.

In this series of articles, we will discuss how the evolution of application architecture — from monolithic based to microservices based — will require changes in the tools and strategies for network security policy enforcement.

• In this first article, we'll examine how compute infrastructure and application architecture have changed in the past 15 years.
• In Part II, we'll examine networking for container and Kubernetes environments and its impact on application security.
• In Part III, we'll survey the approaches and tools for securing applications in this new world of applications that can be hosted on bare metal servers, virtualized servers or in hybrid or Kubernetes environments.

It is imperative that network and security professionals understand these application changes and the implications on security policy enforcement in the network.

The advent of containers and microservices application architecture
 

1. Infrastructure changes: containers and Kubernetes

The infrastructure that supports application deployment has changed greatly in the past 15 years. In the early '80s, with the advent of personal computers and x86 servers, applications were deployed on individual servers. This led to a sprawl of greatly underutilized individual application servers.

Throughout the 2000s, greater server utilization was achieved through the combination of application servers using hypervisors such as ESX, KVM and HyperV. This ongoing drive for speed and efficiency led businesses to deploy applications in containers.

Containers are self-contained, lightweight application execution environments, typically hosted on a Linux server, deployed either as bare metal or as virtual machines (VMs). Containers can be used to deploy web, middleware, database or other application components. A container houses just the necessary libraries to support the execution of the application. As the container is lightweight (with regards to memory, disk and CPU), the startup or "boot time" for a container is measured in the 10s of milliseconds. This quick startup time makes containers ideal for application environments where the need for rapid change is paramount. 

The other key benefit is that containers are portable. This means they can be hosted on different platforms (RHEL, Ubuntu, SUSE, etc.) in a private data center or in the public cloud. 

To summarize, containers provide speed of deployment, efficiency in resource consumption and flexibility in deployment locations.

Effective management of the deployment, scheduling and resource usage of containers requires an orchestration framework. Kubernetes, an open source framework championed by Google, provides such an orchestration capability. Kubernetes groups containers into "Pods," which consist of one of more containers. Kubernetes schedules and manages the Pods across servers called "Worker Nodes." The Kubernetes management processes execute on the Kubernetes "Master Node."
 

2. Application architecture changes: from monolithic to microservices
 

Monolithic software architecture

While compute infrastructure was evolving from mainframe to servers to virtual machines, applications were being developed via a monolithic approach. In a monolithic application, all business logic is contained in a single block of application software. The business logic might be written in a series of modules, but the application is written, tested and deployed as a single entity. 

Typically, this type of application was developed through a "waterfall" approach. This meant the application would be written and tested in a series of releases. If software bugs were discovered after the release, they would be fixed, tested and then deployed in a subsequent release.

With the ongoing emphasis on reducing time-to-market, the concept of Continuous Integration/Continuous Development (CI/CD) was established. In CI/CD methodology, changes to software are made and tested on an ongoing basis. There's no waiting until the next release to introduce a fix into the software.

This type of approach can present issues with large blocks of monolithic software. Given all of the complex interactions within the modules of the software, testing and verification of the software can be too slow. What was needed was to simply the method of communication of the modules to facilitate faster verification of the software. This simplification is known as microservices-based architecture.

Microservices application architecture

With microservices-based architecture, the business logic of an application is segmented into a series of services (microservices) that communicate with each other via a standardized API.

This standardized API not only allows the microservices to interact with each other but also to function independently of each other. This independence allows for the separate development, testing and deployment of the microservices. The overall application essentially becomes a federation of independent services.

Microservices architected applications have been pioneered and extensively deployed by companies such as Netflix and Lyft. Figure 4 illustrates a monolithic app that has been re-factored into a set of microservices.

The independence of microservices not only allows for the separate development of each service, but the API-based communication also allows for the application to be developed in a polyglot approach. This means that different languages can be utilized for the development of each service. For example, one service could be written in Java, a second in Python and a third in Go.

As each of these services are small, meaning small, separate blocks of software that can be independently scheduled on a server. This is where containers or Kubernetes Pods have tremendous benefit. 

A microservice can be deployed in a lightweight container. Using Kubernetes, the microservice can be scheduled or redeployed as needed. Given the millisecond startup time of a container, a microservice can be patched and restarted without any noticeable difference in performance to the overall application. This ability to change a portion of the application "on the fly" makes it possible to quickly deliver new application functionality to enhance the user experience. Businesses can now efficiently and reliably reduce the time-to-market of application functionality.

Conclusion

As a network or security professional, you may ask "Why care about microservices application architecture or Kubernetes Pods (containers)?"

The microservices of an application exist in Kubernetes Pods. These Kubernetes Pods communicate with each other using APIs over a network. This network is a distinct private network that exits between the Pods on a given Kubernetes Worker Node, and between Worker Nodes and the outside world. Essentially, you have an intranet on the Worker Nodes and an internet between nodes. Although these networks may seem rudimentary, they can be quite complex, utilizing BGP between nodes when using Calico as the Container Network Interface (CNI) plugin for Kubernetes. (More on that in Part II of this article series: The Impact of Containers and Kubernetes Networking).

Understanding these Kubernetes networks and how they interact with the outside world is crucial to networking applications of the future. Moreover, these microservices need to be secured as they represent the business logic of the future. In the past, we've been concerned about securing a given server; here, we're focusing on the security of the business logic itself.

In summary, applications are evolving to microservices that are deployed in containers within Kubernetes Pods. These applications will need to be connected and secured to the outside world.

In the next article, we'll examine the networking that connects the microservices applications of a Kubernetes cluster.