Container Firewall

The Container Firewall feature lets you control node availability from inside and outside the platform. It evaluates parameters such as incoming request source, protocol, and target node port to manage container access through 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 Platform UI

Each node on the platform (excluding custom Docker- and Windows-based containers) is provisioned with firewall rules that you can review and manage in the dashboard. Click Settings next to the required environment and select Firewall.

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, lets you change Firewall State (enabled for all containers by default), and shows Isolated Env Groups that include the current environment
• Inbound Rules - manages incoming requests (connections not listed in the rules are denied by default)
• Outbound Rules - manages outgoing connections (connections not listed in the rules are allowed by default)

Default Firewall Rules

When you create a new container, the platform automatically adds default records to the Inbound and Outbound Rules sections so the container can operate correctly. If default rules are missing, the platform adds them again during a firewall restart.

Tip: These rules are based on EXPOSE ports declared in the image Dockerfile. See the building custom containers guide for details.

Rules are grouped by layer and follow this structure:

• the very first record is gray-colored (i.e., non-editable/obligatory), has the highest priority (1) and allows platform 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 rules (added by the environment owner or collaborators)

• another non-editable gray record (always the last one due to the lowest priority of 65535) that blocks any incoming connection not allowed by the rules above

Note: Change default rules only if you know exactly what you are doing. These records are required for stack-specific functionality and feature support (for example, SSH, HTTP, HTTPS, or FTP connections).

While you work with a container (for example, adding mount points or installing the FTP add-on), the platform can add default firewall rules to match new requirements. Each default record uses a 10-point priority step, so you can insert custom rules between them.

Adding Container Default Rules

If needed (for example, for automation solutions), use the OPEN_INBOUND_PORTS (formerly Ruk-Com PaaS_PORTS) environment variable to open custom ports in the container firewall when the nodes are created.

1. Click New Environment in the dashboard, select the required software stack, and navigate to the Variables configuration frame.

2. Provide a new OPEN_INBOUND_PORTS variable in the following format:

text

"OPEN_INBOUND_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 OPEN_INBOUND_PORTS variable are applied just once during nodes’ installation. Consequently, the firewall rules should be managed manually.

3. After you create the environment, verify the firewall rules on the Inbound Rules tab.

Tip: Below, you can check an example on how to set this variable via Cloud Scripting:

yaml

jpsType: install
name: OPEN_INBOUND_PORTS env variable
nodes:
  nodeType: apache2
  nodeGroup: cp
  env:
    OPEN_INBOUND_PORTS: 3306, 33061, 33062

Rules Management

The toolbar above the rule list provides Add, Edit, Remove, Disable (Enable), and Refresh buttons for managing existing rules and adding new ones.

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 or IPv6 addresses and CIDR blocks (e.g., 10.0.0.1,10.0.0.0/24 or 2001:db8::1,2001:db8::/32); mixing IPv4 and IPv6 addresses within the same rule is not supported
  • predefined 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)

To Edit a default or custom rule, you can adjust all parameters described above except Nodes (the target layer cannot be changed). For testing, temporarily disable rules with Disable/Enable and re-enable them later. Click Refresh to update the rule list after server changes (for example, a topology change) without restarting the server.

Firewall Use Cases

You can control node access based on request parameters such as source IP address, protocol, and port. The example below blocks access to a container from a particular IP address using either:

• User Interface
• SSH connection

Note: Before following this instruction, ensure that the appropriate container is provided with a Public IP address.

When you automate container lifecycle tasks, you can apply firewall changes through the platform API. See the relevant methods in the linked reference.

Restrict Access via User Interface

1. Click Settings next to the required environment and open the Firewall section. Select the Inbound Rules tab and click Add. To manage outbound container traffic instead, switch to the Outbound Rules tab; rule parameters are the same as described below.

2. In the Add Inbound Rules form, configure how the container processes incoming requests.

To deny a connection from a particular IP, fill in the fields as follows:

• Nodes - choose the container to restrict (tomcat in this example)
• Name - enter a rule name (for example, my-rule)
• Protocol - select the required protocol (TCP)
• Port Range - leave this field blank to deny access to all ports
• Source - select Custom IP Address(es) and enter the IP in the IP Address Range field (111.111.111.111)
• Priority - set the rule priority (for example, 900 to apply before default rules)
• Action - select Deny

Click Add to save and automatically apply your rule.

3. When you connect to the node from 111.111.111.111, you see the following page:

You can use the same approach to deny access from any IP address.

Restrict Access via SSH

Alternatively, you can configure firewall rules for your container via terminal when accessing the node through SSH Gate.

Note: Although most of the firewall configurations can be performed via the dedicated user interface, management via SSH is more flexible (for example, allows configuring NAT redirects). However, such rules won’t be displayed in the UI list but will be of higher priority.

1. Open Web SSH from the dashboard by clicking the same-named button next to the required node. Once connected, check /etc/Ruk-Com PaaS/metainf.conf to confirm that the container firewall is enabled:

shell

cat /etc/jelastic/metainf.conf

The FIREWALL_ENABLED parameter should be set to “1”. If it is not, contact your hosting provider and ask them to enable firewall protection for your account.

2. Next, you need to modify the /etc/nftables/user-defined.nft file (e.g., with a vim editor) and declare firewall rules using the nftables scripting format.

shell

vim /etc/nftables/user-defined.nft

For example, to deny access from a particular IP (111.111.111.111):

shell

insert rule ip filter INPUT ip saddr 111.111.111.111 ct state new tcp dport 1111 counter drop

3. Apply your custom firewall settings to the container default rules:

shell

sudo /usr/bin/jem firewall fwstart

4. List the active firewall rules for your container:

shell

sudo jem firewall list \;

Your custom rule denying access from 111.111.111.111 appears in the output. Use the same approach to restrict access from any IP address.

Setting Rules via Platform API

For custom scripts, automation, and similar tasks, configure firewall rules through the environment > Security methods in the platform API documentation:

• AddRule - creates a new rule
• AddRules - adds several rules
• EditRule - changes parameters of an existing rule
• GetRules - shows a list of rules for the environment
• RemoveRule - deletes a rule
• RemoveRules - removes several rules
• SetFirewallEnabled - switches on the firewall
• SetRuleEnabled - enables an existing rule
• SetRules - replaces existing rules