Application Security and Firewall Rules

Overview

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.

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:
    • Prior to CloudCenter 4.8.1 =  networkName-cliqr-job-worker-userId
    • Effective CloudCenter 4.8.1 = 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:
    • Prior to CloudCenter 4.8.1 =  networkName-cliqr-firewall-uniqueId
    • Effective CloudCenter 4.8.1 = 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

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

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.

Enable Microsegmentation – Inter-Tier Communication (Firewall Rules)

Effective CloudCenter 4.8.1

The Enable Microsegmentation feature has been renamed.

  • New Name: Inter-Tier Communication (Firewall Rules) as a new sub-section title

  • Checkbox Name: Restrict to one-way south-bound communication between connected tiers.

The Enable Microsegmentation (effective CloudCenter 4.8.1, the Microsegmentation feature is called Restrict to one-way south-bound communication between connected tiers) option is only available for clouds powered by Cisco ACI.

  • Enabled: Only a tier that is directly dependent on another tier can communicate with each other.
  • Disabled (default): All tiers within the application can communicated with each other.

    If the microsegmentation feature is disabled (default), 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.


When modeling application profiles or applications, use the Enable Micro segmentation option (available via the Basic Information tab in the Topology Modeler) to configure firewall rules between tiers.

Service-Level Microsegmentation

The following behavior applies to the 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 0.0.0.0/0. 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 cloud integrations. 

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.