# Managed Cluster Identity and Access

> Source: https://parallelworks.com/docs/compute/managed-clusters/identity-and-access

# Managed Cluster Identity and Access

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.

## Prepare Identities

For ACTIVATE-managed identities:

1. Confirm each user has a unique ACTIVATE username and POSIX UID. Organization administrators can set UIDs during [user import](/docs/organization-admin/managing-users#importing-users).
2. Organize membership with [ACTIVATE groups](/docs/organization-admin/managing-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.
3. Ask each user who will use ACTIVATE-managed SSH keys to add a public key under **Account > Authentication > SSH Keys**. See [Managing SSH Keys](/docs/account-settings/authentication#managing-ssh-keys).
4. 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](/docs/compute/managed-clusters/planning-and-setup#before-you-begin).

### Recommended Enablement Order

1. Enable **User Population** on the pilot and confirm `getent passwd <username>` and `id <username>` return the intended UID and groups.
2. Enable **Home Directories** if ACTIVATE-managed users need automatic home creation, then complete one pilot login.
3. Enable **SSH Keys**, validate `sshd` configuration, and complete an ACTIVATE-key login.
4. Enable **Sudo Access** only after verifying synchronized `pwsudo` membership and the approved Sudo or Admin grant.
5. Repeat the [pilot acceptance checklist](/docs/compute/managed-clusters/planning-and-setup#pilot-acceptance-checklist) before applying the settings cluster-wide.

:::caution 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:

1. Account for the user's jobs, sessions, files, and service ownership.
2. Remove the group or organization grant, or reduce Sudo/Admin to Login.
3. Keep the relevant agents online and wait for a subsequent heartbeat.
4. 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.

:::caution 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](/docs/compute/managed-clusters/operations#offboard-a-node-or-cluster) while the agent can still clean up its managed settings.