Multi-Tenancy Part 4

1. Introduction
2. Steps Overview
3. Step 1: – Default Policy & Rule in a Project
4. Step 2: – User created Policy & Rule in a Project
5. Step 3: – Multi-Tenancy Distributed firewall as a Service-DFWAAS
6. Example 1, ProjA-DEV VM can ICMP to ProjA-Prod VM, but not vice versa.
7. Example 2, ProjA-Prod VM can RDP to ProjA-DEV VM, but not the other way around.
8. Step 4: – Multi-Tenancy Intra-tier & Inter-tier Micro-segmentation as a service-MAAS
9. Conclusion

Introduction

Security in multi-tenancy is of utmost importance, especially when sensitive information is involved. Fortunately, there are advanced features and tools available in Projects that can be utilized to establish more robust security measures to safeguard tenant data. One great example is the implementation of role-based access controls, which can limit access to confidential data, and quotas can also be set up to prevent tenants from overusing resources. These measures can go a long way in ensuring the security of all tenant data.

Steps Overview

• Step 1:- Default Policy & Rule in a Project
• Step 2: – User created Policy & Rule in a Project.
• Step 3: – Multi-Tenancy DFW As a Service
• Step 4: – Multi-Tenancy Intra-tier & Inter-tier Micro-segmentation as a service-MAAS

Step 1: – Default Policy & Rule in a Project

Whenever a new project is added to NSX, the system automatically generates a default DFW policy for that project. This policy is created in the Application firewall category and can be found at the bottom of the policy list. It serves as a template for the behavior of VMs within the project in the absence of any other rules. To identify this policy, the naming convention used is ORG-default PROJECT-<Project_Name> Default Layer 3 section.

Please note that the actual Project_Name value will be unique to your system.

Capture 1: –

Note:- Project-A is the project name.

Step 1: – Default rules are under the Application tab.

Step 2: – The Default policy is applied to DFW and it contains the following rules.

Step 3: – Rule id 4073 allows IPV6-ICMP traffic.

Step 4: – Rule id 4074 allows communication to the DHCPv4 Client & Server.

Step 5: – Rule id 4075 allows communication between workload VM’s within the project.

Step 6: – Rule id 4076 drops all other communication that does not match any of the above rule.

Capture 2: –

I have located some information that could be of assistance to you. It should be noted that the default DFW policy limits VM communication exclusively to other VMs within the same project, including the DHCP server. This implies that communication with VMs outside of the project is not permitted. Furthermore, VMs that are linked to segments inside the project are unable to ping their default gateway by default. To allow such communication, you will need to either create new rules or modify the existing rules in the default DFW policy.

Step 2: – User created Policy & Rule in a Project

The Infrastructure, Environment, and Application DFW firewall categories are fully supported for projects within the organization. These categories enforce DFW rules in a specific order of precedence, with the highest priority given to DFW rules in the default space, followed by DFW rules in the project. It’s worth noting that the DFW rules in the default space apply to all VMs in the NSX deployment, including those in the projects. However, if you wish to restrict the scope of these rules, the UI offers a Groups option within the Applied To setting that you can select.

When working with DFW rules in a project, it’s essential to understand the available groups. These groups can either be created within the project or shared with it. It’s worth noting that the firewall rules in place for a project only affect the VMs that are connected to its segments. So, even if Any-Any rules have been applied to DFW, they won’t impact workloads outside of the project. Rest assured that you can confidently configure DFW rules within your project with this knowledge.

Let’s go with an example to discuss.

Capture 1: –

Step 1: – login as an project administrator “TOM”.

Step 2: – Click on “Project-A” under project switcher.

Step 3: – Click on Security.

Step 4: – Click on Distributed Firewall under Policy management.

Step 5:- Application category.

Step 6: – Click on “Add Policy”

Step 7: – Gives the name of the policy. As per capture 1 i have given “Project-A-maliciousip”

