NSX Service Composer: Methodology Concept

Background

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.

Picture1

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”.

Picture2

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
“L1-ST-APP-Web”.

Picture3

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

Picture4

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.

Picture6

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”:

Picture8

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:

Picture10

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:

Picture11

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:

Picture12

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:

Picture13

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”

Picture14

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

Picture15

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

Picture16

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:

Picture17

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

Picture23

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

Picture24

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

Picture25

To recap the complete Security Group list:

Picture26

The complete Security Policy list:

Picture27

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:

http://nsxperts.com/?p=65

Anthony Burke also Cover the Service Composer subject :

https://networkinferno.net/service-composer-security-groups-and-security-tags

And from  Service Composer on VMware official wrote by Romain Decker 

https://blogs.vmware.com/consulting/2015/01/automating-security-policy-enforcement-nsx-service-composer.html

Posted in Design, Firewall

Leave a Reply