Perimeter Is Where Your Workload Is: Policy Abstracted from IP Addressing

By Christer Swartz, global consulting engineer

Cloud, containers and microservices are some of the disruptive technologies that have had a transformative impact on enterprise security in recent years. In this new landscape, securing the perimeter no longer works and IP addresses are not an efficient or reliable way to keep track of workloads that are dynamic and moving in and out of the data center and cloud. When I visit customers around the world, my advice to them is, “If you are still defining security along IP addresses, your security model will quickly break.”

Policy in the data center needs to be defined in a totally new way, and this idea is captured by an expression popular among network engineers, "Perimeter is where your workload is." We need to evolve away from the legacy approach to defining policy boundaries in the data center. The perimeter is no longer a network perimeter, it is a perimeter defined by metadata associated with workloads, regardless of network location. 

Traditional Approaches to Security Boundaries Are Outdated

Security boundaries in the data center have traditionally been network centric. Firewalls were deployed along boundaries between VLANs and IP subnets, and policy was defined to state that specific VLANs could talk to each other, or this IP subnet could communicate with that IP subnet, over some specific set of ports. The most basic trust boundary was the data center network perimeter; everything outside that network perimeter was untrusted, and everything inside that network perimeter was trusted. 

This traditional approach to data center security boundaries has been used for many decades now, and it assumes that workloads remain mostly on a specific network segment and rarely migrate or change IP addresses. If they do, this approach calls for updating the firewall, which generally requires some kind of manual change-control process, which is rarely executed in real-time.

This is a long-since outdated model, since most workloads are now either deployed on virtual machines or on a microservices container model, which is the emerging application-architecture platform. Modern hybrid cloud architectures allow workloads to be on either side of the traditional network boundary, which means that the traditional definition of a trust boundary is no longer relevant. A fundamental detail of this modern model is that workloads move around dynamically, live-migrating between hypervisors, hosts, data centers or public or private clouds. These dynamic movements of workloads are orchestrated by a central controller, which decides where to migrate workloads based on resource utilization or demand. As workloads move in this way, IP addresses often change. 

If you are using the traditional firewall network boundary model, this means you need to touch the firewall every time such a move happens. Alternately, you need to create rules that are so broad and wide-open that they no longer provide any real security. 

Policy Should Be Defined Against Identity

Firewalls can no longer define policy based on network location, since it is simply not scalable to have to modify policy every time a workload moves. Instead, policy needs to be defined against an identity that remains associated with a workload even if its IP address changes. Doing so allows firewalls to define policy against workload identity once. Then, as the data center and hybrid cloud scale out, these policies remain quiet unless new identities need to be defined.

Almost all controllers, both in private and public cloud fabrics, are able to associate metadata, or "tags,” to workloads. This is true for both host-based controllers, such as Cisco ACI and VMware NSX, and for container controllers, such as Kubernetes. As a workload is spun up, the controller will assign a current IP address to that workload, and then it will assign a permanent tag to it, which does not change, regardless of how often it migrates around the network. 

For example, one VM could be assigned a tag of "Database," another could be assigned a tag of "Web" and a third could be assigned a tag of "App." If the controller needs to migrate any of these VMs to a different network segment, the IP address may change but this tag will not. The tag is permanently associated with the workload, for the life of that workload, regardless of network location. 

This tag is not a network tag, such as an MPLS tag in an Ethernet frame. This is simply a string which is associated with specific workloads in the controller, almost like a field in a database. The tag is the permanent identity of the workload. Think of it like a user ID for workloads. 

The controller keeps records of which workload's IP address is currently assigned to a specific tag - its identity - and these tags can be sent to Palo Alto Networks firewalls. This enables Palo Alto Networks firewalls to create policy that refers to tags, and not to specific IP addresses. 

Palo Alto Networks calls these tags Dynamic Address Groups, or simply "DAGs." This means users can create policies that look less like computer code and more like human sentences. For example, a policy might say, "Any workload tagged as Web can talk to any workload tagged as App." This is especially useful because it aligns with how users or developers usually perceive data center resources. 

Typical IT support tickets often open with a complaint like, "My App servers can no longer contact my Web servers." The first question the help desk will ask in response is which IP addresses and ports are being used, and usually the user will have no idea. This simply delays troubleshooting.

Better, more modern security practices will prevent this delay. If we write policy that resembles how data center resources are perceived by users, the help desk engineer can click through a tag name, see its current IP address and much more quickly remediate problems. 

I strongly recommend using tagging when designing a private or hybrid cloud architecture. Tags are required in the case of VMware NSX, since NSX uses them to make forwarding decisions. Tagging is available but optional for other controllers, such as Cisco ACI and OpenStack. The APIs required to push these tag-to-IP mappings to Panorama, Palo Alto Networks security management, are included in VM-Series on VMware NSX, and they are implemented as a Panorama plugin in the case of Cisco ACI. 

Configuring your controllers to send tag-to-IP mappings to Panorama means you can write policy that allows data center and hybrid cloud architectures to be deployed and scaled out without firewalls becoming an operational bottleneck. The security perimeter is now the identity of the workload, no longer defined by the workload’s location on the network. Policy is mapped to this permanent identity, no longer being limited to how the network is segmented. Remember, “Identity is the new perimeter,” and Palo Alto Networks can help you define policy against identity.

For more on data center security, see Christer Swartz's piece on "Protecting Data Center Interconnect Links."