That is, what's the advantage over just creating section in DFW and adding SG related rules there?
It is my believe that Service Composer is a really great tool if you want to repeat lots and lots of firewall rules (in a Service Provider environment for example). So if you have a really dynamic environment, where applications are constantly being created, destroyed, re-created, etc., Service Composer can be a really powerful tool (especially when using vRealize Automation).
If you have a static environment, where there is no use case for reusing the same firewall rules over and over, then in my opinion you should not use Service Composer and instead just create the firewall rules in the Distributed Firewall directly.
Can you expand on that a bit? So in a very dynamic environment - you could tag or untag VMs at
will to be part of a security group, say call it HIPPA-1. So by using tags instead of VMs you've
allowed for the dynamism of having say a system get the right security policy just by having
tagged it - and all without modifying a single security rule and certainly without adding a new
rule. BUT, the security rule governing this tag it seems to me could just as easily be a rule
in a section created in the DFW as it could be a rule created in a Service Composer rule
set which is associated with that Security Group.
Does that make sense? It seems similar to the having your money in your left pocket or your
right pocket. And with the DFW rule export, you may actually have better visibility of your
Not being argumentative. Just trying to drill into the benefit.
Great follow-up question! And yes, it does make sense 🙂 So let's dive a little bit deeper into the bits and bytes.
First of all, you're mentioning using tags. That is definitely the way to go, with or without using Service Composer. So you tag a Web VM, which then gets dynamically added to the SG-Web Security Group and this Security Group is then used as a source and/or destination in the Distributed Firewall. This works great in both static and dynamic environments.
But then we get to the Service Composer...
If you look at the Service Composer, you basically have two things: what you want to protect (a Security Group, with static and/or dynamic members) and how you want to protect it (Security Policies, whereby the source, destination, or both can be a Security Group). You then basically apply a Security Policy to a Security Group (which then becomes the source, destination, or both for all the firewall rules defined in the Security Policy). All great stuff, but you can see how this can become messy and unmaintainable in static environments. Because if you have 500+ applications that don't in the slightest look like each other, how are you going to create reusable firewall rules for all of them using Security Policies? Sure, it can be done sometimes, but most of the time all of your applications are just too different and require different firewall rules. Service Composer, in that case, is not your friend.
For me personally it boils down to:
- Is the environment static? Don't use Service Composer.
- Is the environment dynamic? Let someone else use Service Composer (I really don't like SC 😉
- Is the environment based on NSX-T? There is no Service Composer.
So to recap, if you have a static(-ish) environment with lots of different applications, which look nothing like each other and you see no way to create reusable firewall rules, then the best way to go is to just simply use the Distributed Firewall and create your own Sections and firewall rules. Remember, this is exactly what Service Composer does as well: create Sections and firewall rules. It's just automated. But the firewall rules that your applications need to function correctly (whether defined in a Security Policy using Service Composer or directly in the Distributed Firewall itself)? They are basically exactly the same.