As you create or edit your vRealize Automation cloud template, use the most appropriate security group resources for your objectives. Learn about the security group options that are available in the cloud template.

Cloud agnostic security group resource

There is currently only one type of security group resource. You add a security group resource by using the Cloud Agnostic > Security Group resource on the cloud template Design 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 directly to your cloud template design or you can use an existing security group that has been added to a network profile. Existing security groups are supported for various cloud account types.

For NSX-V and NSX-T, 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 only supported for NSX-T and NSX-V.

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 vRealize Automation from the source. You can select an existing security group from a list of available resources as part of a vRealize 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 NSX-V and NSX-T 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 NSX-V or NSX-T security group 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, and load balancer examples in vRealize Automation cloud templates.
When you create firewall rules in an NSX-V or NSX-T on-demand security group, the default is to allow the specified network traffic but to also allow 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, and load balancer examples in vRealize Automation cloud templates.
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, and load balancer examples in vRealize Automation cloud templates.

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 app isolation policy, the policy is assigned an auto-generated policy name. The policy is also made available for reuse in other cloud template designs and design iterations specific to the associated resource endpoint and project. The app isolation policy name is not visible in the cloud template design code 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, vRealize 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 is updated 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 reassociate between each redeployment. The needed workflow is as follows, assuming that you have initially deployed the cloud template:
  1. In the Cloud Assembly 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 vRealize Automation Cloud Assembly deployments.

Learn more

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

For information about using security group settings in a network profile, see Learn more about network profiles in vRealize Automation and Using security group settings in network profiles and cloud template designs in vRealize Automation Cloud Assembly.

For examples of cloud template designs that illustrate sample security resources and settings, see Network, security, and load balancer examples in vRealize Automation cloud templates.