Workspaces and project access
Rename a workspace, invite members, and manage project permissions.
A workspace contains your team and projects. Workspace membership and project access are separate: accepting a workspace invitation does not automatically grant access to its projects.
Settings navigation
Open Select a resource, choose a workspace, then select a project in the Console. The active project appears in the top bar. Select its name to reopen the resource selector. Changing the workspace in the selector does not change the active resource until you select a project.
- Workspace Settings contains Overview, Workspace Members, IAM, and Billing & Credits.
- Project Settings contains Overview for the selected project.
Workspace General Admins and Owners can rename the workspace and manage workspace members. Project permissions are described below. Billing account permissions are managed separately; see Billing and automatic recharge.
Change a workspace name
- Open Workspace Settings, then Overview.
- Under Workspace name, enter a single-line name with 2–50 characters. Leading and trailing spaces are removed.
- Select Save changes.
A success notification confirms the change. The new name appears in Overview and in the workspace control inside Select a resource. The workspace ID, URLs, projects, and resource connections remain the same. Overview also displays Workspace Created At.
The name editing form requires Workspace General Admin or Owner. General Viewer can read workspace details.
Fixed Workspace ID
The Workspace ID shown in Workspace Settings → Overview is immutable. You can change the workspace display name, but cannot choose or change its ID.
Service-account addresses have a fixed workspace suffix. Renaming the workspace does not change existing addresses. These addresses identify service accounts and do not receive email. No Workspace ID setup is needed before creating a service account.
Invite a workspace member
With Workspace General Admin or Owner:
- Open Workspace Settings, then Workspace Members.
- Select Add member to open the panel on the right.
- Enter the recipient's email address and select Add member in the panel. The panel closes after the invitation is sent; if sending fails, your entry remains available to retry.
- Confirm the invitation appears with Waiting for acceptance.
The recipient does not need an existing RDC Cloud account when you send the invitation. Invitations expire after seven days. An email address cannot have multiple unexpired pending invitations to the same workspace. If the email cannot be sent, the invitation operation fails and does not add a member.
Accept or deny an invitation
- Open the invitation link in the email.
- Sign in with the verified email address that received the invitation. Use Google sign-in or an email/password account provided by your administrator. Public email registration is not available.
- Review the workspace name and expiry, then select Accept or Deny.
Accept adds you as a workspace MEMBER. Deny closes the invitation without adding you. Select Continue to Console after the action completes. New accounts may require approval before accessing Console.
If the signed-in address is different, select Use another account. Cancelled, expired, or already processed invitations cannot be accepted again; request a new invitation from the workspace owner when necessary.
Cancel an invitation
In Workspace Members, select Cancel invitation on a pending invitation. The recipient can no longer accept that link. This action does not remove someone who has already accepted; remove their membership instead.
Project IAM and Security Insights are separate Console destinations. Workspace Members is for invitations and membership removal; role changes are managed in IAM.
Assign roles
Invite a person to the workspace before assigning roles.
- For workspace-wide access, open Workspace Settings → IAM. For one project, open IAM from Quick access or search.
- Find the member and select Edit roles.
- Choose a category or search for a role. Select one or more roles.
- Select Save changes.
The table distinguishes directly assigned roles from roles inherited from the workspace. Change inherited roles at the workspace where they were assigned. A dash means no direct roles; the member may still have inherited access.
| Category | Built-in roles |
|---|---|
| General | Viewer, Editor, Admin, Owner |
| Container Engine | Viewer, Editor, Admin |
| Memory Store | Viewer, Admin |
| Relational Database | Viewer, Admin |
| Artifact Registry | Viewer, Admin |
| Envault | Viewer, Secret Accessor, Admin |
| Billing | Viewer, Admin |
| Security Insights | Viewer |
Each role shows its identifier and description, such as roles/container_engine.admin. Product roles apply to that product. Container Engine Admin does not grant project IAM or database administration.
General Viewer reads metadata and, when assigned at Workspace scope, Envault secret values without creating, editing or deleting them. Project-only General Viewer and Workspace Envault Viewer do not grant secret-value access. General Editor permits ordinary resource creation and operation but does not grant Envault value access by itself; roles are independently defined and additive. General Admin adds sensitive and destructive operations and manages non-owner assignments. General Owner also manages ownership. General Viewer and Editor do not grant infrastructure credentials or terminal sessions.
Envault and Billing roles are assigned at the workspace only. A Project Owner does not receive workspace secret values or billing management authority. Linking an Envault source requires both container binding authority and access to that workspace's secret values. Deploying an already configured binding follows the container's deployment permission.
Workspace inheritance
Effective project permissions combine eligible workspace permissions with direct project permissions.
For example, Workspace Container Engine Admin plus Project Viewer still permits container administration. Project Viewer does not reduce inherited access. Roles from different products can be combined.
Membership by itself grants no product role. Accepting an invitation does not automatically grant project or secret access.
Ownership and concurrent changes
Only an Owner with authority for the selected scope can grant or remove Owner. Every workspace and project must retain at least one directly assigned Owner. Assign a replacement before removing the final Owner, even when another person has inherited ownership.
You cannot grant permissions you do not hold. If another administrator changes the same member while you are editing, the save is rejected and current roles are reloaded. Review the assignments before saving again.
Remove access
To remove direct project access, open Edit roles, clear the selected roles, and save. Workspace membership and inherited roles remain.
To revoke inherited access, edit the member's workspace roles. To remove the person entirely, select Remove member in Workspace Members. This removes workspace membership and access to all its projects. Owner protection also applies to removal.
Changes apply to subsequent requests, including existing CLI credentials. An open page may need refreshing to update its controls. Terminal sessions recheck access while connected.
Removing a member does not cancel billing-account charges or automatic recharge. Manage those settings on the billing account itself.
Related guides
Permission denied
If you open a page without the required permission, Console shows Permission denied. When available, the dialog includes the permission identifier to share with your workspace or project administrator.
Select Close to return to the current project home. If the requested project is unavailable to your account, Console opens the welcome page and resource selector. A permission denial while performing an action keeps you on the current page after closing the dialog.