CirrusGrid Container Firewall feature provides a possibility to control your nodes availability both from inside and outside of the Platform. It analyzes various parameters (e.g. incoming request source, protocol, target node port, etc.) to flexibly manage access to your containers through setting the necessary connection rules.
Tip: If you want to restrict access between the environments on a single account, it can be automatically configured via the Network Isolation feature.
Container Firewall Management via CirrusGrid UI #
Each node at CirrusGrid PaaS (excluding custom Docker– and Windows-based containers) is provisioned with a set of firewall rules, which can be reviewed and managed through an intuitive graphical user interface. The appropriate section can be accessed by clicking on the Settings button next to the required environment and selecting the Firewall menu item.
Note: The availability of the Container Firewall UI depends on your particular hosting provider settings. If you don’t have this section, please contact your platform support and request feature activation for your account.
Here, the following tabs are available:
- Overview – provides general information on the feature, allows to change Firewall State (which is enabled for all containers by default) and shows Isolated Env Groups the current environment is included to
- Inbound Rules – allows managing incoming requests (not listed ones are denied by default)
- Outbound Rules – allows controlling outgoing connections (not listed ones are allowed by default)
Default Firewall Rules #
When you create a new container, CirrusGrid automatically fills the Inbound and Outbound Rules sections with some records, required for the proper container operability.
Tip: These rules are automatically fetched based on the EXPOSE ports from the same-named variable in the image’s dockerfile, check the linked guide for more details on building Docker images for CirrusGrid PaaS.
Here, rules are grouped by layers and have the next structure:
- the very first record is gray-colored (i.e. non-editable/obligatory), has the highest priority (1) and allows CirrusGrid infrastructure to access container(s) from:
- platform orchestrator to manage all operations inside (password reset, configs generation, CS scripts execution, SSH key generation, etc.)
- SSH Gate and Web SSH to provide access to the appropriate services
- Shared Load Balancers to allow connection to the container without public IP
- the default (stack-related) and user-added (either by an environment owner or collaborators) rules
Note: Apply changes to the default rules only in case you know exactly what you are doing, since these records are required to ensure proper stack-specific functionality and to provide particular features support (e.g. to allow SSH, HTTP, HTTPS or FTP connections).
- another non-editable gray record (always the last one due to the lowest priority of 65535) blocks any incoming connection, which is not allowed via the above-mentioned rules
While working with the container (e.g. adding mount points, installing FTP add-on, etc), the list of default firewall rules can be automatically complemented by the platform according to the new requirements. Herewith, each default record is added with a 10-points priority step, allowing to insert custom rules in between.
Adding Container Default Rules #
If needed (e.g. for the automation solutions), you can use the JELASTIC_PORTS environment variable to define custom ports, which should be opened via container firewall during the appropriate nodes’ creation.
1. Click New Environment in the dashboard, select the required software stack, and navigate to the Variables configuration frame.
2. Provide a new JELASTIC_PORTS variable in the following format:
2. Provide a new JELASTIC_PORTS variable in the following format:
“JELASTIC_PORTS”: “{port1}, {port2}, … , {portN}“
Here, {portN} is a particular port (1234) or range (33062-34000), which will be exposed within the inbound firewall rules (via both tcp and udp protocols) after container creation.
Note: Changes due to the JELASTIC_PORTS variable are applied just once during nodes' installation. Consequently, the firewall rules should be managed manually.
3. You can check your firewall rules after creation.
Tip: Below, you can check an example on how to set this variable via Cloud Scripting:
jpsType: install
name: JELASTIC_PORTS env variable
nodes:
nodeType: apache2
nodeGroup: cp
env:
JELASTIC_PORTS: 3306, 33061, 33062
Rules Management #
For convenient management of the already existing firewall rules and providing the new ones, the tools panel above the list contains a set of buttons, namely: Add, Edit, Remove, Disable (Enable) and Refresh.
When adding a new firewall rule, the following parameters should be defined:
- Nodes – to select the required environment layer
- Name – to provide a name for this record (can be expanded to select from the commonly used presets)
- Protocol – to set the required protocol type (TCP, UDP or TCP/UDP)
- Port Range – to define a particular port (e.g. 80) or their range (e.g. 1024-2048) to be opened/closed for connection; leave this field blank to apply the rule to all ports
- Source – to select the request source:
- Custom IP Address(es) – a comma-separated list of IPv4/IPv6 addresses and CIDR blocks (e.g. 10.0.0.1,10.0.0.0/24)
- redefined ranges – All, All IPv4, All IPv6, Local Network, Internet (Public Access)
- Environment Nodes – node type (layer) from any environment on an account (subsequently, this rule is automatically complemented/diminished with the required IPs when the appropriate layer is scaled in/out)
- Priority – to set a rule priority (where rules with lower values are applied first)
- Action – to define the required action upon receiving the matching request (either allow or deny)
Subsequently, if meeting the necessity to Edit any default or custom rule, you’ll be able to adjust all of the above-described parameters except the Nodes field (i.e. target layer cannot be switched). Also, for the testing purposes, you can temporarily disable particular rules and reapply them later on with the appropriate Disable/Enable buttons. The Refresh button can come in handy to update the list of rules after some server adjustment (e.g. its topology change) without the necessity to restart the whole server.
Firewall Use Cases #
Access to your nodes can be controlled based on such request parameters as its source node’s IP address, connection protocol, port and so on. In the guide below, we’ll consider a simple example of blocking access to a container for a particular IP address, applied via User Interface.
Note: Before following this instruction, ensure that the appropriate container is provided with a Public IP address.
Restrict Access via User Interface #
So, as it was partly shown above, CirrusGrid provides a pretty easy-to-use and powerful GUI to manage container firewall directly via the dashboard.
1. To access the appropriate control panel, click the Settings button next to the required environment and switch to the Firewall section within the opened tab.
Select the Inbound Rules tab and click on the Add button (obviously, to manage external container traffic, you need to choose the Outbound Rules tab instead; herewith, all rule parameters are similar to the ones described below).
2. In the opened Add Inbound Rules form you can configure a new condition for the incoming requests’ processing by a container.
To deny a connection from a particular IP (according to our suggested use case example), fill in the fields as follows:
- Nodes – chose a container to restrict access to (tomcat in our case)
- Name – input any desired rule name (e.g. my-rule)
- Protocol – select a required protocol (TCP)
- Port Range – deny access to all ports by leaving this field blank
- Source – choose the Custom IP Address(es) option and type the necessary IP in the appeared IP Address Range field (111.111.111.111)
- Priority – set the appropriate priority for this record (e.g. 900 to be applied before the default rules)
- Action – select the Deny option
Click Add to save and automatically apply your rule.
3. Now, when trying to connect to your node from the specified 111.111.111.111 IP address, a user will be shown the following page:
This way you can deny access to your containers from any IP address.
