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.
|Security Group Name||When is this security group created?||Notes||When is this security group deleted?|
At the time of user initialization.
This group is also created during theregistration and app launch process.
|The user-related security groups are automatically deleted when you delete this user from the CloudCenter platform.|
|cliqr-firewall-*|| At the time an application tier needs specific firewall settings (when the application was created).||None||This security group is deleted when you .|
To isolate a deployment to a user on OpenStack or AWS clouds, CloudCenter provides the isolation tag feature. Isolation tags allow you to link multiple deployments such that VMs from those deployments can communicate with each other.
Isolation tags are only supported by the Submit Job API for AWS and OpenStack deployments.
When you launch a VM, only the VMs from a particular 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.
When trying to isolate deployments, the security group is created, but it is not associated with any of the VMs in the deployment. Isolation tags enable you to create the security group and attach the group with all the VMs that need to communicate with each other.
In either of these cases, you may not require all deployments to communicate with each other and may only need selective environments to communicate. In these cases, you can use the isolation tag introduced in CloudCenter 4.5.0 to enable these selected VMs to communicate with each other. CloudCenter uses the order number for these deployments as the isolation tag through the Submit Job API.
The Enable Microsegmentation 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.
- No labels