본문으로 건너뛰기
This page is not translated yet. 한국어 is switched on so the navigation and URLs can be tested; the text below is the English original. Use the language selector in the header to switch back, or see the documentation home.
how-to · Reviewed 2026-11-02 GA

Access restrictions

Access restrictions let you limit who can reach the Rescale platform, and from where, using CIDR-based IP allow lists. You can apply them at two levels: the organization level (who can sign in, use the API, or open the portal at all) and the user level (who can SSH or open a NiceDCV session into a running job or workstation). This page explains both scopes, how to enter CIDR rules, and how to find the right IP addresses.

Two scopes for access restrictions​

You configure access restrictions in two places:

  • Organization-level platform access. An organization administrator defines the CIDR ranges that are allowed to reach Rescale itself: the login page, the web portal, the API, and the CLI. Users from outside those ranges cannot authenticate to the platform at all.
  • User-level cluster access. Any authenticated user can restrict SSH and NiceDCV access to their own jobs, workstations, and storage devices from their user profile. User changes propagate immediately to every running instance the user owns.
The 0.0.0.0/0 rule is blocklisted

Per Rescale security policy, 0.0.0.0/0 and derivatives ("quad zero") are not allowed in any access restriction rule. If you need broad access, enumerate the specific ranges you trust.

Organization-level access restrictions​

Organization administrators define CIDR rules that control which source IPs can reach the Rescale platform UI, API, and CLI. Typically you enter a range that covers your corporate offices, VPN exit IPs, and any cloud environments (for example CI runners) that need to hit the Rescale API.

Users connecting from an IP that does not match any configured rule will not be able to sign in or use the API. Once a rule is in place, plan for the following:

  • VPN and corporate egress. If your workforce uses a VPN, include the VPN's public exit IPs.
  • Cloud and CI traffic. Any automation that calls the Rescale API, for example from AWS or Azure, needs to reach Rescale from a known allow-listed IP. Cloud providers publish their egress ranges, and those ranges are large and change over time, so prefer a NAT gateway or a fixed egress IP for the automation over allow-listing a provider's whole range.
  • Remote users. Roaming or home-office users need either a static IP (rare) or a corporate VPN so their traffic exits from an allow-listed IP.

User-level access restrictions for jobs and workstations​

Any authenticated user can restrict SSH and NiceDCV access to their own running clusters, without needing an administrator. Hover your email at the bottom of the left sidebar, open Preferences, go to Job Settings, and edit the Access Restriction CIDR field.

You have two options:

  • My Current IP. Restricts SSH and DCV access to the single IP address you are currently connected from. This is the most restrictive and most secure option.
  • Custom. A comma-separated list of CIDR ranges. Use this if you connect from more than one authorized location (for example office and home office).

If you leave the field undefined, you may not be able to complete an SSH connection. For a NiceDCV session, Rescale prompts you to choose a CIDR preference before the session opens.

Automating CIDR on job submission

If you want Rescale to add CIDR rules automatically when a job is submitted, contact your Rescale representative.

Finding your IP address​

Two ways to find the IP you are currently using:

  1. Click My Current IP in the Rescale UI. Rescale reports the IP address your browser is reaching the platform from.
  2. Browse to https://whatismyipaddress.com/.

Both methods give you your public IP, which is the one you need for CIDR rules. Your internal address on a corporate LAN (for example 10.x.x.x) is not usually the one Rescale sees.

Writing CIDR rules​

CIDR notation uses a slash followed by the number of network bits. The host portion is what is left over:

NotationSize (IPv4)Typical use
/321 addressA single host, the lowest IP in the subnet
/24256 addressesA small office network
/1665,536 addressesA large corporate network
/816,777,216 addressesA very large network
/0Entire IPv4 spaceBlocklisted on Rescale

Rules must use valid CIDR notation. Always enter the lowest IP in the subnet; for a single host that is the host's own IP followed by /32.

Example: multiple locations​

If you connect from three networks, find each one's public IP and combine them into a single comma-separated rule. A single host takes /32; for a whole network, give the lowest address in the range rather than the address of any one machine in it:

  • Home office, one host: 203.0.113.45/32
  • Office network, a whole range: 198.51.100.0/24
  • Rescale workstation, one host: 3.94.195.144/32

The resulting custom rule is:

203.0.113.45/32,198.51.100.0/24,3.94.195.144/32

Paste that string into the Custom field on your user profile.

Propagation and timing​

User-level changes to the CIDR list apply immediately to every running job, workstation, and storage device the user owns. You do not need to restart the instance for the new rule to take effect.

Organization-level changes affect new sessions. Signed-in users may need to reauthenticate before the platform enforces an updated rule against them.