NSX assists customers in configuring multi-layered security. An NSX firewall will provide primary security, and AWS security groups that are managed by NSX will provide a second layer of security. It is fully configurable to each VPC with exclusion lists. It enables agility for VM deploy/tear-down in test-dev while maintaining the structural integrity of production VPCs to get the best of both worlds.
There are environments where we would say VPCs need to be fully onboarded. It is okay to have some VMs that have an agent and some that won't have an agent in some environments. This is a typical test and dev environment, or a brownfield environment, that already has VMs running so we may not want to install an agent on all of them, but it doesn't mean that they can be quarantined.
If we have production VPC and it has a VM running in there with an agent installed and somehow someone manages to get in and install a rogue VM, then it is possible to detect it and quarantine it.
We have the gateway sitting in there and it is constantly polling for new resources that are being spun off inside a VPC/VNET. The gateway expects the agent in a VM to come and register itself, and if it doesn't, the gateway will move the VM to a quarantine security group. We can do this by using a default quarantine policy setup. Since the agent is not there, NSX Public Cloud Gateway (PCG) can't push any policies there, which doesn't mean that NSX doesn't have control over the VM itself. NSX can speak with the cloud provider and move this VM to a quarantine state. This is like adding another level of security and if we have an agent running, the PCG can push policies and manage the VM. If the agent is absent, PCG can move the entire VM to a quarantine state. Since PCG is the one doing this task, we don't have to worry about losing connectivity with on-premises systems. PCG has Identity and Access Management (IAM) roles assigned to it, which lets it talk to the cloud inventory. This is patented and we don't ask for admin privileges to do any of this. We can provide our customers with a cloud permission template, wherein they can assign roles and permissions to every component in NSX Cloud. PCG will be given the necessary roles to be able to talk to the cloud inventory manager and move a particular resource into a quarantine state.
We need an agent with a native security group to get an agentless solution. If AWS, Azure, and on-premises all worked the same way, then we could have done this easily. One single policy would have been good enough for all of these environments, which is not the actual scenario. We can apply one security group per VM in Azure and we can have five security groups that are nested in AWS. There is no way we can nest security groups in Azure as we will have to write a third security group for VNET in Azure. We are now talking about security group explosion, but we don't have any of these problems with NSX Cloud. We can't have a deny rule in AWS as we can only have an allow rule. If we say don't allow web-web tier communication for a particular instance, it doesn't take it. Anything that is not part of the allow rule is implicitly denied.
We have not seen any strong use case for doing encryption on the agent, but we do have the following defined role-based users for all tasks:
- VPC should be managed (cloud admin)
- Tagging the VM (developer)
- Adding the agent (developer)
However, if we need to provide additional isolation between different groups or divisions within companies or need tenant-specific branding, a number of tenants can be configured. Each tenant can have dedicated fabric groups, or shared fabric group resources if necessary. They have two or three subscriptions and a lot of VMs in these subscriptions, while other scenarios may have multiple subscriptions. The VMware IT job is to manage AWS and Azure accounts. Each employee here has their own AWS/Azure account, but the onus is on IT to make sure that we come from a secure interface by removing multiple security touch points. The problem with assigning security groups to VPCs and VNETs is that this has to be manually/statically done for every VPC/VNET. As an IT admin, we have two ways to go about this: by users creating VPCs for the workload or to impose security restrictions on them. But here, security is more like an afterthought. If we are looking for a consolidation of security groups for all VPCs and VNETs, then we need some level of abstraction. If we want a security group that can span across env, then we need a tool such as NSX. We can create NSX security policies using NSGroups in our NSX-T environment. NSGroups can be created with dynamic attributes such an VM name, location of the VM, which VNET it is running in, what region it is running in, and so on. It can also be based on user-defined custom tags, such as what the application is running in, and so on. NSX can learn about the tags, bring them back into NSX Manager, and based on these tags, can create some security groups and apply them to NSX Manager.
Azure has other limitations, such as we can have only one NSG per VM, but we wouldn't have any such problems with NSX Cloud. We can have any superset of NSGs with NSX. VM can be part of multiple SGs based on metadata and VM names. The policy can be based on attributes and not on a VM or interface VM, and there are no limitations on how many security groups can be stacked. Policies can be more dynamically defined instead of being statically defined to a particular VM, an in-bound or outbound access list, and so on.