Securing traffic between your microservices

Security is a complex and highly sensitive domain, and with the adoption of the cloud, one that exposes IT organizations to a drastic shift in perspective. Concepts like DMZs and fixed-access control lists based on source and target IP addresses simply can’t scale to the rapidly changing nature of services and applications brought up and down on demand, across regions, and sometimes ephemerally.

To address these challenges revolutionary concepts like zero-trust security have been developed, where no workload nor request is implicitly trusted regardless of its origin. Many teams, however, struggle with adopting these patterns without having to make broad, non-trivial changes to their architectures.

Is there a way to ensure traffic between services is secure, even in scenarios where services can produce requests from anywhere and to anywhere without having to modify architecture or infrastructure?

Today I’d like to walk you through Palo Alto Networks’ Cloud Next Generation Firewall’s (NGFW) App ID capabilities inside Amazon Web Services (AWS). Using this feature, you can define rules and secure traffic happening between services (east-west traffic) without making any modifications to your code or defining network-related rules that won’t scale to dynamic environments.

Traffic between services represents a huge attack surface. Most organizations build a lot of measures for securing traffic from the outside world into their public-facing applications. Yet many supply chain attacks and other similar modern malicious means to take control or steal data happen from the inside out, exploiting vulnerabilities in how services consume external resources or communicate with one another.

Therefore our objective is to ensure that we can identify each application generating east-west traffic and apply rules to them, all without having to make application-level changes, or expect to maintain fixed, static access control lists which simply do not work with today's containerized, dynamic network environments.

I’ll share the broad strokes on how to configure Palo Alto’s Cloud NGFW inside AWS and have workloads automatically get an authoritative assigned identity. This enables the firewall to automatically identify traffic from those applications by providing a set of patterns to distinguish the origin of interservice requests and then applying relevant rules.

Palo Alto’s Cloud NGFW gets integrated with your AWS accounts and VPCs as endpoints. These endpoints will be used in your route tables as targets to ensure all traffic is routed through them, which will effectively allow the Cloud NGFW service to process all traffic between subnets and across VPCs.

Provisioning Palo Alto’s Cloud NGFW from AWS Marketplace handles most of this process, including linking the AWS account with Palo Alto, and creating the AWS Identity and Access Management (IAM) and VPC resources that will be required for Cloud NGFW to have permissions to do its work.

When deploying Cloud NGFW, you can pick the VPC and which subnets you want to have Cloud NGFW endpoints created in. Do keep in mind that endpoints have a monthly cost, and you will be able to deploy new endpoints later on. So don’t create endpoints in subnets where you don’t have any workloads to secure.

A cool additional feature is the ability to integrate multiple AWS accounts into your Cloud NGFW configuration, which gives you a great central location to secure and apply standardized controls across all of them.

The following architecture diagram gives a great overview of how Palo Alto’s Cloud NGFW integrates with AWS and interacts with day-to-day traffic, and helps visualize how you will define rules against the application identification patterns.

TLS Certificates are a simple and reliable way to identify and secure traffic between applications, and have become an industry-standard best practice. Which means if you are not yet using certificates to secure your HTTP traffic, you shouldn’t wait any longer.

However, certificate management has been tricky for as long as certificates have been around. The metadata attached to them is sometimes cryptic, and generating, attaching, and renewing them usually requires all sorts of human effort or complicated technical “glue” tying different toolchains together. Gladly, the continuous drive from AWS to reduce cloud-native complexity has made services like automated certificate generation available.

With ACM, you can use a private certification authority to sign all certificates generated as well as validate certificate authenticity inside your organization without having to incur additional costs for third-party authentication.

ACM fully automates the generation of certificates for your dynamically provisioned services using either a private or public certification authority. Every time you spin up a new instance of your application, ACM automatically generates a certificate and attaches it, identifying the application the instance belongs to. ACM allows you to define a custom common name, subject alternate name, and other TLS certificate metadata to uniquely identify your applications.

We’re going to use data in the TLS certificate used by the application endpoints to identify which application is associated with the traffic being inspected. Working with TLS certificates can be accomplished in a very streamlined way with ACM, which allows you to use public as well as private certificate authorities, and handles the full lifecycle associated with certificate management, from issuing to assignment to eventual invalidation.

Palo Alto’s Cloud NGFW offers a unique capability called App ID, which automatically identifies a huge array of commercial off-the-shelf applications as well as allows you to define custom applications, using one of various methods to include them in the identification algorithm.

App ID is a patented traffic classification system that identifies applications irrespective of port, protocol, or encryption. App ID uses application signatures to identify each application, using unique application properties and related transaction characteristics to determine which application is generating the traffic.

We’re going to use pattern matching to identify our applications, leveraging the data embedded in the SSL certificate which was automatically generated by ACM, and attached to the running container as shown above.

Once we have created a customer App ID for each of our applications using this pattern, we can create custom rules that allow or deny traffic between identified applications, regardless of the AWS account or VPC in which they’re running, all without a single change to the codebase of your applications.

With Palo Alto’s Cloud NGFW integrated with AWS services, you can achieve a much-improved security stance by:

1. Fully automating the generation and assignment of TLS certificates to your running workloads.
2. Using TLS certificate data and metadata to uniquely identify applications.
3. Matching application identity with security policies, allowing for centralized security controls of inter-application traffic no matter where these applications are running.

With this model you’ll be well on your way to zero-trust security, while dramatically reducing the complexity of managing security in your cloud environment, all without modifying your existing applications.

You can try out Palo Alto’s Cloud NGFW with a 30-day free trial. To learn more about building your own zero-trust security layer step by step, we encourage you to try our hands-on lab covering the topic.