Step 8: – Create the rule. As per the capture 1 rule name “Malicoius IP rule”. Source-”D-malicious Group”(user created shared group), Destination default DFW Project-A group ”ORG-default-PROJECT-Project-A” & applied to DFW.

Note:- if we select “DFW” in the applied to field it will impact of all the workloads as per our example this rule should apply on both the VM’s (WIN-11-A)& (WIN-11-B).

Step 9: – click on ”ORG-default-PROJECT-Project-A”.

Step 10: – IP address associated to Project-A default group VM’s.

Step 11: – NSX Segments associated to Project-A VM’s (WIN-11-A associated with ProjA-DEV) & (WIN-11-B associated with ProjA-Prod)

Step 12: – We can see the policy is unpublished.

Step 13: – Click on published.

Capture 2:-

Step 1:- Rule id is 7146. generated and policy enforced on the destination group ORG-default-PROJECT-Project-A.

Step 3: – Multi-Tenancy Distributed firewall as a Service-DFWAAS

As a project or security administrator, you have complete control over the distributed firewall policies for the workloads you oversee. To ensure that only authorized personnel can access these policies, we’ve implemented role-based access control (RBAC) with scope project. The enterprise administrator can create a T0 in the default space and segments in corresponding projects. However, it’s important to note that networking is centrally managed by the provider and not at the project level. If you need to filter DFW logs based on label, this feature is readily available. Additionally, shared-services VM groups can be utilized in project policies after sharing. However, it’s important to keep in mind that this feature doesn’t work on VLAN backed networks or overlays shared by multiple tenants.

To illustrate how this all works together, let’s discuss an example of micro-segmentation.

Capture 1: –

As per Capture 1, we will test two examples.

In Example 1, ProjA-DEV VM can ICMP to ProjA-Prod VM, but not vice versa..

In Example 2, ProjA-Prod VM can RDP to ProjA-DEV VM, but not the other way around.

Example 1, ProjA-DEV VM can ICMP to ProjA-Prod VM, but not vice versa.

Pre-Validation Check: –

1. Shall we double-check to make sure that the virtual machines are connected to the correct segments as shown in capture 1?

Capture 2: –

Step 1: – login as an project administrator “TOM”.

Step 2: – Click on “Project-A” under project switcher.

Step 3: – Click on Networking.

Step 4: – Click on Segments under Connectivity.

Step 5: – We can see the segment ProjA-DEV(192.168.80.1/24) is connected to T1-MT-PROJA(Tier-1 GW)with default transport zone.

Step6: – We can see the WIN11-A associated with the Segment-ProjA-DEV.

Step 7: – We can see the segment ProjA-PROD(192.168.90.1/24) is connected to T1-MT-PROJA(Tier-1 GW)with default transport zone.

Step6: – We can see the WIN11-B associated with the Segment-ProjA-PROD.

2. Now we will test both segment VM’s can ICMP to each other.

Capture3: –

Step 1: – WIN11-B (192.,168.90.2) successfully reached to WIN 11-A(192.168.80.2).

Step 2: – WIN 11-A(192.168.80.2) successfully reached to WIN11-B (192.,168.90.2).

because as per the default rule id 4075 allows communication between workload VM’s within the project. Please refer the capture 1 under Default Policy & Rule in a Project

3. Tags & Groups validation: –

Capture 4: –

Step 1: – login as an project administrator “TOM”.

Step 2: – Click on “Project-A” under project switcher.

Step 3: – Click on Inventory.

Step 4: – Click on Tags under Inventory Overview.

Step 5: – ProdA-DEV tag already created & associated with VM(WIN11-A) & Group (ProjA-DEV).

Step 6: – ProdA-PROD tag already created & associated with VM(WIN11-B) & Group (ProjA-PROD).

Step 7: – Under groups we can see 3 groups are already created.

ProjA-Combine—Both VM’s added(WIN11-A & WIN11-B).

ProjA-DEV—- WIN11-A

