Aporeto Logo
Aporeto Logo

Coming out of AWS re:invent this year it is impressive to see the adoption of public cloud across companies in all industries even the most conservative and heavily regulated ones. During the conference, Amazon launched 100s of new features to help enterprises efficiently consume cloud infrastructure, improve the application deployment experience and offload as many non-differentiated services as possible. Technology is a differentiator for all companies and leveraging the cloud to deploy business critical-applications is key.

 

The ideal application development and deployment experience is to have developers write and test their applications in their environment and be able to securely deploy that same application across any cloud (public or private) environment seamlessly. This is a journey that involves the adoption of microservices, container technology and treating your infrastructure as code. What is missing is the relevant security approach. The existing approaches to implementing security when going through this journey create tremendous management overhead and lower application deployment velocity. Let’s discuss some of the reasons why.

 

Most customers on AWS enforce security policies through security groups, VPC isolation, and 3rd party appliances. Except for the last approach, which we will address later, all of the capabilities mentioned here are tied to the network infrastructure. Tying application security to your cloud providers infrastructure is a challenge because it gives you less control, less security portability, and less visibility. Even when using programmatic ways to configure security policies there is complexity and management overhead in maintaining those security policies as your cloud footprint grows. This complexity is even more pronounced with cloud native applications consisting of ephemeral components. If 3rd party appliances are deployed for security and segmentation maintaining high availability for these appliances in the cloud and manual configuration of these appliances are very challenging.

 

Alternatively, consider a zero trust flat network with any-to-any connectivity much like the internet, but only sanctioned communications between application components are permitted. Each application component is given a signed identity through a set of system and user-generated metadata derived from the application or underlying host. Security policies are now created and enforced through the trusted identity of these components regardless of where they reside. As the application components scale or are rescheduled across hosts security policies are enforced dynamically without user intervention.

 

Visibility of application communication is key to ensuring the right security policies are in place. Most AWS customers have to rely on VPC flow logs to try and derive this connectivity map today. Unfortunately, flow logs are meaningless especially for ephemeral components because the IP of a component can change over time and will most likely be re-used. Netflix had a fascinating talk at re:invent highlighting all the custom software they had write to make sense of VPC flow logs when dealing with microservices. This is a very “heavy hammer” approach to solving this visibility problem and most customers will not want be able to invest in doing this work. Customers need a consumable solution to solve this visibility challenge. Going back to the concept of identity we can leverage that same capability to discover and label every application component regardless of where it is hosted and derive a connectivity map.

 

Security has for the longest time been tied to network constructs, but the adoption of cloud is challenging this practice. Now there is an opportunity to re-think security. Stay tuned for more thoughts on this topic.

Recent Posts Key Security Concerns for a Kubernetes Deployment How We Prevented the Kubernetes API-Server Vulnerability Security Groups and their Pitfalls

Subscribe to Our Blog

x