posted

0 Comments

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.  The screenshot shows an existing Security Group is added to the profile named Web.  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).

 

 

Security groups are visible within Infrastructure -> Resources -> Security.  This view allows you to see all the of the discovered security groups.  You can also choose a security group click TAGS and add a constraint tag for later use with a blueprint.

 

 

 

 

Security groups can be added to the canvas from the component list.  Two types of security group objects can specified in a blueprint, existing and new.  Existing security groups are cloud agnostic, meaning we can use existing NSX and Public Cloud security groups for deployments.  New aka on-demand security groups are only available for vRealize Automation (vRA) Cloud (our vRA SaaS offering) and NSX-T 2.4+ currently.  On-demand security groups are planned for the on premises vRA in a subsequent release.  I’ll cover on-demand security groups later in the post.

Adding Existing Security Groups to a Blueprint

 

To add an existing security group, click-drag the object to the canvas.  To associate the security group, hover over the security group object until a white circle appears.  Click-drag from the circle to the Cloud Machine you want to associate that security group with.  You’ll notice the YAML code updates with information on each security group, including dependency mapping to the Cloud Machine, and constraint tag.  Once the machines deploy, they will become members of the connected security groups.

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

 

The ability to create on-demand security groups has been available through the Private network type for some time.  What the previous capability lacked, was the ability to customize the firewall rules and membership associated with the security group.  With the new on-demand security group capabilities in vRA Cloud – Cloud Assembly, you now have the ability to create security groups and firewall rules that are specific to the needs of each deployment.

 

For example, when I drag a security group object to the canvas, I have the option to choose ‘new’ for securityGroupType.  I also have the option to create new rules and take advantage of existing services in NSX-T.  The screenshot shows the ability in the blueprint to define source, destination, direction – inbound or outbound, ports, protocol, existing service, and source.    A security group with associated firewall rules is created during the deployment assigned to the NICs of VMs created during the deployment.  The security group and rules are removed when the deployment is deleted.

 

In the example below, A new security groups will be created in NSX-T with the name Allow-https-mcm…  The VM Web will be a member of the group with DFW configured to allow https inbound from source any.  You could also set the source as another VM in the deployment or a range IP addresses/IPSet.   Remember you could also take advantage of an existing service in NSX-T rather than creating a new service.

Membership is assigned based on the resource binding, shown below as ‘${resource.Allow-https.id}’.  The resource binding can be assigned to one or more NICs configured during deployment with the VM.  You can assign independent security groups to each NIC if desired.

 

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:

  1. 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.
  2. For a private on-demand network deployment, from here 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 they don’t create a NAT rule.  In environments where internal NAT is frowned upon, the routed network type is ideal.  Simply point a blue print with network type Routed to an on-demand network profile/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 2Network Automation with Cloud Assembly and NSX part 4