One challenge many organizations face when migrating their applications to Cloud or container platforms is that identifying applications by their network address, either CIDR block (aka subnet) or IP address no longer “works.”
Identifying application instances by their network address no longer works the way it used to because the compute instances are much more dynamic on Cloud and container platforms and classic IP management processes and tools can’t keep up.
This is a big problem because a lot of organizations have been relying on network access controls to identify and control traffic between application instances in order to implement application authentication and authorization.
In the old model, it may have been (or at least seemed) reasonable to skip verifying the identity and authorization of who is making requests to an application, because “only authorized callers will be able to talk to it on the network.” I’ll argue skipping app-level auth was generally not reasonable another day and say…
You’re in for a big change if you’re filling out spreadsheets, an IPAM tool, or JIRA tickets so that someone can go make a change in a PAN or Juniper firewall to authorize traffic between applications.
Here’s a commonly-encountered model: A network or security engineer carefully allocates IP addresses to be assigned to machines when they are provisioned on vSphere or configured with Puppet. An engineer feeds these IP addresses into hand-crafted firewall rules and routing that protect the application and authorize flows. This practice relieved application developers from implementing access controls in many organizations. However, this model breaks down quickly on modern Cloud and container platforms.
We’re managing cattle, not pets.
Virtual machines, containers, and sometimes ‘serverless’ functions on those platforms may acquire and release IPs from large IP pools at high rates. This is necessary to realize the major platform benefits of scaling with customer demand and high availability while controlling costs.
You can definitely provision application instances into particular zones of the network by launching them in an appropriate subnet, e.g. dmz, app, or data. However, there may be hundreds or thousands of other compute instances running in that same network zone, so how do you create meaningful firewall rules built around IPs?
Those compute instances may acquire or release IPs several times per minute, at all times of the day or night. You can make the subnets finer-grained to tighten up your network rules a bit. But you have to answer the question: Can you handle 10x or 100x more application components?
The days of artisan-allocated IP addresses and /29s for specific applications are over.
Maybe you’re thinking you’ll automate the updates to your existing firewall or load balancing tools. That might work, but you need to design and implement this very carefully. Many older tools weren’t built to:
- handle the increased entropy of several changes per minute
- provide highly-available operations across multiple datacenters (c.f. Concepts: Zones and Regions)
- scale with a major Cloud compute platform
- integrate Cloud and container platform management tools
You’re going to need a better way to authorize application access than hand-crafted IP allocation.
The good news is that you have robust options when the Cloud or container compute platform is tightly integrated with the platform’s network or better yet, identity services. I’ll cover these options in upcoming posts:
- better network access identity and control with Cloud-provided networking services
- ‘proper’ application-level identity and access control derived from the compute-platform’s identity services (Let me tell you a secret is a good preview)
- Service Meshes which combine application identity and network routing, access control, and more
Stephen
#NoDrama
