How Aporeto Improves Security for Kubernetes Workloads

By: Don Chouinard 02.28.2018
How Aporeto Improves Security for Kubernetes Workloads

Security is formed around the knowledge of who is trying to gain access to an object, what they intend to do with it, and the ability to allow or deny them access. In the case of Kubernetes, administrator-defined network access policies permit or limit interactions between pods. Ingress and egress traffic is gated based on namespaces, pods, IP addresses (CIDR), and ports. While stock Kubernetes handles all of the mechanics for security, using Aporeto with Kubernetes provides a more powerful, secure and easier to administer solution for hybrid cloud workloads to improve an organization’s security posture – even across Kubernetes clusters in different security zones.

Kubernetes Network Access Control

As described in the Kubernetes documentation, NetworkPolicy resources use labels to select pods and define rules that specify which traffic is allowed. The responsibility for actually enforcing the network policies falls on third-party network plugins. There are a variety of these plugins that have been written for Kubernetes, including Aporeto’s. However, not all network plugins are alike. Network plugins commonly use their own control plane in addition to making too-frequent changes to Linux iptables or leverage Linux BPF (Berkeley Packet Filter) to deliver their functionality. As a result, their performance and scalability vary, as does their ability to keep up with all of the IP routing changes required to track a highly dynamic environment where containers are spun up, closed down and moved frequently.


Figure 1: Kubernetes network access control is performed by the 3rd party provided Network Plugin


Aporeto Network Access Control

Aporeto network access control is compatible with Kubernetes network access control, but offers a compelling superset of capabilities, as described below. To prevent conflicts, NetworkPolicy resources imported from Kubernetes cannot be overridden in Aporeto. The ability of Aporeto to automatically import and apply Kubernetes NetworkPolicy definitions gives Kubernetes users a familiar YAML interface and backward compatibility for declaring allowed network connections. Depending on the security need, Aporeto is flexible with network access policy.  Administrators can use either Kubernetes NetworkPolicy resources, Aporeto Network Policies, or both.

Figure 2: Aporeto Network Policies are a compatible superset of Kubernetes NetworkPolicy resources


How Aporeto Works to Improve Kubernetes Network Access Control

Aporeto provides a significant superset of capabilities for network access control of Kubernetes workloads. Aporeto builds upon the Trireme open source project to deliver a solution that is far more powerful, scalable and easier to administer. Some of the advanced features of the Aporeto solution are summarized in the table below.

Figure 3: Aporeto delivers a superset of network access control capabilities for Kubernetes


Each time a Processing Unit (PU) – which can be a container, Linux process, or external service – attempts to access another PU or resource, the Aporeto Enforcer, a userland process that resides on each host, automatically creates a Trust Profile which travels along with the I/O request. Note that PUs can be running within Kubernetes or external to it, and can span hybrid cloud architectures or even span Kubernetes clusters.

The Trust Profile includes information such as who (user-id as verified by authentication), where (network address of requester), what (information about the service or resource being accessed), metadata (from Linux processes, Dockerfiles, Docker containers, Kubernetes labels, etc.), reputation (from ratings services), and behavior (from past history running in the environment).

Trust Profiles are hashed and cryptographically signed by the Enforcer, to ensure they are genuine and cannot be tampered with.  Each Enforcer has been registered and been granted a signed certificate to create a “chain of trust”. You can think of a Trust Profile as a passport. Every connection request from every PU carries with it a Trust Profile which is used by the receiving Aporeto Enforcer to allow or deny the connection.

By automatically combining multiple factors into the Trust Profile, an unsurpassed security posture can be accomplished with zero manual effort, and it is always current, regardless of how dynamic the runtime environment may be. And because Enforcer has visibility on all traffic, logs help to identify anomalous behavior, including possible security breaches or application bottlenecks.

An Aporeto Security Policy controls what a PU can do within the system. The syntax to define a new policy is intuitive, leading to better application security, visibility, auditability. Better yet, Aporeto will generate the Security Policies for all PUs automatically by watching them run for a period of time. This saves SecOps a lot of work, and promotes full coverage of all interaction paths. To refine the security of the application, Security Policies can be easily inspected and edited. If encryption of data in flight is specified in a Security Policy, Aporeto automatically encrypts the traffic with no changes required for source code and no key management required.


Why You Should Use Aporeto with Kubernetes

With stock Kubernetes, network access policies are applied to containers based on labels. Aporeto uses this paradigm as well, as it eases administration at scale of a dynamic environment. However, where stock Kubernetes only limits traffic based on CIDR and Port, Aporeto utilizes the automatically generated unique identity of individual application components. This allows Aporeto to provide enterprises with security that better enables protection against malicious or unintentional security breaches, from within or without.

Because it employs machine intelligence to generate Security Policies, Aporeto’s solution not only provides better and more thorough security, but its automation reduces complexity and save SecOps time. Aporeto can be used with or without stock Kubernetes NetworkPolicy resources. It uses an open source, industrial strength, userland Enforcer that is easy to deploy and proven to scale, even for highly dynamic environments that potentially span Kubernetes clusters.    

Aporeto is easier to use than network-oriented perimeter security based on Kubernetes NetworkPolicy resources, and provides SecOps with clear visibility of the application’s security posture, not only across Kubernetes workloads and clusters, but across services and resources that are not running on Kubernetes. And because Aporeto is 100% compatible and well integrated with Kubernetes, it’s easy to try out.

Recent Posts Palo Alto Networks Acquires Aporeto Palo Alto Networks Announces Intent to Acquire Aporeto Aporeto – Flexible and Secure by Default