Welcome to part-9 of the NSX Multi-tenancy series. The last post of this series discussed how resources are shared with a VPC from the default space and the project’s space.
In this post, I will discuss distributed security in NSX VPC.
If you are not following along, I encourage you to read the earlier parts of this series from the below links:
1: NSX Multi-tenancy Introduction
2: Multi-tenancy Design Models
4: Distributed Security in NSX Project
5: NSX Virtual Private Cloud Overview
8: Resource Sharing in NSX VPC
When the Project/VPC Admin creates a VPC, a default security group is also created with it. This group follows the naming convention “PROJECT-<project_name>-VPC-<vpc-name>-default”.
Members of this security group can be viewed by clicking the View Members button. This group contains subnets and VMs created inside the VPC.
All members of the VPC’s default group are automatically added as members of its parent project’s default group.
NSX also creates default north-south and east-west firewall rules to secure the workloads in the NSX VPC. The firewall rules can be viewed from the VPC view by expanding the VPC’s security section.
The firewall rules in an NSX VPC apply only to the VMs in the VPC and do not impact workloads outside the VPC.
By default, east-west traffic between workloads within an NSX VPC is allowed.
The N-S firewall rules are centralized rules that apply to traffic going in and out of the NSX VPC.
As per the default policy, the workload VMs have outbound access from all subnets in the VPCs to “ANY” destination. Inbound access to public subnets is not enabled, but you can implement additional policies to permit inbound connections to the VPC VMs.
VPC’s firewall rules (both E-W & N-S) can be viewed only by the project admin from the Project’s view.
Note: To view VPC E-W rules from the Project’s view, select the checkbox “VPC realized objects.”
To view the VPC’s N-S rules from the Project’s view, enable the toggle button “Show VPC realized objects” under the Gateway dropdown.
As stated earlier, the N-S rules can be only viewed from the Project’s view. To modify or add new policies/rules, you need to go to the VPC view.
VPC and Project’s Security Correlation.
As previously mentioned, members of the VPC’s default security group are automatically added to the parent project’s default security group. If any DFW policy/rule is written with the Project’s default group, the rule applies to all VPCs in the project. That brings us to an interesting conversation about outbound traffic from the VPC’s public subnets.
By default, the project’s default security policy doesn’t allow outbound external access (unless explicitly allowed by the project admin). Since VPC subnets are part of the project’s default group, any VM on the VPC public subnet shouldn’t be allowed to communicate with the external networks, right? But this is not the case.
Rule ID 2040 belongs to the VPC default policy and has more weightage than any other rules, it will allow outbound access to the VMs connected to the public subnet. If this were not the case, it would defeat the whole purpose of the public subnet in VPC.
Any custom rules written in the project context will be stacked on top of all VPC default and custom rules.
If a rule is applied to the same object in the Project and VPC contexts, the rule in the project context precedes the rule in the VPC context.
Let’s understand this with the help of the example below.
The VPC admin created a rule (rule-id: 2049) to allow core infra endpoint access from the VPC’s default security group. The Project admin has implemented a rule (rule-id: 2047) to block access to infra endpoints from the project’s default security group. The project’s custom rule appears before the VPC’s custom rule in the DFW table.
On analyzing the rules applied to one of the VM of the VPC, we can see rule 2047 is processed before rule 2049, and thus, traffic to the destination object will be blocked. This is because all members of the VPC’s default security group are also part of the Project’s default security group.
Similarly, rules written by the Enterprise Admin in the default space will have more precedence than any rule written at the project or VPC context by the Project/VPC admin.
In the example below, the Enterprise admin has implemented a rule (rule-id: 2050) for the Engineering project in the default space for blocking access to infrastructure endpoints.
On analyzing the rule on a VM from the VPC, we find rule 2050 is processed before any other rule.
This allows the Enterprise Admin to enforce optimal security by creating global rules that apply to all workloads or specific projects.
Logs from the distributed firewall and gateway firewall will be labeled with the Project information so that they can be identified and separated by the tenant.
And that’s it for this post.
I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing.