Updated August, 2020
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.
Adding Existing Security Groups to a Blueprint
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
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
With the August 2020 release of vRealize Automation Cloud, you now have the ability to change security group membership for a deployment as a day-2 action. 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.
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!