ProjA-PROD—-WIN11-B.

Excellent news, all pre validation checks have been successfully completed and we are ready to move forward. Our next step is to deploy the necessary policy and rules to ensure full compliance with example 1. Let’s take action and get this done!

Capture 5: –

Step 1: – login as an project administrator “TOM”.

Step 2: – Click on “Project-A” under project switcher.

Step 3: – Click on Security.

Step 4: – Click on Distributed Firewall under Security Overview.

Step 5: – Click on ADD Policy.

Capture 6: –

Step 1: – Policy Name—> ICMP-Allow DEV-to-PROD.

Step 2: – Applied to filed I added the group “ProjA-Combine”.

Capture 7: –

Step 1:- Adding the rule. Rule name—> ICMP-Allow

Step 2:- Source—> ProjA-DEV

Step 3: – Destination —> ProjA-PROD

Step 4: – Services—> ICMP all

Step 5: – Applied to —> ProjA-DEV

Step 6: – Action—> Allow

Step 7: – Click on Publish

Capture 8: –

Step 1:- Rule is successfully applied.

Now, as per rule 7150 ProjA-DEV is able to ICMP ProjA-PROD but not vice versa. Let’s verify.

Capture 9:-

Step 1: – WIN11-B (192.,168.90.2) successfully reached to WIN 11-A(192.168.80.2).

Step 2: – WIN 11-A(192.168.80.2) successfully reached to WIN11-B (192.,168.90.2).

But as per the policy 7150 step 1 shouldn’t be happen. Still they are pinging each other.

Now let’s verify the rule 7150 is enforced on VNIC level of WIN11-A and WIN11-B or not.

Capture 10: –

Step 1:- Win11-A resides on esx-03b. To know the vNIC Slot 2 name i execute the command

“summarize-dvfilter | grep -A10 Win11-A”

Step 2:- Copy the name of the vNIC slot 2.

Step 3: – Win11-B resides on esx-02a. To know the vNIC Slot 2 name i execute the command

“summarize-dvfilter | grep -A10 Win11-B”

Step 4:- Copy the name of the vNIC slot 2.

Capture 11: –

Step 1:- run the command to know the rule enforced on the vnic slot 2 on WIN11-A

vsipioctl getrules -f “vnic slot2 name”.

Step 2:- We can see the rule 7150 is already applied.

Capture 12: –

Step 1:- run the command to know the rule enforced on the vnic slot 2 on WIN11-A

 “vsipioctl getrules -f “vnic slot2 name”.

Step 2:- We can see the rule 7150 is successfully applied.

Hello there! It appears that there is still a ping occurring from Win11-B to WIN11-A, despite all the rules being correctly applied. I believe I may have pinpointed the issue. As you may recall, in step 2, I mentioned the User created Policy & Rule in a Project. It turns out that the DFW rules are applied in a specific order of precedence, with the highest priority given to DFW rules in the default space, followed by DFW rules in the project. This could be the reason why the ping is still happening.

Capture13: –

Step 1: – Rule id 4075 has the default groups added of project-A.

Step 2: – Action —> Allow.

Let’s we change the action from allow to drop and see the behaviors of the policy 7150.

Capture 14: –

Step 1: – Change the rule id 4075 action from Allow to drop.

Step 2: – Click on Publish.

let’ we verify the ping connectivity again does it comply as per our example 1

Capture 15:-

Great News, Policy is implemented successfully.

Step 1: – We can see the WIN11-A

Step 2:- Aper the rule 7150 ProjA-DEV(WIn11-A) is able to ping the ProjA-PROD (Win11-B).

Step 3: – We can see the WIN11-B

Step 4:- Aper the rule 7150 ProjA-PROD (Win11-B)is not able to ping the ProjA-DEV(WIn11-A).

Example 2, ProjA-Prod VM can RDP to ProjA-DEV VM, but not the other way around.

Pre-validation Check

1. Shall we double-check to make sure that the virtual machines are able to RDP or not as per the capture 1?

