Micro segmentation divides the data center into smaller, more-protected zones. The servers can be added to multiple application tiers and depending on the type of application, traffic flow is controlled when it flows from one tier to another tier rather than individual server ports. In a real world scenario an application tier may not have a 1:1 mapping to a Layer 3 subnet. So applying firewall rules on the physical or virtual firewall appliance based on the IP address of the server becomes highly un-manageable and not scalable.
With Contrail security groups feature one can follow a declarative model to label the servers based on the application it is catering to and then constructing security rules to define the traffic flow between these different applications rather than referring to IP addresses.
Use case example:
As shown in the below figure the subnet 172.16.0.0/16 is hosting all the servers and these servers may be any of web, application or database servers depending on the end-application requirement. In this specific example we have 2 servers in each tier.
As shown by the arrows at the bottom of the figure the idea is to make sure that the web tier can talk to the app tier and the app tier can access the db tier , but the web tier cannot access the db tier directly.
For the simplicity purpose the use case in this example is demonstrated using ssh.
The idea here is to create security groups one for each tier. And under the security group match condition we will match the traffic flow between different application tiers by matching the security group names we have created for each of the application tier and the traffic direction instead of matching individual server IP address or subnets. And then launch the VMs by associating them with the respective security groups based on the tier they were launched.
Check 1: Login to a machine in web tier and ssh to VMs in app tier. Ssh should be allowed to pass through.
Check 2: Login to a machine in web tier and ssh to a VM in database tier. Ssh should be blocked.