Updated April, 2021
Welcome back for part three of a four part series on Network Automation with Cloud Assembly and NSX. In the previous two posts, I covered how to setup Cloud Accounts, verify and configure your initial network profile, then showed how to create on-demand networks and use existing or provider networks. For this post, I will cover using security groups plus private and routed network types that can be configured in Cloud Assembly. If you happened upon part 3 without looking at the first 2 posts, I recommend reading though part 1 and part 2 before going through this post.
NSX Security Groups
NSX Security groups are one method which are used to isolate VMs constrained to private network type deployments. Security groups and associated firewall rules are a core way we can implement and manage security with NSX. Cloud Assembly can assign VMs to existing NSX security groups through network profiles and blueprints. The screenshot shows an existing Security Group is added to the profile named Global through a network profile. I could also assign membership to multiple Security Groups using this network profile, simply keep adding the required security groups to achieve that result. One thing to note, all VMs provisioned using this network profile will be members of the same security group(s). Blueprints offer a different way to assign membership with more granularity, which I’ll cover shortly.
Security groups are visible within Infrastructure -> Resources -> Security. This view, shown in the screenshot, allows you to see all the of the discovered (existing) security groups. To assign VMs to an existing security group using a blueprint, you must add a constraint tag to the security group and then add the same tag to the cloud zone where the VM will be deployed. To add a constraint tag to the security group, click the checkbox for the chosen security group in the Security view then click TAGS to add a constraint tag for later use with a blueprint.
I’ve mentioned that security groups can be leveraged through a blueprint. Two types of security group objects can specified in a blueprint, existing and new. Like existing networks, existing security groups are groups that have already been created in NSX using Cloud Assembly, manually in the NSX manager, or 3rd party methods. New aka on-demand security groups are available for vRealize Automation (vRA) Cloud (our vRA SaaS offering) and on-premises for vRealize Automation 8.1. I’ll cover on-demand security groups later in the post.
Updated April, 2021
Adding Existing Security Groups to a Blueprint
This process now supports both NSX and VMC. Since VMC uses NSX on the backend, the process for adding existing security groups to a Cloud Template is the same.
To add an existing security group via the blueprint, click-drag the object to the canvas. You’ll notice the YAML code updates with information on each security group that’s added. Once the machines deploy, they will become members of the specified existing security groups.
To associate a security group with a cloud machine, click the security group object on the canvas and drag the cursor to the cloud machine (similar to the process used to connect machine and network objects). A dialog will appear asking which NIC to assign to the security group. Don’t forget to add the security group constraint tag to the YAML portion of the blueprint as well. As soon as the machines deploy, they’ll become members of the specified existing security groups.
When a security group, whether existing or new, is connected to a cloud machine, a resource binding appears in the YAML code for the connected cloud machine. You can assign independent security groups to each NIC, if so desired.
Assigning security groups from the blueprint offers more flexibility versus assignment via the network profile. Both methods can still be used. You may want to assign a common security group, which sets a minimum security baseline, at the network profile and more secure or specific security groups using the blueprint.
Adding On-demand Security Groups to a Blueprint
This process now supports both NSX and VMC. Since VMC uses NSX on the backend, the process for adding on-demand security groups to a Cloud Template is the same.
Cloud Assembly provides the option to choose “new” for securityGroupType in the YAML code. You also have the option to create firewall rules and take advantage of existing services in NSX. The screenshot shows how to define firewall rules in YAML: source; destination; direction, inbound or outbound; ports; protocol; existing service.
In this scenario, a security group with associated firewall rules is created during the deployment assigned to the NICs of deployed VMs. The security group and rules are removed when the deployment is deleted. The process for connecting the security group and cloud machine are the same as existing groups; here though you won’t use a constraint tag in the YAML code because in this example we’re creating new security groups.
The screenshot shows new security groups being created in NSX. The VMs, Web and DB, will be members of the newly created groups with the distributed firewall rules set in the YAML code. You can also set the source as other VMs in the deployment or a range IP addresses.
Change Security Group Membership – Day-2 Action
vRA now supports the ability to change security group membership for a VM deployment as a day-2 action in both NSX and VMC. To change a group, choose the group from the Deployment – Topology view. Click Actions on the right and select Change Security Groups.
The existing security group assignment will be displayed. You can remove the group and choose from one of the other groups in the deployment. Once complete, click Apply to update the deployment.
Change a Security Group Iteratively Via the Cloud Template and as a day-2 action
vRA Cloud and vRA 8.4 now support the ability to update a VM’s Security Group membership as a deployment update following a Cloud Template change. This method provides more flexibility around Security Group assignment than the day-2 action, which only supports Security Groups associated with the deployment. Simply change the Existing Security Group assigned to a VM within the Cloud Template and initiate a deployment update. Choose the dropdown to update an existing deployment, select the deployment from the list you would like to update, click Next, confirm the Planned changes and click Deploy. The deployment will be updated with the new Security Group membership. This capability is supported with both NSX and VMC.
We also support the reconfiguration of firewalls rules for on-demand Security Groups as a day-2 action. Navigate to the deployment topology, select the Security Group, then click Actions and choose Reconfigure or Delete. You can add new rules, edit existing rules, or delete the rules from this day-2 action. When you click Submit, an update actions run to modify or add DFW rules that are associated with the Group in NSX.
Private Network Types
networkType: private Private network types isolate provisioned VMs from external access via firewall rules or network configuration. Private allows you to use existing (shown below) or on-demand networks for deployments. The network profile the provisioning service chooses controls each configuration. If you choose private on the blueprint and use a constraint tag for a network profile/policy where Create an on-demand security group is matched (shown below), a security group is created for each network on the blueprint canvas. All on-demand security groups are created with three associated firewall rules. The associated rules include inbound and outbound reject rules and a third rule allows intra-VM communication for members of that security group.
If you choose to create an on-demand private network, networkType private is still used on the blueprint, but you would constrain the network choice to a network profile with on-demand networking configured. In that event, a DHCP server and pool is created, however a T-1 isn’t configured, and no security groups are created. I’ll talk more about this later in the post. Let’s take a look at how to set this up.
Open a network profile, select Networks, and choose one of the two options:
- For a private on-demand security group deployment, add an existing deployed or discovered switch in Networks, choose Create an on-demand security group in Network Policies, and specify networktype: private on the blueprint.
- For a private on-demand network deployment, the configuration process uses the on-demand network profile config (check out part 2 on outbound network types for more information). The main difference with this configuration is you don’t need to add an existing switch in Networks and an external network isn’t required in Network Policies.
Routed Network Types
networkType: routed Is available for NSX and requires an NSX network object on the blueprint canvas. You can’t use the routed network type with a cloud agnostic network object, the option won’t appear in the YAML properties. Routed networks are similar to Outbound (on-demand networks), except they configure the route advertisement to Advertise all connected routes for the created Logical Router (Outbound uses Advertise all NAT routes) and a NAT rule isn’t created. In environments where internal NAT is frowned upon, the routed network type is ideal. Simply point a blueprint, with network type Routed, to a network profile with a on-demand network policy (just like the Outbound type) and Cloud Assembly will handle the configuration at deployment time.
This covers how security groups, plus private and routed network types are configured and the resulting behavior in NSX. For part 4 of the series, I’ll be covering how to use and deploy NSX load balancers with Cloud Assembly. I hope you’ve enjoyed our trip down network automation lane!
Network Automation with Cloud Assembly and NSX part 1 – Network Automation with Cloud Assembly and NSX part 2 – Network Automation with Cloud Assembly and NSX part 4