Capture 1.1:-

Step 1:- WIn11-A is unable to RDP WIN11-B(192.168.90.2).

Step 2:- Win11-B is unable to RDP WIN11-A(192.168.80.2).

Let we configure the Policy under the DFW to comply with the Example 2.

Capture 1.2: –

Step 1: – login as an project administrator “TOM”.

Step 2: – Click on “Project-A” under project switcher.

Step 3: – Click on Security.

Step 4: – Click on Distributed Firewall under Security Overview.

Step 5: – Click on ADD Policy.

Step 6: – Policy Name—> RDP-Allow PROD -to -DEV

Step 7: – Applied to—> ProjA-Combine.

Step 8:- Rule Name —> RDP block from DEV -to-PROD.

Step 9: – Source —> ProjA-PROD.

Step 10: – Destination ProjA-DEV.

Step 11:- Services—> RDP

Step 12: – Applied to ProjA-PROD

Step 13:- Action—> Allowed.

Step 14: – Click on Publish.

Now, let we verify the policy Status.

Capture 1.3: –

Step 1:- Policy is successfully publish and rule id 7151.

Step 2: – Action —> Allowed.

Capture 1.4: –

Now, let’s comply the rule ID 7151. Does it work as per Example 2?

Step 1:- Win11-A unable to RDP to WIN-11B.

Step 2:- WIN11-B is successfully took the RDP prompt of WIN11-A.

Step 4: – Multi-Tenancy Intra-tier & Inter-tier Micro-segmentation as a service-MAAS

To restrict project users to security configurations exclusively, it is possible to employ Role-Based Access Control (RBAC) with a project scope. Within corresponding projects, the Enterprise administrator can establish T0 in the default space and T1s and segments. Project Admins have the ability to self-manage Gateway firewall policies for their workload. However, networking is not managed at the project level and is instead centrally managed by the provider. Moreover, Project T1 GFW has the capability to safeguard VLANs.

To illustrate how this all works together, let’s discuss an example of MAAS.

Capture 1: –

As per the capture 1 we will test the below scenario➖

I have been apprised by the enterprise administrator regarding the infrastructure upgrade for the company. It has come to my attention that Proj-A DEV and Proj-B DEV segments are both attempting to establish a connection with the ORG-APP-Segment. Regrettably, it appears that the ProjA-Prod network can communicate with the ProjA-dev network, but is unable to communicate with the ProjB-DEV & ORG-APP-Segment. This is predominantly due to the multi-tenancy architecture that is presently in place, making communication between inter-projects and the default organization to projects rather intricate.

Summary of the capture 1: –

1. Win-D VM (172.16.94.2) is connected with the segment ORG-APP-Segment.
2. Org-APP-Segment connects to the default org-tier-0(MT-T0).
3. TOM(user)is the project-A admin.Win11-A(192.168.80.2)connects with segment-ProjA-DEV.
4. Segment ProjA-DEV connects with the dedicated project-A Tier-1(T1-MT-ProjA).
5. Win11-B(192.168.90.2)connects with segment-ProjA-Prod.
6. Segment ProjA-PROD connects with the dedicated project-A Tier-1(T1-MT-ProjA).
7. Win11-C(192.168.81.2)connects with segment-ProjB-DEV.
8. Segment ProjB-DEV connects with the dedicated project-B Tier-1(T1-MT-ProjB)

1. Pre-Validation Check: –
2. Shall we double-check to make sure that the virtual machines are connected to the correct segments as shown in capture 1?

Capture 2: –

Step 1: – login as an project administrator “TOM”.

Step 2: – Click on “Project-A” under project switcher.

Step 3: – Click on Networking.

Step 4: – Click on Segments under Connectivity.

Step 5: – We can see the segment ProjA-DEV(192.168.80.1/24) is connected to T1-MT-PROJA(Tier-1 GW)with default transport zone.

