Network Micropolicies

The term microservices, first credited with use in 2011 during a software architecture conference in Venice, is now in the mainstream lexicon of just about every software developer, operator, or manager not hiding under a block of magnetic core memory. We now have workshops, application factories, development frameworks, runtimes, orchestrators, service meshes, and packaging formats all dedicated to enabling the adoption of microservices. While one can debate whether the path to nirvana is through microservices, the microservices approach has undoubtedly enhanced, accelerated, and in many cases, simplified the process of software development.

Ok, enough on microservices as most of us have already adopted the development paradigm or are seriously considering it. Instead, I’d like to discuss how microservice adoption is impacting the infrastructure and peripheral services upon which your software workload depends. Along the way, we’ll meet the microservice’s first cousin, the network micropolicy.

Limiting Scope and Separating Concerns

The emphasis on separating concerns and limiting the purpose of components is not a recent discovery but hails from the tenants of the Unix philosophy advanced some forty plus years ago. These tenets, commonly applied to the function and packaging of software, also apply to other operational aspects such as governing the communication between services.

Decomposing applications and creating microservices with a well-defined scope and interface has a connectivity corollary: policies regulating network connectivity should also be appropriately sized and focused. We’ll call this a network micropolicy.

Much like small components can be reused and composed in different ways to provide unique solutions, network micropolicies also provide the means to grant exactly the access needed for components to communicate — no more, no less. This tight coupling of policy to only the enumerated functions of a microservice (or any application really — even legacy monoliths) is essential when trying to achieve a Zero Trust security posture. Micropolicies enable microsegmentation.

Unfortunately, the process of simplification can have unintended consequences. It’s much like squeezing one end of a long balloon — think of the balloons twisted by clowns to form delightful figures at birthday parties — only to find the other end bulging to the point of bursting. Through decomposition along with hyper-shortened software development and deployment lifecycles, we’ve unduly burdened operators with the task of managing portfolios of runtime objects that are orders of magnitude larger than what existed previously.

What has become simple for the developer grows into a nightmare for the operator.

Fortunately, we have come together as a community and shared the burden of implementing the complex distributed systems that enable the adoption of these patterns. While container orchestration platforms such as Kubernetes provide a simple API for defining and deploying packaged microservices, Project Calico and CNX provide simple interfaces for establishing secure application connectivity between them.

Meet the Network Micropolicy

So how do we describe a micropolicy to our peers? First, the micropolicy name usually describes its function. For example, we might have a policy that describes a compliance classification — such as PCI. A standalone policy such as this would enable PCI workloads to only communicate with other PCI workloads.

Micropolicies typically come in pairs. For example, we might have an log-service and log-client micropolicy. As you might expect, the log-service micropolicy would be applied to a log service (maybe syslogd) and any workload needing to push logs would need the reciprocal log-client micropolicy. In addition to the policies, labels need to be setup in pairs as well to identify the target workloads. In this case, we would create a label “log” and it would have the value “client” or “service”. Policies are then applied based on this label.

Enforcing both ingress and egress on every workload with paired micropolicies is another way in which we can achieve a Zero Trust security posture.

Small, purpose-built micropolicies can be composed and reused to restrict network traffic to only the service conversations you intend.

Micropolicies Simplify Testing and Deployment

As a best practice, micropolicies should be versioned so that incremental changes can be tested with canary deployments. When you need to test a new service or policy change, it is much easier to tackle rewriting a tightly scoped policy addressing a specific type of exchange. By not coupling micropolicies directly to specific microservices but instead matching intentions at runtime with labels, changes to traffic rules can be limited to a single policy change instead of updating many tightly-coupled policies.

Project Calico provides full support for creating network micropolicies. In addition, Tigera CNX enables micropolicies to be sorted hierarchically into organizational tiers for enforcing evaluation precedence and to apply to either global or namespace specific scopes such as in multi-tenant environments.

As you start your microservices journey, think about how to apply network connectivity micropolicies to achieve an optimal posture for manageability and security. Micropolicies minimize operational headaches (unpacking and troubleshooting complex policies is painful) while providing optimal security.