This is the third installment in a series of articles for micro-segmentation with vRA and NSX-V.  The previous articles in the series can be found here:

• Part 1
• Part 2

This article wasn’t going to be written as my mini series was complete on this topic however I discovered an issue with my configuration and wanted to cover it here so that you don’t run into the same thing.

The Problem

At the end of Part 2 we had made some amendments to allow web tier nodes within a deployment to talk to each other on a specific TCP port whilst still blocking web tier nodes across deployments.  All good so far.

As a final validation of what I had been doing I started tracing through the firewall rules to make sure I had covered all my bases, this time specifically thinking about multiple deployments from the same blueprint.  I created a diagram to highlight the issue I found.

The premise of our strategy up to this point was to leverage NSX security groups and policies provided by the NSX admin within the blueprint to ensure one deployments machines cannot reach another deployments whilst still allowing the application to function with only the required ports open.  This works very well when machines are in the same tier (e.g. deployment 1 app servers trying to talk to deployment 2 app servers) but it completely breaks when crossing tiers as the above diagram shows.

Deployment 1’s app servers are in the same security group as deployment 2’s app servers so the firewall rules in the Security Policies cannot separate the deployments.  The same rule that allows app to talk to db within deployment 1 also allows app in deployment 1 to talk to db in deployment 2 (see below).

The “App Isolation” policy created by vRealize Automation also does nothing to help remedy the situation, as it is always at the bottom of the application rules and therefore traffic has already been passed by preceding rules in our “Security Policies”.

The Resolution (Or Not)

Sadly, this is an issue that I have yet to solve with OOTB functionality whilst still maintaining the intra-deployment granular security.  If you are willing to sacrifice this, then you can fall back onto securing the deployment as a whole with vRA “App Isolation” without the individual tier security policies.  Access into all copies of the application can then be controlled by a single “Security Policy” and access between deployments can then be blocked via “App Isolation”.

The resulting single “Security Policy” and blueprint would then look like these.

Another option available (although one that requires significantly more effort) is to build custom firewall services leveraging vRealize Orchestrator and associated plugins instead of the OOTB blueprint links to “Security Groups” and “Security Policies”.  This would allow you to define the rule base however you wanted however it comes with risks, particularly with maintaining a functional set of services as product versions (and APIs) change over time.

I will re-visit this topic again as vRealize Automation evolves.