Aporeto Logo
Aporeto Logo

The cloud has further challenged the static assumptions of VLANs while imposing larger scaling requirements. Spanning VLANs across multiple racks quickly became the bottleneck. Simultaneously, concepts like security groups that AWS introduced were easy for developers to understand and expanded the segmentation model to a more granular level, where any set of hosts irrespective of IP subnets could be grouped together in different trust domains. There is certainly value in the network isolation provided by AWS security groups and the analog provided by other public cloud providers, but there are also numerous pitfalls from trying to manage segmentation this way.

The first issue arises from the fact that very few organizations rely on a single public cloud provider for all infrastructure, requiring them to replicate security policy and network configuration across on-premise and cloud deployments, as well as across several public cloud providers. Many security teams are struggling with just defining consistent security policy across all of these environments, much less effectively implementing them.

Security groups are designed to allow you to enact firewall policies within cloud instances, which reproduces many of the network segmentation challenges described in the previous section. When you try to do unnatural things with network configuration, it does not matter if you’re doing it on-premise or in the cloud with security groups. There are also practical limits on the number of groups and flexibility of the segmentation design that can be modeled in this manner. Managing network configurations and ACLs is challenging enough when you are running the network, but can be even more challenging at scale when you’re trying to model those network policies with a level of cloud abstraction.

Because of the nature of shared infrastructure in public cloud security groups create some unique challenges in addition to those inherent in network segmentation at scale. Elastically scaling and temporal workloads create a dynamism in IP address configuration that is difficult to manage as a control point for security policy. When workloads are replicated or re-scheduled across hosts, as is very typical in a scaled-out cloud environment, the security groups configuration does not handle it well. VPCs can also have overlapping addresses across instances and regions, so the granularity of security policy ends up compromising based on the IP address space and allocation schemes. Network access policies can also become problematic with NAT gateways or load balancers are in play.

All of these factors together make a relatively simple to implement and powerful firewalling feature of cloud computing ill-suited for effectively segmenting and securing modern cloud-native workloads. The next attempt that some security teams make is to miniaturize and virtualize their on-premise security controls and run them as instances in the public cloud to attempt to replicate their on-premise topology and policy. This results in a compounding mess of expensive virtualized security controls costing you additional license and compute costs, while not effectively segmenting your workloads any more than they are on premise.

You can find out more by reading the recently published Cloud Security Gaps Whitepaper here.

Recent Posts Key Security Concerns for a Kubernetes Deployment How We Prevented the Kubernetes API-Server Vulnerability Amir Sharif’s Guest Appearance on Red Hat’s Podcast

Subscribe to Our Blog

x