How Managed Cluster Access Works

Administrators assign cluster access in ACTIVATE. On nodes with User Population enabled, the agent creates the Linux accounts those users need and keeps their groups updated. It applies these changes in the background.

You can also use Linux accounts maintained by your existing systems. Administrators choose which account, SSH, home-directory, and sudo settings the agent manages.

Accounts and Permissions

Term	What it means
ACTIVATE account	The account a person uses to sign in to ACTIVATE. It has a username and membership in an ACTIVATE organization and its groups.
Cluster access level	Login, Sudo, or Admin permission assigned to a group or the organization through Manage Access. A user receives access through their membership.
Linux account	The username, numeric user ID (UID), and group memberships that Linux uses on a cluster node. It can be maintained by your existing account system or by the ACTIVATE agent.
SSH key	A credential used to authenticate an SSH connection to a Linux account. The SSH server accepts public keys from its configured sources, and the connecting client must have the matching private key.

Creating an ACTIVATE account does not by itself assign cluster permission. Access follows the permissions given to the user's organization and groups.

How Linux Accounts Are Created

In Manage Access, an organization administrator assigns Login, Sudo, or Admin access to groups or the organization. ACTIVATE combines those permissions with group and organization membership to determine which users have access.

Example: access through the Researchers group

Cluster permissionResearchers has Login access

Group membershipPriya belongs to Researchers

ACTIVATEPriya has Login access to this cluster

On nodes with User Population enabledThe agent creates Priya's Linux accountIt keeps the account and groups updated in the background.

Account creation can happen before Priya's first connection. Login access does not grant sudo.

Adding someone to a group that has cluster access also gives that person access. Organization-wide permissions apply to members who join later. With User Population enabled, online agents apply account changes on a subsequent heartbeat.

Without User Population, your existing Linux account system must supply the accounts. Other agent features, including SSH key lookup, remain independently configurable. See Linux account storage and conflict checks.

What the Agent Configures

Administrators choose these settings for the cluster and can override them for individual nodes:

Setting	Effect when enabled
User Population	Creates or updates Linux accounts and group membership for users who have cluster access.
Home Directories	Configures home creation through the Linux login system (PAM) and installs a script for node-to-node SSH key creation.
SSH Keys	Configures the node's SSH server to retrieve accepted public keys for an active ACTIVATE username.
Sudo Access	Installs a rule allowing members of the Linux `pwsudo` group to run commands as root without a password. User Population supplies membership for users with Sudo or Admin access, subject to No Root Access policy.

See Identity and Access for dependencies and configuration steps.

With Home Directories enabled:

A missing home directory is created at login. If the agent uses local Linux accounts, it may have created the home along with the account.
An interactive login can create a node-to-node SSH key. The script runs when the home is writable and ~/.ssh/id_rsa is absent. It creates the key without a passphrase and adds its public key to the user's authorized_keys file.

The initial connection authenticates before this script runs. The new key stays in the user's home and supports later SSH connections to nodes that accept it. Automatic key creation runs when the user's shell loads the login startup script.

See Home Directory and Key Files for file paths and permissions.

How Users Connect

Choose the connection method your site supports:

Connection method	What happens
Terminal or CLI connection through ACTIVATE	ACTIVATE checks the user's permission to connect to the selected cluster. The destination SSH server then authenticates the connection to the user's Linux account.
Managed desktop or VS Code session	ACTIVATE checks permission for the requested session. The registered agent on the configured session node starts it.
Direct SSH to a node	The node's SSH server authenticates the user and applies its Linux login rules. See SSH Authentication for ACTIVATE key lookup.

The encrypted agent tunnel carries traffic to a registered node. The permission and authentication checks above still apply when the connection uses the tunnel.

Filesystem permissions, software licenses, scheduler limits, and application permissions remain under their respective systems. ACTIVATE can supply Linux group membership for those systems to use.

Registration Tokens and SSH Keys

Machine registration and user authentication use different credentials:

Credential	Purpose
Registration token	Registers a node with a specific ACTIVATE organization and managed cluster. It does not assign access to users.
Node credential	Authenticates the registered agent's connection to ACTIVATE. The agent receives it during registration. Registration-token expiry does not disconnect an enrolled node.
SSH host key	Identifies a node's SSH server to connecting SSH clients.
User-uploaded SSH public key	Allows a client with the matching private key to authenticate to the user's Linux account when the node accepts that public key.
Platform service and managed workspace keys	Authenticate SSH connections made by the platform or a managed workspace as the user. These paths can work without the user uploading a personal key.
Key generated in the user's home	Supports SSH from that Linux account to other nodes that accept the key, subject to their account and network configuration.

For registration steps and token lifetimes, see Register the Pilot Node.

Access for Collaborators

Registering a machine adds that node to the ACTIVATE organization and cluster named by its registration token. Registering a node in another cluster does not give its users access to your cluster.

Collaborators must belong to the ACTIVATE organization that owns the cluster and have access through a group or organization permission. Their Linux accounts and authentication use the account-management method configured for the cluster.

Register a collaborator's machine as a node only if you intend ACTIVATE to monitor or manage it as part of the cluster. Users do not need to register their personal computers as cluster nodes to connect to the cluster.

Continue with Plan and Set Up to register a pilot node, or Identity and Access to configure accounts and permissions.