Aporeto in Action
[Start of recorded material 00:00:00]
Male Voice: Aporeto makes cloud-scale container security faster and more efficient by driving policy, enforcement and visualization with well-known attributes – all with zero touch from developers. In this demonstration video, you’ll get to see Aporeto in action as we secure a globally distributed application running in containers and Linux services across multiple clusters. Let’s preview the workflow that will be presented in this demonstration. Here’s what we’ll show in this demonstration.
First a brief overview of the Aporeto components – process visualization, including process attributes and a simple container policy example. We’ll then use that container policy to show authorized and denied connections between services as well as a one-click network policy option for transparent encryption between services. Since Aporeto enforces policy at the process level, in steps three and four we’ll zoom out from a single node to the global heterogeneous environment of Kubernetes, Docker and Linux with a single policy that secures access between distributed services. In step six and seven we’ll look at how you can drill through the analytic noise with grouping and filtering on both live and historical views so that you can visualize live service connections and rewind history for diagnostics and forensics.
With Aporeto every unintended connection is a threat. Aporeto cloaks your application from unauthorized services. In step eight, we’ll see who’s been trying unsuccessfully to discover our Aporeto protected services over a 12-hour period. Finally in step nine, we’ll show you how Aporeto’s policy engine is dynamic, responding automatically to common vulnerability and exposures, also known as CBE data, to protect services. With this preview you’re ready for the Aporeto demonstration.
Let’s first go over the Aporeto components. An Aporeto installation is composed of two main components. The first is the Aporeto security orchestrator, the central point for container security policy and visualization. The Aporeto security orchestrator pushes container policy to the second distributed component, the Aporeto enforcer, which runs as a Kubernetes DaemonSet, a Docker container or a Linux service that is deployed with zero developer interaction.
Let’s look at how Aporeto visualizes processes. I will demonstrate security in a Kubernetes cluster in AWS with a busybox service and two nginx instances. When a pod is created in Kubernetes, Aporeto automatically gathers attributes about the application service from API calls to the cloud provider and Kubernetes. Based on these attributes we automatically associate the appropriate Aporeto policy. Said another way, Aporeto is unique in its capability to let you visualize services, their attributes and what your services are allowed to connect to.
Let’s review the Aporeto policy. From an auditability and readability perspective, the Aporeto policy as a source destination action structure. The policy drivers are container attribute tags that give the Aporeto security policy unlimited flexibility to make decisions based on container identity and context. This example policy secures a specific application. You can use any application attribute to drive policy. You can further secure services and apply policy by other attributes from the compute platform or a cloud region and other attributes. Note the security policy in Aporeto is independent of IP addresses, which are undependable in the ephemeral container and cloud services world.
Let’s go back to the service view and establish connections. Let’s start with an authorized connection. In the TCP three-way handshake between these two services the enforcers authenticate the tags and authorize the connection via the tags and network policy, allowing the connection to establish. Now let’s attempt a connection between busybox and the other nginx service. This time the enforcer for the second nginx instance authenticates the tags for busybox but with no policy that authorizes app one and app two to communicate. The service doesn’t even respond.
Let’s look at how we can add encryption without developer interaction. For added security Aporeto can instantly encrypt authorized connections between services and automatically rotate keys. Not only do your developers not have to encode service authentication and authorization, but with a single click policy change there’s no need to implement encryption.
Now when we reestablish the connection, the enforcer instances automatically apply AES 256 payload encryption to the authorized connection, keeping prying eyes away from sensitive data. Let me show you how the Aporeto security model transcends across different clouds. Since Aporeto enforces at the process level, we can apply the security control and encryption, not just in the same namespace but also across different Kubernetes namespaces, nodes and even multiple clusters and clouds.
Let’s expand this service view for multiple clusters, multiple regions and multiple cloud providers. Let’s visualize the effects of our single policy for the zero trust world. In this view we can now see services grouped by cloud provider, AWS and GCP, regions and platform type. Since Aporeto enforces security at the process level you can control access between services and a heterogeneous compute platform environment of Kubernetes, Docker and Linux. Let’s add Linux and Docker to this view. Remember that we’re controlling access to these application services deployed across the cloud with the single instance of security policy. Aporeto was designed for a zero trust world. We let you carve out a private piece of the internet for your secure service communications for your application with simple yet powerful policy controls and with enforcement anywhere your containers run.
Let’s look at how Aporeto helps you visualize services and policy affects how you want to. As you deploy more services you can use Aporeto’s visualization functions to help you clearly understand how your services are communicating. You can group by any of the application attributes. In this example, we grouped by cloud provider, cloud region and compute platform. You can also filter for services with specific attributes to find out things like, “Where are my services for AWS and GCP?” In Oregon, running in Kubernetes, Docker or Linux. Let’s see how Aporeto can show you not only what happened but when with our container time machine. When were services communicating?
With all the flow and services data backed by a time series database, we can view policy enforcement live and in the past. From troubleshooting network policy to forensics on internal unintended access or external threats, Aporeto’s service views help you understand when and where services communicate. Let’s see how Aporeto cloaks your services in the zero trust world. With application’s security model your services are cloaked from external discovery. With no policy that permits these SSH connection attempts, the SYN packets are dropped, effectively cloaking our service. None of these external entities knocking on our door are even aware of our service. In this view, we can see attempted and denied SSH attempts to one of our hosts. Then with a single click you can see what external addresses are communicating with your services and even overlay those addresses on a map.
Let’s look at how Aporeto protects you from container image vulnerabilities. With container images it’s not about if you have a vulnerability. It’s what your security posture is based on the vulnerabilities. With Aporeto, the individual container vulnerabilities and the overall vulnerability level become part of your services identity. Perhaps you’re okay with services with a medium level of vulnerability connecting in your development environment but not in production. Or perhaps you want to quarantine a service and even prevent it from starting. Let’s review the Aporeto demonstration. We went over the two Aporeto components – the Aporeto security orchestrator and a distributed enforcer node component that runs on your compute platforms as a Kubernetes DaemonSet, a Docker container or a Linux service.
With a single, simple Aporeto policy definition we secured two application services in a multi-cluster, multi-cloud environment, including Kubernetes, Docker and Linux. We used Aporeto’s visualization tools to see live and historical results of security policy enforcement between services in the Aporeto domain and cloaked application services from potential external threats. Finally, we saw how container image vulnerabilities can be used as factors to enact dynamic security policy. Aporeto is a new container security model that transcends clouds, untethered from complex network infrastructure. Aporeto allows you to move fast, be more secure and let’s your developers develop. For more information on how you can simply secure your containers anywhere, visit us at https://www.aporeto.com.
[End of recorded material 00:09:21]