Aporeto – Flexible and Secure by Default

By: Chris Serafin 12.12.2019
Aporeto – Flexible and Secure by Default

Why is Aporeto Secure by Default?

Whether you are using Amazon Web Services (AWS), Google Cloud Platform (GCP) or Microsoft Azure, you can run your applications in VMs managed in any cloud infrastructure. It also means that you need to secure your application depending on where it is running.

Each cloud provider has its own way of managing access to your resources (security groups, VPCs, service accounts…). 

  • If you haven’t configured anything yet, your resources will be automatically publicly accessible. 
  • If you’ve secure your application, you already know it’s quite confusing, and depends on each cloud providers tools.

Aporeto provides a daemon agent called the Aporeto Enforcer that can be installed in your resources. As soon as it is installed, the traffic to and from your resource is automatically blocked unless you define an Aporeto rule to allow it. This is why Aporeto protects your resources by default. Aporeto can secure your resources across all on-premises, private, hybrid, public and multi-cloud environments.


What Does Aporeto Provide? How Does it Work?

Aporeto is based on the Zero Trust networking concept. This concept is quite simple; imagine that you have an open network where everything is publicly accessible. On top of that open network layer, you still want to add your own security rules to meet your own requirements. How can Aporeto help?

Aporeto provides the security layer that protects the network. Because you are no longer dealing with the network layer, you no longer need to use IP addresses or firewall rules. Instead, you can create your security policies based on what is running in your network.

The Aporeto Enforcer provides information about anything that consumes the network. For instance, you can get information about:

  • What application is running
  • Where the application is currently running
  • Who started the application

All of this combined information is representing your application: It is like an ID card that proves an individual applications identity. At Aporeto, we call this the contextual identity of your application. You can now use this information to shape your security rule that makes sense for you.

For instance, imagine you have a 3-tiered application with a frontend, backend and a database. You probably want your frontend to be able to communicate with your backend. 

You can apply the following Aporeto rule:

Allow traffic from anything that has the tags app:name=A AND env=prod AND app:role=frontend to anything that has the tags app:name=A AND env=prod AND app:role=backend.

This brings multiple benefits:

  • This rule is meaningful for your organization and does not rely on IP addresses.
  • No matter where your app is running, your policy won’t change. 
  • You can add an additional backend and it will automatically match this rule.


Aporeto Flexibility

The real power of the Aporeto Platform is its flexibility. It comes with a set of tools that makes it easy to integrate or interact with your environment.

Here are some some small examples of interactions you might be interested in:

  • Log everytime a policy rule has changed
  • If somebody is trying to connect, trigger an alarm
  • When traffic has been rejected for a certain period of time, send an email
  • Everytime an object is created, consolidate the information in Splunk

These were simple examples. There is no real limit here! 

To achieve that flexibility, here is a set of tools that are available to you. I will go into more detail about each tool below:

  • The Command Line Interface 
  • The Golang SDK
  • Hooks
  • Automations
  • Events Listener
  • Application


  • The Command Line Interface (CLI)

The Aporeto CLI (apoctl) is probably the first tool you will use. It allows you to interact with the REST API. You can use it to authenticate and manage your Aporeto policies and other resources.

It sounds pretty basic, but it’s always the quickest way to verify your authentication token, and list some data. As it interacts with the Aporeto API, everything you can do through the UI can be done through apoctl.

>  apoctl is very reliable as it is auto-generated, and Aporeto test pipelines use it internally as well.


  • The Golang SDK

As for the CLI, the SDK allows you to interact with the REST API and you can use it with any action you can access through our web UI.

The SDK has been built in a very symmetrical way: Learn how to use it for a single resource, and it will always work the same way… always.

The SDK is currently only available in Golang. However, it is worth mentioning that it is extremely reliable and tested since we are using it to develop anything at Aporeto. All our micro-services are based on that SDK!


  • Hooks

Hooks give you the ability to trigger your own API when something happens in the Aporeto system. Register your hook in Aporeto, and we will send you a request to enable the endpoint.

You can decide what your API should be called before or after the resource has been created, updated or deleted. It is particularly useful when you want to control whether or not the action on an Aporeto resource should be allowed.


  • Automations

Automations allow you to define custom behavior such as:

IF [something happens] THEN [do something]

It works by defining block components:

  • A condition that defines when something happens.
  • A set of actions that will be run when the condition will be met.

Automations are slightly different than hooks as defined below:

  • The code runs in Aporeto and not on your side.
  • You can define your own code blocks.
  • Hooks have different types of triggers:
    • On schedule  – for example, run this automation every 24h
    • On API event – Almost similar to the hook “after” the action has already happened
    • On a remote call – Allows a call to an automation from outside. We will provide a URL to trigger your automation from outside of Aporeto.
    • On a hook – Instead of asking you to define a REST API, you can ask a hook defined above to trigger an automation for you.


  • Events Listener

The Events Listener is very useful if you want to get near real time data from Aporeto. It allows you to inject the data in your favorite SIEM including Splunk, or just log whatever you want.

This script is running on the Aporeto side and listens to all the notifications our streaming pipeline is receiving. It simply forwards these events to wherever you would like it to go.


  • Applications

Aporeto has a way to develop internal applications that can be listed in the UI and deployed whenever you want. See this feature as a marketplace where you could run predefined – but parameterized apps.

The more concrete example is our Vulnerability Scanner. Technically, it uses hooks to trigger the scanning of your docker images. We bundled this code into an application that you can now run from the UI. 

By following the above steps, you are now able to use the Aporeto platform on any heterogeneous infrastructure to deploy an application.

For more information on how Aporeto can provide your organization with a Zero Trust cloud security solution, read our whitepaper Zero Trust Security Solution for Microservices, Containers and Cloud or Request a Demo today!

Recent Posts Palo Alto Networks Acquires Aporeto Palo Alto Networks Announces Intent to Acquire Aporeto Are You Only 2 Commands Away From Credential Theft?