Aporeto Logo
Aporeto Logo

In part one of this blog we looked at the challenges involved when security for microservices is expressed and enforced as rules that permit one IP address range to interact with another. To protect individual microservices, the perimeter security model has to be replaced with the finer-grained model where security is tied directly to the application components, so it will follow them and be easier for administrators and auditors to understand. That’s exactly what Aporeto does, resulting in increased security and a reduced administrative burden. Aporeto leverages the attributes of containers and Linux processes to establish trusted identities for each, then uses automatically generated security policies to specify which interactions should be allowed between application components. Associating security policies with individual application components is a welcomed evolution from the perimeter security model in which security was tied to IP addresses and ports.

Figure 1: Security needs to be around each service rather than around each host

 

This elevated, application-aware perspective is the appropriate level for hybrid cloud applications. It helps DevSecOps personnel to overcome the problems inherent in the old IP address-based perimeter security model, in which security rules cannot keep up with the frequent movement of application components. With Aporeto East-West traffic between application components becomes fully secured across sites, Kubernetes clusters, and cloud providers using one, consistent model, and with no changes to source code being required.

Rather than the protection surrounding an AWS security group, it surrounds each individual application component. If an open source vulnerability, malicious hacker, or inadvertent human error affects a service, the disturbance will not be able to spread unfettered across the security group. Encryption of data in-flight can happen based on a new security policy being created in Aporeto, with no need to change source code, put into place VPNs or manage encryption keys which allows security teams to sleep much sounder at night.

 

Identify Each Application Component

Aporeto identifies each application component based on its unique attributes, including:

  1. The User-ID it is running under
  2. The hash of the image
  3. Docker container labels
  4. Labels assigned via the Aporeto GUI, CLI, or API
  5. Attributes from the runtime environment
  6. Attributes from the AWS EC2 Instance Identity Document

 

The Enforcer

Each Host (physical or virtual server) runs the Enforcer. The Enforcer is the traffic cop and by default blocks all IP connection requests and access to other host resources. Network Policies and File Policies select Linux processes and containers, based on their tags, and explicitly define what they should have access to. Editable Policies can be automatically generated by the machine intelligence capabilities of the Aporeto solution in an “observation mode” and pushed to the appropriate Enforcer on each Host, eliminating the need for manual administration and delivering unsurpassed scalability.

Aporeto Enforcer allows or denies connection requests between services

Automatic Security

When an application component attempts to establish an IP connection or open a file, the request is intercepted by the Enforcer and wrapped in a cryptographically signed Trust Profile that includes all of the identity information for the requesting component. Based on the security policies that apply, and the Trust Profile sent along with each request, the receiving Enforcer will either permit or deny the operation. This is how each application component gets a security perimeter automatically created and enforced around itwith no manual effort or changes to source code required. The net result is an unsurpassed security posture across a hybrid cloud computing environment that is easy to deploy and administer over time.

Aporeto AWS Integration

When Aporeto is used on AWS, it gathers additional tags from the EC2 Instance Identity Document – a JSON file that is generated by AWS when the EC2 instance is launched. These tags provide additional context about the application components to help Aporeto to determine what should not be allowed. The EC2 Instance Identity Document (IID) is cryptographically signed by AWS, so once verified as authentic, Aporeto can rely on the tags extracted from the IID to be accurate and true. Another key integration point is that whenever an EC2 instance is spun up, the Aporeto Enforcer can be automatically installed, started and auto-registered with no manual intervention required.

Net Result

The net result is that with Aporeto on AWS, security is increased while the burden of administering security is decreased. No longer does the organization struggle with matching up the accelerating and decelerating application components that are moved by the orchestrator with rigid IP address and port rules, using disparate security syntaxes across sites and clouds.

Rather, services are uniquely identified by a collection of attributes and security is enforced based on established policies that are tied to application components, rather than IP addresses of hosts. This is a more natural model for both legacy and cloud-native application security. As such, it is easier for DevSecOps personnel to understand, put into place and maintain over time resulting in an improved security posture that always stays current (and a happier DevSecOps team).

Learn More

To learn more, read our whitepaper on The Best Way to Strengthen Security on AWS.

Recent Post Notes and Impressions from this year’s Red Hat Summit Enterprises Are Becoming Cloud-Native, But It Is A Journey – Thoughts from KubeCon The Security Blast Radius in Cloud Native Applications

Subscribe to Our Blog

x