Managed Cluster Identity and Access | Managed Clusters

Managed clusters can use accounts already maintained on the Linux hosts, or the agent, which runs as root, can synchronize ACTIVATE identity and access data. Coordinate these settings with the Linux administrator because they change NSS, PAM, sshd, and sudoers configuration.

Requiresorg:admin

Prepare Identities

For ACTIVATE-managed identities:

Confirm each user has a unique ACTIVATE username and POSIX UID. Organization administrators can set UIDs during user import.
Organize membership with ACTIVATE groups. ACTIVATE assigns each group a POSIX GID when it is created; confirm assigned GIDs do not collide with local or directory-service groups before synchronization.
Ask each user who will use ACTIVATE-managed SSH keys to add a public key under Account > Authentication > SSH Keys. See Managing SSH Keys.
Check usernames, UIDs, and GIDs against local and directory-service accounts on every affected node. Resolve collisions before enabling synchronization.

The managed-cluster SSH username is the user's ACTIVATE username. If that username does not already resolve on the host, enable User Population on every node where the user must sign in or run processes.

Choose Access-Management Settings

Open the cluster and click Edit. The cluster settings become defaults for registered nodes and are applied by the agent on a subsequent heartbeat.

Setting	Changes on an enabled node	Dependencies and recommended use
User Population	Installs and configures `libnss_cache`, then synchronizes authorized ACTIVATE users and groups into passwd, shadow, and group cache files	Enable first when ACTIVATE supplies Linux identities. It is required for synchronized `pwsudo` membership.
Home Directories	Configures PAM to create `/home/<username>` at first login and deploys first-login SSH key generation for node-to-node SSH	Pair with User Population for users who do not already exist locally. Existing home-directory contents are not removed when disabled.
SSH Keys	Configures `sshd` to retrieve a user's public keys from ACTIVATE	Users must have a public key in ACTIVATE. Test for conflicts with an existing `AuthorizedKeysCommand`, cloud guest agent, or SSH policy.
Sudo Access	Creates a sudoers rule granting passwordless sudo to the `pwsudo` group	Enable User Population too; without it, ACTIVATE cannot synchronize users into `pwsudo`. Grant only Sudo or Admin permission to intended administrators.

User Population can install build dependencies and obtain libnss_cache source from GitHub. Review the package and network requirements in Plan and Set Up.

Recommended Enablement Order

Enable User Population on the pilot and confirm getent passwd <username> and id <username> return the intended UID and groups.
Enable Home Directories if ACTIVATE-managed users need automatic home creation, then complete one pilot login.
Enable SSH Keys, validate sshd configuration, and complete an ACTIVATE-key login.
Enable Sudo Access only after verifying synchronized pwsudo membership and the approved Sudo or Admin grant.
Repeat the pilot acceptance checklist before applying the settings cluster-wide.

System configuration changes

Test on a non-critical node with a host backup or documented rollback path. Enabling or disabling these settings can restart SSH and alter NSS, PAM, sshd, and sudo behavior. Maintain an independent administrative access path while validating the changes.

Node-Level Overrides

To give one node different access settings, open Nodes, select the node, and click Settings. Values that differ from cluster defaults appear as Overridden.

Each setting inherits the cluster default independently until you override it. Use Reset to default for a setting when the node should follow future cluster-level changes again. After changing an override, confirm the effective settings in the agent logs and with the host-level checks above.

Grant Cluster Access

Open the cluster's actions menu and select Manage Access. Grant a level to the entire organization or selected groups.

Access level	User capability	Linux effect when synchronization is enabled
Login	View the cluster, sign in as a normal user, and submit jobs	User and group data are synchronized when User Population is enabled
Sudo	Includes Login access and permits administrative work	User joins `pwsudo` when User Population and Sudo Access are enabled
Admin	Highest managed-cluster access level; also includes sudo access	User joins `pwsudo` under the same setting dependencies

Organization administrator permission is still required to create, configure, or delete the managed cluster. Managed clusters do not have a Writer level.

Access changes reach online nodes after a subsequent heartbeat. Validate access on every node where the user must resolve or sign in, not only the login node.

Remove or Reduce Access

Plan revocation like an operational change:

Account for the user's jobs, sessions, files, and service ownership.
Remove the group or organization grant, or reduce Sudo/Admin to Login.
Keep the relevant agents online and wait for a subsequent heartbeat.
When User Population is enabled, verify the cache and pwsudo membership changed on every affected node.

When a synchronized user loses all cluster access, the agent removes that user from its cache and attempts to terminate processes running under the revoked UID. It also attempts to terminate the user's processes when Sudo or Admin access is reduced to Login. Treat that behavior as disruptive: do not revoke access during an active workload without coordination.

Revocation is not host restoration

Removing sudo permission prevents future synchronized pwsudo membership, but it cannot undo files, services, credentials, scheduled tasks, or other persistent changes the user previously made as root. Audit or restore the affected nodes when you need assurance that those changes are gone.

For removal of the integration itself, use the offboarding procedure while the agent can still clean up its managed settings.