Network and Security
The Network & Security tab controls how the cluster is reachable: its public IP, an optional private VPC address, and the security groups that decide what traffic is allowed.
The tab has a sub-navigation: Network and Security Groups.
Public IP
Make your cluster reachable over the internet.
The IP shown here is the address you SSH to. It carries a badge:
| Badge | Meaning |
|---|---|
| Floating | Assigned from a shared pool. It can change if the cluster's network resources are recreated |
| Reserved | Held for your account. Stable for the cluster's life |
Convert a floating IP to reserved
Click Convert to reserved on the IP row.
A floating IP breaks every ~/.ssh/config entry, CI job, bookmark and runbook that hard-codes it —
and it changes without warning, so the failure arrives at an inconvenient moment. Converting costs
one click and removes the whole class of problem.
Attach a reserved IP
+ Add Reserved IP attaches an IP you have already reserved for your account. Use it when you want a specific, known address — for example one already allow-listed by a corporate firewall.
Anyone connected on the old address is unaffected until they reconnect, but new connections must use the new one. Tell your team, and update the Connection Details on the Details tab afterwards.
Detaching the last IP is refused: "At least one IP (reserved or floating) must be attached." To swap addresses, attach the new one first, then detach the old.
VPC IP
Select an existing VPC IP to attach to your cluster and enable private network connectivity.
A VPC IP puts the cluster on your private network, so it can reach other resources — a database, an internal registry, an on-premises system over a tunnel — without going over the internet.
- Pick an address from Select VPC IP.
- Click Attach.
+ Reserve New VPC IP creates one if you have none.
While a VPC IP is still attaching, Terminate Cluster and Delete are refused. Wait for it to settle, then retry. If a cluster seems un-terminatable, this is the usual reason — check this tab.
If your training data lives in a database or an object store on your VPC, attaching a VPC IP keeps that traffic off the public internet entirely. It does not replace the public IP — you keep SSH access on the public address.
Security Groups
Manage security groups attached to this cluster. Click here to create a new security group.
Select a group from Select Security Groups and click Attach. Attached groups are listed below; expanding one shows its rules under Inbound Rules and Outbound Rules:
| Column | Shows |
|---|---|
| Type | The rule type, e.g. SSH |
| Protocol | TCP, UDP, ICMP |
| Ports | The port or range |
| Source | Where traffic may come from |
| Description | What the rule is for |
A default SSH group typically contains one rule:
SSH TCP 22 Any Network Allow SSH access to the resource from any network.
Each attached group has an edit button and a red detach button.
What has to be open
| Traffic | Requirement |
|---|---|
| SSH to the login node | Inbound TCP 22. Without it the cluster is unreachable |
| Node-to-node Slurm and NCCL traffic | Handled internally. You do not open ports for it |
| Anything else you expose | Only what you deliberately add |
Provisioning succeeds and the cluster runs — you simply cannot log in. If SSH times out, check this tab first. Fix it by attaching a group that allows port 22; you do not need to recreate the cluster.
Any Network on port 22 is why the login-node log fills with
rejected login attempts from the internet. They are being rejected — password authentication is off —
but restricting the source to your office or VPN range removes the noise and the risk together.
Create a group with your own CIDR, attach it, and detach the open one.
Removing the last group is refused. Attach a replacement first.
Internal Cluster Networking
You do not configure any of this, but it is worth knowing what you have:
| Fact | Detail |
|---|---|
| Node-to-node fabric | GPU nodes are placed together and connected by the cluster's high-speed RDMA fabric |
| Slurm traffic | The controller, login node and workers talk over the internal network. No security-group rules needed |
| Where the public IP lands | On the login node. Worker nodes are not individually addressable from outside |
| NCCL and MPI | Work over the internal fabric. See Multi-node container training |
The fabric is available on the node, but a container starts from its image's filesystem. For multi-node NCCL over RDMA, mount the device path into the container:
--container-mounts=/pfs:/pfs,/dev/infiniband:/dev/infiniband
Hardening Checklist
| Step | Why |
|---|---|
| Restrict inbound SSH to your own CIDR ranges | Removes the constant internet scanning against port 22 |
| Convert the public IP to reserved | Stable endpoint, so an allow-list stays valid |
| Use per-user logins rather than a shared root key | Individual revocation, and job ownership you can audit |
| Keep at most two root SSH keys | Fewer keys, fewer ways in — but keep a second so you cannot lock yourself out |
| Attach a VPC IP for private data sources | Keeps that traffic off the public internet |
| Do not open extra inbound ports "for now" | Nothing about a Slurm Cluster needs an inbound port other than 22 |
| Review attached groups when a cluster changes hands | A group added for a one-off test tends to stay attached |
The login node accepts SSH keys only; there is no password to set and none is issued. If someone asks for a password to the cluster, they need an SSH key added instead — either to the root keys or, better, as their own login user.