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.
|Security/Firewall Type||Security Group Creation||Notes||Security Group Name for Supported Cloud||Security Group Deletion|
Tenant or User-Level Firewall Rules
At the time of user initialization.
Also created during app launch process.
|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.
|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 group||See Security Profiles for additional details||You can only delete a Security Profile if it is not attached to any running job in any cloud.|
A security group is created for each Azure RM 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.
AWS: The CloudCenter platform ensures that an initial job submission is verified and reused if you submit multiple security group configurations with the same name.
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.
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
To configure firewall rules for an application tier, follow this procedure.
- Model an Application.
- 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.
- 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.
- You can choose to keep the pre-configured firewall definition or add additional Firewall rules as required.