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.
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:
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:
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).
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.
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:
“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
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:
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.
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.
Also, when preparing some container lifecycle automation solution, you may need to apply the required firewall changes via API – examine the list of the appropriate methods within the linked reference.
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:
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.
Powered by BetterDocs
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.