I wrote a blog post in the VMware official blog about a demo I recorded called “Dynamically enforcing Security On a Hot Cloned SQL Server With VMware NSX“.
A bit long of a title but captures the essence of the demo perfectly. You can see the demo as well here:
I got a question from a colleague of mine with has a very keen eye:
“I just saw the great video you made, at 0:50 second of the demo we can see the rules for the prod app
What is the meaning of rule 6? If the source is the datacenter and is broader than the App Server in rule 5, and the rule allows for ANY service, doesn’t it make rule 5 irrelevant? “
This is a great observation by Manuel with a very simple explanation which demonstrates perfectly the power of VMware NSX, can you figure out the answer?
Rule 6 makes sense, only if you know your NSX 🙂
The port requirement is for 1433. By default, the MS-SQL-M-TCP object is port 1434.
Good catch. Not what I referred to in my question, but nonetheless true.
I also see that the group AppB Servers contains no objects. As a result, rules 4 and 5 do not apply.
Matt, the rules are relevant as they apply to the security group, just haven’t put the criteria yet in this video. But thank you for putting the time looking for these things.
Hi Niran, I can think of two other things: The rule could be used for logging traffic that is accessing the AppB-Prod-SQL-Servers group. The rule could be used for traffic steering, but I see the action as allow rather than redirect.
I’m really interested in hearing what you have to say on the matter.
Both of your suggestions are valid but not what I did in my lab, the explanation is simple. The source in rule 5 is a security group the can hold app servers from more than one Datacenter object, while rule 6 is listed to a single Datacenter. This way I am limiting access to the DB from app servers wherever they reside to a single port, while from Datacenter 01 I’m allowing any port.
Yes, that was simple. I did not consider the scope of the group. Thank you for the learning opportunity.