Hello,
we are using NSX-T 2.4.1
Our take on micro-segmentation consists of grouping VM’s not by functionality (web server, DB, etc.) or division (HR, Finance, etc.), but by business unit or IT service (for example antivirus infrastructure, Exchange, custom application #1 and so on).
Each VM is named and tagged after the business unit/IT service through which it is generated: for example, AV VM’s are named its_av[000-999]. Each of its_av VM receives a security tag (st.its_av) and is linked to a Nsgroup (sg.its_av) whose membership criteria is, you’ve guessed it, st.its_av.
That allows us to grant or deny flows between IT services easily, and also inside them if we want to go even further. Simple enough, right ? We have followed best practices (IP sets are only for physical or virtual machines outside our new VM infrastructure, always apply firewall rules to groups and never directly to VM’s to avoid ‘emply’ FW rules when VM is erased, always use dynamic membership when you can, etc.) but we don’t like the idea of having VM’s with a long list of Security Tags, because it can become confusing with 10 or more ST’s.
We have many ways to group VM’s together and we are still unsure how to proceed in the future. We have these possibilities:
- Nsgroup and membership criteria are security tags (could be a LS, an IP set, a VM, etc.) – we can restrict to a Scope criteria
- Nsgroup and members are an AD group, a VM, another Nsgroup, etc
- IP sets and members are IP addresses
In short, we have various ways of achieving the same result, which is allow a certain group of NSX objects to access another group of any NSX objects.
From your own experience, what are/were the pitfalls you encounter/ed during deployment?
What were the perks and quirks of your own way of dealing with micro-segmentation?
What would be the best advice or piece of information you wish you knew before implementing your model?
Do you use the Scope criteria when grouping VM’s through security tags?
Thank you very much in advance !
