As you create or edit your VMware Aria Automation cloud templates, use the most appropriate security resource options to meet your objectives.

Cloud agnostic security group resource

You add a security group resource by using the Cloud Agnostic > Security Group resource on the Template page. The resource displays in the cloud template code as a Cloud.SecurityGroup resource type. The default resource displays as: 
  Cloud_SecurityGroup_1:
    type: Cloud.SecurityGroup
    properties:
      constraints: []
      securityGroupType: existing

You specify a security group resource in a cloud template design as either existing (securityGroupType: existing) or on-demand (securityGroupType: new).

You can add an existing security group to your cloud template or you can use an existing security group that has been added to a network profile.

For NSX-V and NSX-T, as well as NSX-T with the policy manager switch enabled in combination with VMware Cloud on AWS, you can add an existing security group or define a new security group as you design or modify your cloud template. On-demand security groups are supported for NSX-T and NSX-V, and VMware Cloud on AWS when used with NSX-T policy manager.

For all cloud account types except Microsoft Azure, you can associate one or more security groups to a machine NIC. A Microsoft Azure virtual machine NIC (machineName) can only be associated to one security group.

By default, the security group property securityGroupType is set to existing. To create an on-demand security group, enter new for the securityGroupType property. To specify firewall rules for an on-demand security group, use the rules property in the Cloud.SecurityGroup section of the security group resource.

Existing security groups

Existing security groups are created in a source cloud account resource such as NSX-T or Amazon Web Services. They are data collected by VMware Aria Automation from the source. You can select an existing security group from a list of available resources as part of a VMware Aria Automation network profile. In a cloud template design, you can specify an existing security group either inherently by its membership in a specified network profile or specifically by name using the securityGroupType: existing setting in a security group resource. If you add a security group to a network profile, add at least one capability tag to the network profile. On-demand security group resources require a constraint tag when used in a cloud template design.

You can associate a security group resource in your cloud template design to one or more machine resources.

Note: If you intend to use a machine resource in your cloud template design to provision to a Microsoft Azure virtual machine NIC ( machineName), you should only associate the machine resource to a single security group.

On-demand security groups

You can define on-demand security groups as you define or modify a cloud template design by using the securityGroupType: new setting in the security group resource code.

You can use an on-demand security group for NSX-V and NSX-T, as well as Amazon Web Services when used with NSX-T Policy type, to apply a specific set of firewall rules to a networked machine resource or set of grouped resources. Each security group can contain multiple named firewall rules. You can use an on-demand security group to specify services or protocols and ports. Note that you can specify either a service or a protocol but not both. You can specify a port in addition to a protocol. You cannot specify a port if you specify a service. If the rule contains neither a service or a protocol, the default service value is Any.

You can also specify IP addresses and IP ranges in firewall rules​. Some firewall rule examples are shown in Network, security group, and load balancer resource examples in Automation Assembler.

When you create firewall rules in an NSX-V or NSX-T on-demand security group, the default allows the specified network traffic. The default also allows other network traffic. To control network traffic, you must specify an access type for each rule. The rule access types are:
  • Allow (default) - allows the network traffic that is specified in this firewall rule.
  • Deny - blocks the network traffic that is specified in this firewall rule. Actively tells the client that the connection is rejected.
  • Drop - rejects the network traffic that is specified in this firewall rule. Silently drops the packet as if the listener is not online.
For an example design that uses an access: Allow and an access: Deny firewall rule, see Network, security group, and load balancer resource examples in Automation Assembler.
Note: A cloud administrator can create a cloud template design that contains only an NSX on-demand security group and can deploy that design to create a reusable existing security group resource that members of the organization can add to network profiles and cloud template designs as an existing security group.

Firewall rules support either IPv4 or IPv6 format CIDR values for source and destination IP addresses. For an example design that uses IPv6 CIDR values in a firewall rule, see Network, security group, and load balancer resource examples in Automation Assembler.

Using constraints for security group placement

You can control where security groups are provisioned by using constraint tags, as shown in the following example: 
Cloud_SecurityGroup_4:
  type: Cloud.SecurityGroup
  properties:
    securityGroupType: new
    constraints:
        - tag: na
In this example, an on-demand security group is provisioned in endpoints (local NSX Manager cloud accounts) that have the na capability tag.
  • If multiple endpoints satisfy the constraint, the endpoint whose cloud zone has the highest provisioning priority is selected.
  • If no endpoint satisfies the constraint, the deployment fails.
  • If the security group is attached to another resource, the respective endpoint of that resource must satisfy the security group constraints in addition to any placement constraints on the resource itself.

On-demand and existing security groups for VMware Cloud on AWS

You can define an on-demand security group for a VMware Cloud on AWS machine in a cloud template by using the securityGroupType: new setting in the security group resource code.

A sample code snippet for an on-demand security group is shown below: 
resources:
  Cloud_SecurityGroup_1:
    type: Cloud.SecurityGroup
    properties:
      name: vmc-odsg
      securityGroupType: new
      rules: 
        - name: datapath
          direction: inbound
          protocol: TCP
          ports: 5011
          access: Allow
          source: any

You can also define an existing security group for a networked VMware Cloud on AWS machine and optionally include constraint tagging, as shown in the following examples: 

  Cloud_SecurityGroup_2:
    type: Cloud.SecurityGroup
    properties:
      constraints: [xyz]
      securityGroupType: existing
