Skip to main content

Documentation Index

Fetch the complete documentation index at: https://www.qovery.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

Preview: Remote Dev Environments Portal is in preview. Features may change as the product evolves.

Overview

The Security Center is an admin page that provides visibility into active connections, IP-based firewall controls, and an audit log of all connection activity across your organization’s workspaces. It has three tabs:
  • Overview - Summary of active sessions and recent firewall events
  • Firewall - IP allowlist and denylist rules for controlling access
  • Activity - Full log of connection sessions and firewall events

Accessing the Security Center

1

Open the Admin Panel

Log in to the RDE Portal as an admin and navigate to Admin > Security Center.
2

Select a Tab

Use the tab bar at the top to switch between Overview, Firewall, and Activity.

Overview Tab

The Overview tab provides a quick summary of the current security posture:
  • Active connection sessions - The number of currently open shell and preview connections across all workspaces.
  • Recent firewall events - A summary of recent firewall activity, including blocked connection attempts.
Use this tab as a starting point to assess whether anything needs attention before diving into the Firewall or Activity tabs.

Firewall Rules

The Firewall tab lets you define IP-based access rules that control who can connect to workspaces. Rules apply to both shell (terminal) connections and preview (HTTP) connections. Each firewall rule has the following fields:
FieldDescription
Actionallow or deny - whether the rule permits or blocks the connection
CIDR RangeAn IP address or CIDR block (e.g., 192.168.1.0/24 or 10.0.0.5)
DescriptionA human-readable label for the rule (e.g., “Office VPN” or “Block suspicious range”)
PriorityThe position in the rule list - rules are evaluated top to bottom

Creating a Rule

1

Open the Firewall Tab

Navigate to Admin > Security Center > Firewall.
2

Add a New Rule

Click Add Rule. Fill in the action (allow or deny), the CIDR range, and a description.
3

Save

Click Save. The rule takes effect immediately for all new connections.
Start with a deny rule for known bad IP ranges, then add allow rules for your office and VPN networks. This gives you a clear picture of what is explicitly permitted.

Rule Evaluation Order

Rules are evaluated in order from top to bottom. The first rule that matches the connecting IP address wins - no further rules are checked. This means rule ordering matters. Consider the following example:
PriorityActionCIDRDescription
1Allow10.0.0.0/8Internal network
2Deny10.0.5.0/24Restricted subnet
3Deny0.0.0.0/0Block everything else
In this configuration, a connection from 10.0.5.15 would be allowed because it matches rule 1 first. The deny rule at priority 2 never executes for that IP. To block the restricted subnet, move the deny rule above the broader allow rule.
First-match-wins means that a broad allow rule placed before a narrow deny rule will override the deny. Always place more specific rules above more general ones.

CIDR Notation

Rules accept standard CIDR notation:
FormatMeaning
192.168.1.100A single IP address (equivalent to 192.168.1.100/32)
192.168.1.0/24All IPs from 192.168.1.0 to 192.168.1.255 (256 addresses)
10.0.0.0/8All IPs from 10.0.0.0 to 10.255.255.255
0.0.0.0/0All IPv4 addresses

Default Behavior

When no firewall rules are configured, all connections are allowed. The firewall only activates when at least one rule is present.
If you add rules, make sure your intended users are covered by an allow rule - or that they are not matched by any deny rule. Any IP that does not match any rule is allowed by default, even when other rules exist.

Reordering Rules

Because evaluation order determines which rule matches first, you can reorder rules by dragging them in the Firewall tab. After reordering, click Save to apply the new priority order.
  1. Add a rule: Allow 203.0.113.0/24 (your office network)
  2. Add a rule: Deny 0.0.0.0/0 (everything else)
  3. Ensure the allow rule is above the deny rule
Result: Only connections from your office IP range are permitted. All other IPs are blocked.
  1. Add a rule: Deny 198.51.100.42 (the IP to block)
Result: Connections from 198.51.100.42 are blocked. All other IPs are allowed by the default policy.
  1. Add a rule: Allow 10.8.0.0/16 (VPN range)
  2. Add a rule: Allow 203.0.113.0/24 (office network)
  3. Add a rule: Deny 0.0.0.0/0 (block all other traffic)
Result: Only VPN and office connections are allowed.

Activity & Connection Audit

The Activity tab provides a full log of connection sessions and firewall events.

Connection Sessions

Every time a user opens a terminal or accesses a preview, the session is recorded:
FieldDescription
User EmailThe authenticated email of the user who initiated the session
IP AddressThe IP address the connection originated from
Connection Typeshell (terminal session) or preview (HTTP preview request)
TimestampWhen the connection was established
StatusWhether the connection is active or has ended

Firewall Events

When a connection is blocked by a firewall rule, the event is logged separately:
FieldDescription
IP AddressThe IP that was blocked
Matched RuleThe specific firewall rule that caused the block
TimestampWhen the blocked connection attempt occurred
Connection Typeshell or preview
Use the Activity tab to investigate suspicious access attempts, verify that firewall rules are working as expected, and maintain an audit trail of who accessed which workspaces and when.

How the Firewall Works

The firewall is enforced at two integration points: shell WebSocket connections and preview proxy HTTP requests.

Shell Connections

When a user opens a terminal in a workspace:
  1. The portal receives a shell connection request.
  2. Before establishing the WebSocket, the firewall evaluates the user’s IP address against the rule list.
  3. If a deny rule matches first, the connection is rejected and the terminal displays a firewall_blocked message.
  4. If an allow rule matches first, or no rules match (default allow), the connection proceeds normally.
  5. The connection attempt is logged in the Activity tab regardless of the outcome.

Preview Connections

When a user accesses the live preview panel:
  1. The portal receives an HTTP request for the preview proxy.
  2. The firewall evaluates the user’s IP address against the rule list.
  3. If a deny rule matches first, the request is rejected.
  4. If an allow rule matches first, or no rules match, the request is proxied to the workspace container.
  5. The connection attempt is logged in the Activity tab.
Both allowed and blocked connections are recorded. This means the Activity tab provides a complete audit trail of all access to your organization’s workspaces, not just blocked attempts.

Next Steps

Security & Data Residency

Learn about the portal’s security architecture and data residency model.

Workspace Management

Monitor and manage all workspaces across your organization.

Access Control

Configure blueprint-level access rules by email or domain.