This is the second post in a series about how the Cloud is changing how we manage network access control and application identity. In particular, my thesis is that the use of a network-centric identity such as an IP address or subnet to identify an application is waning and are being replaced by identities provided by core compute and network platform services.

Good things happen when the compute platform:

1. uniquely identifies each compute instance: virtual machine, container, or function
2. and provides a way for the application(s) inside that instance to prove it to others

That’s a chain of trust.

There are two robust and common ways for compute platforms to make those good things happen:

First, provide a “metadata” endpoint where only applications inside the compute instance can retrieve an “instance identity document (EC2).” We’ll explore that in a later post on application identity.

Second, the compute services can integrate deeply and securely with the networking and firewall services so that the networking services can be sure that a network packet coming from a compute instance attached to the network really came from that instance and its IP or managed network interface. As Colm MacCárthaigh, AWS Principal Engineer (Networking, Cryptography), explains:

The short of it is that traffic simply can’t be man-in-the-middled or spoofed on the VPC network, it’s one of our core security guarantees. Instances, containers, lambda functions, and Elastic Network Interfaces can only be given IPs via the secure and audit-able EC2 APIs.

Firewall services can do some very interesting things when they can trust:

1. that network packets are coming from where they say they are
2. “who” is at that IP or identified by a firewall rule is always available via an up-to-date API

The practice of “Security Group Chaining” leverages these properties and is a nice evolutionary step if you have been using IP addresses or subnets to control access to applications.

Security Group Chaining

In AWS, a set of firewall rules that can be applied to a network interface is called a security group. One very neat thing about AWS Security Groups is that you can configure one security group to trust the traffic coming from the members of another security group.

This practice is called “security group chaining” and it is usually covered on the AWS Security and Architecture certification tests :).

Let’s work through an example.

Suppose you only want to permit traffic to an ecommerce application frontend from that application’s load balancer.

Security group chaining works by:

1. creating a distinct security group for the ecommerce app to trust, e.g. named sg-ecommerce-lb; this security group might permit https traffic (only) on port 443 from the Internet
2. configuring the application instance’s firewall, sg-ecommerce-frontend, to trust network ingress from sg-ecommerce-lb.

What this really means is that (only) the set of compute instances with the sg-ecommerce-lb attached will be permitted to send traffic to sg-ecommerce-frontend instances.

There are a few important things to note:

• We don’t know or control the IPs the load balancer instances will have and they can change at any time. The ELB service is a managed load balancer service and new instances will come online to replace existing ones in the event of software upgrades, availability events, scale up or down, etc.
• The load balancer IPs are managed by EC2 and come from AWS’ (enormous) public IP blocks. It would defeat security access controls to enable network access to our internal applications from those blocks using CIDR notation.
• EC2, VPC, and ELB manage IP allocation and security group membership automatically, according to your configuration.

This approach to control access to an application works in AWS because the compute, networking, and firewall components are so tightly integrated. The membership of security groups updates automatically with trusted identity information from the compute platform and the network guarantees packets actually came from where they say they did. This approach is useful for securing basic network flows between applications.

Next, we’ll explore application-level identity provided by the compute platform’s identity services and how to implement access control to cloud-managed data sources.

Stephen

#NoDrama

KEEP LEARNING

 

 

 

Receive #NoDrama articles in your inbox whenever they are published. Reply to Stephen and the QualiMente team when you want to dig deeper into a topic.

SUBSCRIBE!

You have Successfully Subscribed!