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||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.|
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.
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.
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.
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 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 environments.
To configure firewall rules for an application tier, follow this procedure.
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.