NSX Service Composer: Methodology Concept


Recently in one of my NSX projects I was asked by the customer to develop flexible yet simple to use Security methodology of working with NSX service composer.

The focus was to build the right construct of security groups and security policy based on following requirements:

  • The customer owns different environment types: Dev, Pre-Prod and Prod, Each environment required different security policy.
  • Customer would like to avoid creating specific blocking rules between the environments, such deny rules will cause operation complexity. Security policy should be based on specific allowing rules while all others traffic will be blocked in the last cleanup rule.
  • Minimizing the human error of connecting workload to the wrong security group, which may result in giving it an unwanted access. For example connecting Prod workload to Dev security group.
  • The customer would like to protect 3-tier applications (Web, App and DB), these applications run on 3 vSphere clusters (Dev, Pre-Prod and Prod) .


To achieve the customer requirements, we will build a security concept that is based on the NSX Service Composer.

We will demonstrate the implementation of security policies and security groups to protect 3-tier applications, based on the assumption that the application run on pre-prod cluster but the same concept applies to any cluster.


Security Level Concept:

We will use the concept of “Security Levels” to differentiate between firewall rules granularly.

Each level will have different firewall access policy starting from zero (no access) till the highest level (Application access).

Level-1 Basic Security groups (SG)

Level 1 (L1) SG used to create the building block for the firewall rules, we are not using any security policy directly with Level 1 security groups.

The following security groups created at Level 1:

Cluster SG

Cluster Security Group represents different vSphere clusters.

In our example: Dev, Pre-Prod and Prod. (Some customers may have only two clusters (Dev and Prod) or a similar scenario.

For each vSphere cluster we will have a dedicated security group. Any deployed VM will be included automatically and dynamically in the relevant Cluster security group.

For example: any VM from Pre-Prod cluster will be included in “SG-L1-CL-Pre-Prod” security group.


By creating this dynamic criteria, we have eliminated the need for manual human action.

We can leverage this ability further and create Security policy levels on top on this one.

By doing that we are reducing the human error factor of connecting Virtual Machines to the wrong security groups and as a result enabling them with dangerous unwanted security access.

In Level-1 SG, the machines are member only in a cluster security group representing its vSphere cluster environment and it will not get any dFW rules at this level.

Environment Security Group

This Security Group represents the environment that the machine belongs to.

For example: We might have a different Prod env for IT, R&D, and Sales.

This is very useful when we want to say that a machine is “Prod” and running in “R&D” env rather than “Sales”.

Env-L1 could represent different departments or projects in the company according to the way you build your infrastructure.

For example we will create a security group called “SG-L1-EN-R&D” to represent any machine owned by R&D.

The membership criteria in this example is security tag called “L1-ST-ENV-R&D”.


Application Security Group

The Application Security Group comes to indicate the application installed on the machine (For example: Web, App or DB).

Virtual Machines will be assigned to this group by NSX security tag.

An example of security group name “SG-L1-Web” with match criteria security tag called


The full list of level 1 security tag shown in image bellow:


Level 1 Security Groups Building Blocks Concept:

Level 1 Security Groups Building Blocks Concept

Level 2 Infrastructure Security Group

Infrastructure rules are used by machines to get common System Services like: Active directory, DNS, Anti virus and different agents and services that manage the environment.

Combining both L1-Cluster and L1-Env security groups (with Logical “AND”) will form the “Infrastructure” security group shown as Level-2 that allow the Virtual Machines to get infrastructure security policy based on the VM role.

For example, we will create Level 2 Security group called “SG-L2-INF -R&D“, this SG represent Virtual Machines from the SG-L1-CL-Pre-Pre SG  AND belong to SG-L1-EN-R&D SG environment.

The match criteria are security groups, we called this nested security groups.


The Result of adding Level 2 security on-top of Level 1 security is illustrated in the following diagram:

Level 2 security


Level 3 Application Security Group

Level-3 security group are used for application access level. Security groups in this level are combining a level-2 infrastructure SG AND a level 1 application SG.

For example, we will create the security group “SG-L3-Pre-Pro-WEB” with dynamic membership criteria matching of L1 Security group “SG-L1-WEB” and security group “SG-L2-INF-R&D”:


The relation between the different security groups is illustrated in the next diagram:

Level 3

For example, web VM from the web tier. This VM was deployed to Pre-Prod cluster, as results this VM automaticity belong to “SG-L1-CL-Pre-Prod.

The VM got the NSX security tag called “L1-ST-EN-Pre-Prod” and as result it will be a member of security group called “SG-L1-EN-Pre-Prod”.

The VM was attached with the NSX security tag “L1-ST-APP-Web” and is now a member of security group called “SG-L1-APP-WEB”.

Because of the membership in both security groups: “SG-L1-EN-Pre-Prod” AND “SG-L1-APP-WEB” this VM is automatically a member of security group called “SG-L2-EN-Pre-Prod”.

As a result of the VM being a member of “SG-L2-EN-Pre-Prod” and “SG-L1-AP-WEB” it will automatically be member of “SG”L3-Pre-Prod-APP-WEB”

Please note we’re demonstrating here just the WEB tier what the same concept Apply to APP and DB tier.

Service Composer Security Policy

Security policy for L2 infrastructure workloads in service composer includes generic firewall rules to enable workloads with infrastructure system connectivity like DNS,AD, Anti-Virus etc..

For example Level 2 security policy named as “L2-SP-INF-R&D” and contain example of 4 firewall rules:


then we’ll apply the “L2-SP-INF-R&D” security policy on the “SG-L2-INF-R&D” security group.

Service Composer Application Security Policy

Security policy for Application workloads in service Composer includes firewall policy for application. For example, the web tier security policy called “SG-L3-R&D-WEB” and contains one firewall rule:


Then we will apply the “L3-SP-R&D-WEB” to security policy on the “SG-L3-R&D-WEB” security group.

Example for security policy to allow the Web tier to talk to App tier with Tomcat service:


Then we’ll apply the “L3-SP-R&D-APP” security policy on the “SG-L3-R&D- APP” security group.

Example for security policy to allow App tier to talk to DB tier with MySQL:


Then we will apply the “L3-SP-R&D-DB” to security policy on the “SG-L3-R&D-DB” security group.

Starting from NSX version 6.2.x we can enable the “Apply To” feature to automatically enforce security policy on the security group object instead of the default distributed firewall (means apply the policy anywhere).

This is a great feature that help us avoid “spamming” of objects with unrelated dFW rules so we are more efficient with our system.

To enable this feature we need to use the following steps. In Service Composer click on “Edit Policy Firewall Setting”


Then choose the checkbox the “Policy Security Group” instead of “Distributed Firewall”.


We can view the full service composer firewall result in the “Firewall” Tab:


To demonstrate the effective security policy combined with the different security levels let’s look at ‘Monitor -> service Composer’ at a VM object level.

Here is screenshot of Web-02a VM part of the WEB tier:


The effective security policy for web-02a can be verified under Monitor -> Service Composer tab in the web client:


The effective security policy for App-02a can be shown in the Monitor -> Service Composer tab:


The effective security policy for DB-02a can be shown in the Monitor -> Service Composer tab:


To recap the complete Security Group list:


The complete Security Policy list:


I would like to Thanks to Daniel Bakshi that review this blog post.


Reference blogs post by my colleagues:

Sean Howard wrote great blog post with service composer concept:


Anthony Burke also Cover the Service Composer subject :


And from  Service Composer on VMware official wrote by Romain Decker