Step 6: – We can see the WIN11-A associated with the Segment-ProjA-DEV.

Step 7: – We can see the segment ProjA-PROD(192.168.90.1/24) is connected to T1-MT-PROJA(Tier-1 GW)with default transport zone.

Step6: – We can see the WIN11-B associated with the Segment-ProjA-PROD.

Capture 2.1: –

Step 1: – login as an project administrator “Chris”.

Step 2: – Click on “Project-B” under project switcher.

Step 3: – Click on Networking.

Step 4: – Click on Segments under Connectivity.

Step 5: – We can see the segment ProjB-DEV(192.168.81.1/24) is connected to T1-MT-PROJB(Tier-1 GW)with default transport zone.

Step 6: – We can see the WIN11-C associated with the Segment-ProjB-DEV.

Capture 2.2: –

Step 1: – login as an Enterprise administrator “admin”.

Step 2: – Click on “default” under project switcher.

Step 3: – Click on Networking.

Step 4: – Click on Segments under Connectivity.

Step 5: – We can see the segment ORG-APP-Segment(172.16.94.1/24) is connected to MT-T0(Tier-0 GW)with default transport zone.

Step 6: – We can see the WIN11-D associated with the Segment-ORG-APP-Segment.

3. Now we will test the connectivity from WIN11-A to WIN11-B, WIN11-C & WIN11-D can ICMP to each other.

Capture 3: –

Step 1: – We are trying to ping successfully from WIn11-A(ProjA-DEV) to WIN11-B(ProjA-PROD). As per the Multi-tenancy architecture, intra-project communication is allowed bidirectionally.

Step 2: – when attempting to ping Win11-A (ProjA-DEV) to Win11-C (ProjB-DEV), an RTO is expected as inter-project communication is prohibited bidirectionally.

Step 3: – when attempting to ping Win11-A (ProjA-DEV) to Win11-D (ORG-APP-SEGMENT)an RTO is expected as inter-project communication is prohibited bidirectionally.

Excellent news, all pre validation checks have been successfully completed and we are ready to move forward. Our next step is to deploy the necessary groups, policy and rules to ensure full compliance with capture 1. Let’s take action and get this done!

4. Groups Creations: –

Capture 4: –

Step 1: – login as an Enterprise administrator “admin”.

Step 2: – Click on “default” under project switcher.

Step 3: – Click on Inventory.

Step 4: – Click on Groups under Inventory Overview.

Step 5: – ORG-APP group is created

Step 6: – ORG-APP group associated VM is WIN11-D.

Step 7: – ProdA-DEV group is created

Step 8: – ProjA-DEV group associated VM is WIN11-A.

Step 9: – ProdB-DEV group is created.

Step 10: -ProjB-DEV group associated VM is WIN11CA.

Step 11: – Sensitive-Group group is created.

Step 12: – Sensitive-Group associated VM’s are WIN11-C,WIN11-D,WIN11-A.

5. Firewall Policy Creation: –

Capture 5: –

Step 1: – login as an Enterprise administrator “admin”.

Step 2: – Click on “default” under project switcher.

Step 3: – Click on Security.

Step 4: – Click on Distributed Security under Category Specific rules.

Step 5:- Click on “ADD Policy”.

Step 6: – Policy Name —Proj A&B—to-ORG-Segment.

Step 7:- Under Applied to field i select the group named “Sensitive-Group”. It has the 3 Vm’s (WIn11-A, Win11-C, Win11-D).

Capture 5.1: –

Step 1: – login as an Enterprise administrator “admin”.

Step 2: – Click on “default” under project switcher.

Step 3: – Click on Security.

Step 4: – Click on Distributed Security under Category Specific rules.

Step 5:- Click on “ADD Policy RADIO Button”.

Step 6: – Click on ADD Rule

Step 7: – Rule Name —ICMP Allow Proj A&B—to-ORG-Seg.

Step 8: – Source name — Add the groups (ORG-APP-Seg, ProdA-DEV,ProdB-DEV).

