--- title: Network and Security sidebar_label: Network & Security --- import { Globe, Share2, Shield, Lock, Wifi } from 'react-feather'; # 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. }, { href: '#vpc-ip', label: 'VPC IP', icon: }, { href: '#security-groups', label: 'Security Groups', icon: }, { href: '#internal-cluster-networking', label: 'Internal networking', icon: }, { href: '#hardening-checklist', label: 'Hardening checklist', icon: }, ]} /> 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. :::tip Do this before anyone scripts against the address 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. :::warning Changing the IP changes the SSH endpoint 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](/docs/tir/SlurmCluster/manage/) afterwards. ::: :::info At least one IP must remain attached 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. 1. Pick an address from **Select VPC IP**. 2. Click **Attach**. **+ Reserve New VPC IP** creates one if you have none. :::warning A VPC attach in progress blocks terminate and delete 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. ::: :::tip Use a VPC IP for private data sources 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 | :::danger Without inbound TCP 22 you cannot reach the cluster 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. ::: :::tip Narrow the source range rather than removing the rule `Any Network` on port 22 is why the [login-node log](/docs/tir/SlurmCluster/manage/logs) 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. ::: :::info At least one security group must remain 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](/docs/tir/SlurmCluster/containers/multi-node-training) | :::info Container jobs need the RDMA devices passed in explicitly 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: ```bash --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](/docs/tir/SlurmCluster/connect/login-user-management) 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 | :::warning Passwords are never the answer 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](/docs/tir/SlurmCluster/manage/actions#update-ssh-keys) or, better, as their own [login user](/docs/tir/SlurmCluster/connect/login-user-management). ::: --- ## Related Resources - [Connect to the cluster](/docs/tir/SlurmCluster/connect/) - [Login User Management](/docs/tir/SlurmCluster/connect/login-user-management) - [Cannot connect](/docs/tir/SlurmCluster/troubleshoot/connectivity) - [Multi-node container training](/docs/tir/SlurmCluster/containers/multi-node-training) - [Security groups](/docs/tir/network/Security_Group/)