Members and tenants

Members are role assignments

A boundary keeps no member list of its own. Its members are the users, groups and service accounts that hold a role assignment on the boundary or on something inside it:

• A role assigned on the boundary applies to every resource group and resource in it.
• A role assigned on a resource group or a single resource reaches only that.
• Every built-in role for people lets its holder see the boundary, so any assignment inside it makes the boundary appear in that person's boundary list.

The boundary's Access Control tab shows and changes the assignments on the boundary itself. Assignments on a resource group or a resource are made under Access control (IAM) in the sidebar, or on a resource's own Access Control tab. Assigning roles needs rbac/members/write, which the boundary's Owners have and Contributors do not; the boundaries API offers a second way in with boundaries/members/manage — see Permissions. The roles and how to assign them are described in Role assignments.

Giving someone access

1. Make sure the person belongs to the boundary's tenant — see The tenant. Someone who is new to the platform joins it by accepting an invitation; see Invite a user.
2. Open the boundary, then Access Control, and assign a role. For narrower access, assign it on a resource group or a resource instead.

Removing the assignment removes the access.

The tenant

The tenant is the customer a boundary belongs to. A tenant can own several boundaries, and the boundaries of one tenant share its people and its single sign-on: email domains and identity providers are configured per tenant and shown read-only on the boundary's Overview. A tenant has no name of its own; the portal describes it by the boundaries it owns.

The tenant limits who can be given a role in the boundary:

• A user or service account must be a member of the tenant. People become members by accepting an invitation, by signing in through the tenant's identity provider, or by being added by an administrator.
• A group must belong to the tenant.
• A workload identity — a managed identity or a service account created in a boundary — belongs to the tenant of the boundary it was created in. One from another tenant is admitted only when a boundary trust runs from its own boundary into this one.

Apart from the platform administrators described under Guests, an assignment for anyone else is refused.

Guests

A platform administrator holding rbac/members/admin at the root — the Platform Owner role — is not held to the tenant rules and may assign a role to a user, group or service account from another tenant. A user assigned this way is recorded as a guest of the boundary's tenant, so the access shows up as a membership that the tenant's administrators can see rather than as a silent exception. A group or service account from another tenant gets no such record.

When a boundary moves

A platform administrator can move a boundary to another tenant. Its role assignments stay where they are, and the people who had access become members of the new tenant. The details are in Tenants.