Members
A namespace’s members are the people who can sign in and see it. Manage them under Team.
Adding someone
Invite them from the Team page and assign a role. The role decides what they can do in the console — see User Roles.
On Community the invitation email is never sent, because the instance has no mail. The invitation
is still created and the console gives you its link to copy — send it however you like. Or skip
the person entirely: user create and namespace member add on the host put them in. See
Administration.
Membership and device access are different things
This is the distinction that matters most on this page, and the one people get wrong.
Being a member does not grant access to any device. In a new namespace, device access comes entirely from access policies, and a new member matches none of them.
So adding somebody is two steps:
- Add them as a member, with a role.
- Write or extend a policy that grants them something.
A member with no policy can sign in, see the namespace, and connect to nothing. That is deliberate — default deny means access is something you grant on purpose.
The exception is the namespace owner, who is covered by the starter Owner access policy.
Roles as policy subjects
The cleanest way to handle step 2 is to grant the role, not the person:
| Name | Effect | Subject | Devices | Logins |
|---|---|---|---|---|
| Operators to fleet | allow | Role: operator | tag production |
deploy |
Now adding somebody as an operator grants them the fleet, and removing them takes it away, with no policy edited either time. Per-person policies are for genuine exceptions.
Removing someone
Removing a member ends their access to the namespace.
Two things to do alongside it:
Revoke their SSH identities. Membership and identities are separate records. Revoke the keys bound to them on the SSH Identities page.
Check for automation on their key. If a pipeline was configured with a key of theirs, it stops working. That is why automation should connect as an API key with its own SSH access instead.
Where to go next
- User Roles — What each role can do.
- Access Policies — Granting device access.
- Single Sign-On (SAML) — Bringing members from an IdP.