Cloud_SecurityGroup_3:
  type: Cloud.SecurityGroup
  properties:
    securityGroupType: existing
     constraints:
        - tag: xyz
Iterative cloud template development is supported.
  • If a security group is associated with one or more machines in the deployment, a delete action displays a message stating that the security group cannot be deleted.
  • If a security group is not associated with any machine in the deployment, a delete action displays a message stating that the security group will be deleted from this deployment and the action cannot be undone. An existing security group is deleted from the cloud template, while an on-demand security group is destroyed.

Using NSX-V security tags and NSX-T VM tags

You can see and use NSX-V security tags and NSX-T and NSX-T with policy VM tags from managed resources in VMware Aria Automation cloud templates.

NSX-V and NSX-T security tags are supported for use with vSphere. NSX-T security tags are also supported for use with VMware Cloud on AWS.

Note:

As with VMs deployed to vSphere, you can configure machine tags for a VM to be deployed on VMware Cloud on AWS. You can also update the machine tag after initial deployment. These machine tags allow VMware Aria Automation to dynamically assign a VM to an appropriate NSX-T security group during deployment.

You can specify NSX-V security tags by using the key: nsxSecurityTag and a tag value in the compute resource in the cloud template, as shown in the following example, provided that the machine is connected to an NSX-V network: 
tags:
  - key: nsxSecurityTag
  - value: security_tag_1
  - key: nsxSecurityTag
  - value: security_tag_2

The specified value must correspond to an NSX-V security tag. If there are no security tags in NSX-V that match the specified nsxSecurityTag key value, the deployment will fail.

Note:

NSX-V security tagging requires that the machine is connected to an NSX-V network. If the machine is connected to a vSphere network, the NSX-V security tagging is ignored. In either case, the vSphere machine is also tagged.

NSX-T does not have a separate security tag. Any tag specified on the compute resource in the cloud template results in the deployed VM being associated with all tags that are specified in NSX-T. For NSX-T, including NSX-T with policy, VM tags are also expressed as a key value pair in the cloud template. The key setting equates to the scope setting in NSX-T and the value setting equates to the Tag Name specified in NSX-T.

Note that if you used the VMware Aria Automation V2T migration assistant to migrate your cloud accounts from NSX-V to NSX-T, including NSX-T with Policy, the migration assistant creates a nsxSecurityTag key value pair. In this scenario, or if the nsxSecurityTag is for any reason explicitly specified in a cloud template for use with NSX-T, including NSX-T with policy, the deployment creates a VM tag with an empty scope setting with a tag name that matches the value specified. When you view such tags in NSX-T, the Scope column will be empty.

To avoid confusion, do not use a nsxSecurityTag key pairs when for NSX-T. If you specify an nsxSecurityTag key value pair for use with NSX-T, including NSX-T with policy, the deployment creates a VM tag with an empty scope setting with a tag name that matches the value specified. When you view such tags in NSX-T, the scope column will be empty.

Using app isolation policies in on-demand security group firewall rules

You can use an app isolation policy to only allow internal traffic between the resources that are provisioned by the cloud template. With app isolation, the machines provisioned by the cloud template can communicate with each other but cannot connect outside the firewall. You can create an app isolation policy in the network profile. You can also specify app isolation in a cloud template design by using an on-demand security group with a deny firewall rule or a private or outbound network.

An app isolation policy is created with a lower precedence. If you apply multiple policies, the policies with the higher weight will take precedence.

When you create an application isolation policy, an auto-generated policy name is generated. The policy is also made available for reuse in other cloud template designs and iterations that are specific to the associated resource endpoint and project. The app isolation policy name is not visible in the cloud template but it is visible as a custom property on the project page (Infrastructure > Administration > Projects) after the cloud template design is deployed.

For the same associated endpoint in a project, any deployment that requires an on-demand security group for app isolation can use the same app isolation policy. Once the policy is created, it is not deleted. When you specify an app isolation policy, VMware Aria Automation searches for the policy within the project and relative to the associated endpoint - If it finds the policy it reuses it, if it does not find the policy, it creates it. The app isolation policy name is only visible after its initial deployment in the project's custom properties listing.

Using security groups in iterative cloud template development

When changing security group constraints during iterative development, where the security group is not associated to a machine in the cloud template, the security group updates in the iteration as specified. However, when the security group is already associated to a machine, redeployment fails. You must detach existing security groups and/or securityGroupType resource properties from associated machines during iterative cloud template development and then re-associate between each redeployment. The needed workflow is as follows, assuming that you have initially deployed the cloud template.
  1. In the Automation Assembler template designer, detach the security group from all its associated machines in the cloud template.
  2. Redeploy the template by clicking Update an existing deployment.
  3. Remove the existing security group constraint tags and/or securityGroupType properties in the template.
  4. Add new security group constraint tags and/or securityGroupType properties in the template.
  5. Associate the new security group constraint tags and/or securityGroupType property instances to the machines in the template.
  6. Redeploy the template by clicking Update an existing deployment.

Available day 2 operations

For a list of common day 2 operations that are available for cloud template and deployment resources, see What actions can I run on Automation Assembler deployments or supported resources.

Learn more

For information about using a security group for network isolation, see Security resources in VMware Aria Automation.

For information about using security groups in network profiles, see Learn more about network profiles in VMware Aria Automation and Using security group settings in network profiles and cloud template designs in VMware Aria Automation.

For examples of using security groups in cloud templates, see Network, security group, and load balancer resource examples in Automation Assembler.