Enforcer and processing units
Enforcer is an agent that runs on your deployed server and applies any policies which you have defined in the control plane. Once deployed, the enforcer agent connects to the control plane using credentials just as any other client does, and it is bound to API Authorizations. The role of the enforcer agent is to protect any unit of computation called processing units.
Enforcer can protect traffic between two processing units at different layers of the network stack. At layer 3, it automatically adds the processing unit's cryptographically signed identity during the
SYN/SYN->ACK portion of TCP session establishment (or by using UDP options in the case of UDP traffic). At layer 4, it exchanges identities after a TCP connection is established, but before any data traffic is allowed to flow. In this case, it utilizes TCP Fast Open to minimize the round-trip times needed to complete a robust authorization.
The addition of these cryptographically signed tags allows Aporeto to exchange and verify the identity of both processing units and validate if there is a Network Access Policy which will allow or deny traffic between the two endpoints. Once the authentication and authorization is complete, the enforcer allows both processing units to communicate directly.
At layer 7, the enforcer operates as a full API proxy and injects authorization information on every API call. In this case, it can perform per API endpoint authorization between processing units as well as between users and processing units.
The content of traffic is never visible to the control plane or the enforcer. The enforcer's role is to allow or drop the connection establishment depending on policies it has received from the control plane.
Enforcer can be installed:
- As a Kubernetes DaemonSet
- As a plain Docker container
- As a Linux
- As a sidecar in service mesh architecture
Authentication and authorization
Instances of enforcer are classic API clients to the platform, and they are governed by the same authentication and authorization mechanisms as any other client. They must be authorized to perform their operations.
There are multiples ways to authenticate an enforcer:
- Using Aporeto application credentials
- Using authentication via cloud attestation:
- Amazon Web Services
- Google Cloud Platform
- Microsoft Azure
As usual, authentication is not enough, there should be an API authorization policy assigning the correct roles.
In the case of application credentials, the associated API Authorization is automatically created.
A processing unit represents a unit of computation which enforcer will protect by applying policies.
It can be:
- A Docker container
- A Kubernetes pod
- A Linux process
- An entire Linux host
- Specific services (protocol/port pairs) in a Linux host
- A user Linux session
Enforcer reports the processing units and the network interactions it protects to the control plane so you can visualize your application flows.
It will apply default tags to the processing units according to what it finds.
For example, a docker container will be tagged with the docker image name, a process with its PID, a host with the
hostname, a pod with its namespace, and so on.
This set of predictable tags can be use to write policies.
An external network refers to anything that is not protected by an enforcer and still needs to be accessed using the basic access control lists. Like any other object, tags can be associated to an external network so it can be used in a policy.