CloudCenter 4.8 has reached End of Life (EOL) as of November 14, 2018. See End of Support Notices for additional context.

Application Security and Firewall Rules


The CloudCenter platform provisions application VMs in various cloud environments. These cloud environments provide communication security (both between nodes and external access) via Security Groups/Firewall rules. The CloudCenter platform dynamically creates these Security Groups/Firewall rules based on your application topology to allow inter-communication between nodes.

Deleting Security Groups - Caution

Numerous security groups may be listed under your CloudCenter account. The following table identifies when a security group is created and deleted.

If you delete a security group via the cloud provider console, be aware that you may no longer be able to access the application VMs.

Application deployment VMs will not be able to connect to VMs of another application deployment without explicitly allowing connectivity through firewall rules. The following table provides information about firewall rules.

Security/Firewall Type
Security Group Creation
NotesSecurity Group Name for Supported CloudSecurity Group Deletion

Tenant or User-Level Firewall Rules

At the time of user initialization.

Also created during app launch process.  

  • Created per user only if the Create default security groups for users in this Tenant option is enabled for the tenant
  • Also used for tenant-level isolation (on AWS, OpenStack, and Google) to allows unrestricted access across VMs created by the user, when Allow launched VMs to communicate with each other is enabled for the tenant. See Tenant Information > Default Security Group for additional details.
  • AWS, Alibaba, and OpenStack = cliqr-user-security-group_userId
  • Google = networkName-c3-user-userId-ruleId
The user-related security groups are automatically deleted when you delete this user from the CloudCenter platform.

Application Tier-Level Firewall Rules

Created during app launch process.

Created for each application tier for unique set of firewall rules and supported.

  • AWS, Alibaba, and OpenStack = cliqr-firewall-uniqueId
  • Dimension Data = cliqr-firewall-uniqueId (one per firewall port)
  • Google = networkName-c3f-uniqueId-ruleId
This security group is deleted when you terminate the application deployment.

Deployment-Level Firewall Rules

The application tier/deployment security profile feature which also creates security groupSee Security Profiles for additional details
  • AWS, Alibaba, and OpenStack use the same format: securityProfileName_uniqueId
You can only delete a Security Profile if it is not attached to any running job in any cloud.

Azure RM and Azure Stack

A security group is created for each AzureRM and Azure Stack VM with the name as CliQrSecurityGroup-VMName

Multiple Security Groups 

  • OpenStack: The CloudCenter platform accepts multiple security group configurations with the same name from OpenStack but uses the first security group from the list of security groups returned by OpenStack.

  • AWSThe CloudCenter platform ensures that an initial job submission is verified and reused if you submit multiple security group configurations with the same name.

Isolation Tags

If deploying an application using the multi-site/multi-account feature, be sure to address all firewall requirements when you Model the Application.

See Environments for additional context.

To isolate a deployment to a user on OpenStack or AWS clouds, CloudCenter provides the isolation tag feature. When you launch a VM, isolation tags allow you to restrict the VM communication to a particular deployment (only VMs within this deployment can communicate with each other).

Alternately, by using the cliqr-user-security-group_ self-reference job security group, all deployments launched by this user can communicate with each other. See Tenant Information > Default Security Group for additional details

Isolation tags are only supported by the Submit Job API for AWS and OpenStack deployments.

Inter-Tier Communication (Firewall Rules)

When modeling application profiles or applications for clouds powered by Cisco ACI, use the Restrict to one-way south-bound communication between connected tiers option (previously referred to as Enable Microsegmentation) to configure firewall rules between tiers.

  • Checked: Only a tier that is directly dependent on another tier can communicate with each other.

    Be aware that you can add your own firewall rules and customize the rules as required by your application. To implement this, go the applicable tier and add the tier name for the target port in the application. In addition to the tier name, your can specify "any" in the firewall rule for this application so you can expose that port to any endpoint in the ACI context (VRF). See ACI Extensions for addition details.

  • Unchecked (default): All tiers within the application can communicate with each other.

    If unchecked (disabled), nodes within the application can communicate with each other. However, other than the top application tier, firewall rules relating to a service-specific port are ignored and cannot be saved. This is regardless of the firewall rule being set to open a service-specific port for public internet access or a specific CIDR/subnet.

Service-Level Microsegmentation

The following behavior applies to the service-level microsegmentation feature:

  • If required, you must explicitly configure Ports 22 (SSH) and 3389 (RDP) as part of the application tier firewalls or the Vendor (tenant) Firewall list.

  • If you specify any tenant firewall rules, a shared security group (cliqr-job-worker*) with the rules is applied to all VMs deployed within the tenant.

  • Services now contain a set of internal firewall rules. These rules are applied as defaults to application tiers when you model applications. The default CIDR for application tiers default to The IP/CIDR/Tier automatically changes to the name of the dependent tier as soon as you make the connection in the Topology Modeler.

  • Nodes within the same tier can communicate with each other. 

  • Nodes in different deployments cannot communicate with each other. 

Define a Service with a Dynamic Firewall Rule

To define a dynamic firewall rule (metadata) at the service level, see Define a Custom Service.

Configuring Application Tier Firewall Rules

See Topology Modeler > Basic Information for additional context on the Enable microsegmentation check box to automatically set firewall rule for ACI environments. 

To configure firewall rules for an application tier, follow this procedure.

  1. Model an Application.

  2. When you model the topology configure the Firewall Rules for each tier  in the Topology Modeler. For example in the image below, the Apache Firewall Rules are being configured for the MySQL tier.

  3. Connect the Apache service to the MySQL service. As soon as you connect the service in the Topology Modeler, the IP column in the Firewall Rules section automatically updates to display the Apache application tier name.

  4. You can choose to keep the pre-configured firewall definition or add additional Firewall rules as required.

Terms & Conditions Privacy Statement Cookies Trademarks