Step 9: – Destination Name — Add the groups (ORG-APP-Seg, ProdA-DEV,ProdB-DEV).

Step 10: – Services — ICMPv4-ALL.

Step 11:- Applied To—- DFW.

Note: – Be remember we already select the “Sensitive-Group ”in the applied To under policy so this rule will not published on all the VM’s.

Step 12: – Action —- Allow

Step 13: – Click on Publish.

Now let’s verify the behavior of this policy.

Let’s first check the connectivity as below

• [ ] WIN11-A (ProjA-DEV) to WIN11-B(ProdA-PROD) Intra-Tier Connectivity.
• [ ] WIN11-A (ProjA-DEV) to WIN11-C(ProdB-DEV) Inter-Tier Connectivity.
• [ ] WIN11-A (ProjA-DEV) to WIN11-D(ORG-DEV-SEG) Inter-Tier Connectivity.

Capture 5.2: –

Let’s we verify the connectivity from the GUI with the UI tool “traffic Analysis”

Capture 5.3:-

Step 1: – login as an Enterprise administrator “admin”.

Step 2: – Click on “All Projects” under project switcher.

Step 3: – Click on plan & Troubleshoot.

Step 4: – Click on “Traffic Analysis” under Troubleshooting Tools.

Step 5: – Under packet information select the below

IP Type : – IPV4

Traffic Type: – Unicast

Protocol Type: – ICMP

Step 6: – VM Name — WIN11-A

Step 7: – VM Name —- WIN11-D

Step 8: – Click on TRACE.

Capture 5.4: –

Great News we are able to comply as per the requirement.

Let’s now we will check the connectivity as below

• WIN11-D(ORG-DEV-SEG) to WIN11-A (ProjA-DEV) Inter-Tier Connectivity.
• WIN11-D(ORG-DEV-SEG) to WIN11-B(ProdA-PROD) Inter-Tier Connectivity.
• WIN11-D(ORG-DEV-SEG) to WIN11-C(ProdB-DEV) Inter-Tier Connectivity.

Capture 5.5: –

Step 1: – We can successfully reach an inter-tier communication from WIN11-D to WIN11-A. Step 2: – We can successfully reach an inter-tier communication from WIN11-D to WIN11-C. Step 3: – We are unable to reach an inter-tier communication from WIN11-D to WIN11-B. As per capture 1, we can achieve what we are trying to execute.

Let’s we verify the connectivity from the GUI with the UI tool “traffic Analysis”

Capture 5.6:-

Step 1: – login as an Enterprise administrator “admin”.

Step 2: – Click on “All Projects” under project switcher.

Step 3: – Click on plan & Troubleshoot.

Step 4: – Click on “Traffic Analysis” under Troubleshooting Tools.

Step 5: – Under packet information select the below

IP Type : – IPV4

Traffic Type: – Unicast

Protocol Type: – ICMP

Step 6: – VM Name — WIN11-D

Step 7: – VM Name —- WIN11-A

Step 8: – Click on TRACE.

Capture 5.7: –

Great News we are able to comply as per the requirement.

Lets we verify the connectivity as below: –

• WIN11-B(ProdA-PROD) to WIN11-A (ProjA-DEV) Intra-Tier Connectivity.
• WIN11-B(ProdA-PROD) to WIN11-C(ProdB-DEV) Inter-Tier Connectivity.
• WIN11-B(ProdA-PROD) to WIN11-D(ORG-DEV-SEG) Inter-Tier Connectivity.

Conclusion

Thank you for your attention. We have successfully completed the fourth installment 😎 of our Multitenancy blog series. I am confident that the comprehensive explanations of multitenancy from various perspectives and scenarios have provided valuable insights into this intricate subject matter. Although it required a certain amount of dedication and effort, I believe that the knowledge gained was definitely worth it. We invite you to stay tuned for our upcoming topic, which we are positive will be both enlightening and captivating.