Managed Cluster Identity and Access

Use this guide to configure Linux accounts, SSH authentication, and sudo permissions on managed-cluster nodes. For an introduction to the account and permission model, read How Access Works.

Prepare Identities

ACTIVATE assigns numeric Linux user IDs (POSIX UIDs) automatically. Organization administrators can specify a UID during user import to match an existing Linux identity.

1. Organize membership with ACTIVATE groups. ACTIVATE assigns each group a numeric Linux group ID (POSIX GID) when it is created. Check usernames, UIDs, and GIDs against local and directory-service identities on every affected node. The built-in groups use GIDs 9001 (pwuser) and 9002 (pwsudo). Resolve collisions before enabling synchronization.
2. Choose the intended SSH connection method. Users connecting with a personal private key should add its public key under Account > Authentication > SSH Keys. Platform and managed workspace connections can use platform-managed keys. See Managing SSH Keys.

The managed-cluster SSH username is the user's ACTIVATE username. Every node where the user signs in or runs processes must recognize that account. Enable User Population on those nodes if the agent should supply the accounts; otherwise, configure them through your existing Linux account system.

Grant Cluster Access

Open the cluster's actions menu and select Manage Access. Assign an access level to the entire organization or selected groups. The assignment also applies to users who join those groups or the organization later.

Organization administration privileges are still required to edit cluster configuration or access grants. Admin access to a cluster does not make the user an organization administrator.

Access changes reach online nodes after a subsequent heartbeat. Check the account and permissions on every node where the user needs to 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 an online agent on a subsequent heartbeat.

SSH Authentication

With SSH Keys enabled, the node's SSH server retrieves public keys for an active ACTIVATE username. These can include user-uploaded keys, platform service keys, and managed workspace keys. The SSH server authenticates the connection against those keys and its Linux account configuration.

ACTIVATE checks cluster permission for terminal and CLI connections routed through the platform. Direct SSH uses the node's login rules; the key lookup itself does not check destination-cluster permission. With User Population enabled, the agent uses cluster permissions to create and update Linux accounts. It removes its managed account when the user loses all cluster access. See Remove or Reduce Access.

The agent configures an AuthorizedKeysCommand wrapper and an SSH configuration drop-in where supported, otherwise the main sshd_config. It validates the configuration and restarts SSH. On SELinux hosts, it also attempts to enable the persistent nis_enabled boolean so key lookup can reach ACTIVATE. Check for an existing AuthorizedKeysCommand when configuring this feature.

Home Directory and Key Files

Home Directories configures PAM to create a missing home at login and installs /etc/profile.d/pw-user-ssh.sh as a login-shell startup script. On hosts using authselect, it disables the with-mkhomedir feature and configures pam_mkhomedir directly. The local-account storage method can create homes during account creation, independently of this setting.

When the home is writable and ~/.ssh/id_rsa is absent, the script creates an RSA key without a passphrase, appends its public key to ~/.ssh/authorized_keys, and sets permissions to 700 for .ssh and 600 for authorized_keys. It does not upload the key to ACTIVATE. Disabling the setting removes the managed PAM configuration and startup script; it retains existing homes and generated user keys.

Enabled, Disabled, and Unmanaged

Cluster defaults support three states. Nodes inherit these unless a node override or policy applies:

To remove a managed feature, explicitly disable it. Clearing a setting to unset does not request cleanup.

How Linux Identities Are Stored

User Population uses either systemd user records or local Linux accounts. The agent selects the method automatically; both provide the username, UID, and groups that Linux needs.

User Population enabledDoes the agent already manage local accounts here?If so, it keeps using local accounts. Otherwise, it checks systemd support.

↓For a node without agent-managed local accounts

Can systemd serve user records on this node?

If supportedUse systemd user recordsThe agent writes records under /etc/userdb.

If unavailableUse local Linux accountsThe agent uses Linux account commands and tracks the accounts it manages.

The local-account database, /var/lib/pw/localusers.db, identifies the accounts and memberships the agent manages. Retain it through account updates and removal so the agent can complete cleanup.

Recommended Enablement Order

After granting Login access to your pilot users, apply these settings through node-level overrides. Verify the pilot before changing cluster defaults.

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 you need PAM home creation and the managed key-generation script.
3. Enable SSH Keys, validate sshd configuration, and complete an interactive login using the intended key source. Verify home-directory and key creation if enabled.
4. Enable Sudo Access only if policy permits it and the assigned Sudo or Admin permissions and pwsudo membership are correct.
5. Repeat the pilot acceptance checklist before applying settings cluster-wide.

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 when the node should follow future cluster-level changes again. Confirm the effective settings in agent logs and host-level checks after changes. No Root Access takes precedence over both cluster defaults and node overrides.

No Root Access Policy

When the effective No Root Access policy is enabled:

• ACTIVATE does not assign pwsudo membership to users with Sudo or Admin access. They retain ordinary login access.
• Sudo Access cannot be enabled in the cluster or node settings, and API requests to enable it are rejected.
• Effective agent settings force Sudo Access off, including node overrides. Online agents remove their managed /etc/sudoers.d/pwsudo rule when they apply the setting.

The policy applies to ACTIVATE-managed user privileges. The agent service runs as root. An existing local pwsudo group can remain after its managed memberships are removed.

Saved Sudo Access settings are retained. Those cluster settings and node overrides apply again when the policy is removed.

Remove or Reduce Access

1. Account for the user's jobs, sessions, files, and service ownership.
2. Remove every group or organization permission that gives the user access, remove the user from the relevant groups, or reduce Sudo/Admin to Login as appropriate. Check all memberships: another group or organization permission can still give the user access.
3. Keep the relevant agents online and allow a subsequent heartbeat to apply the change. Offline nodes cannot apply revocation until they reconnect.
4. Verify the user's identity and groups on every affected node.

When a user loses all cluster access, an agent with User Population enabled removes the systemd user records or local account it manages for that user and updates group membership. Home directories and user files are retained.

The agent also attempts to terminate the user's processes when access is removed or sudo membership is lost. This happens without waiting for scheduler jobs to finish, so account for running work before applying the change.

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