Tenant Administration

Tenant admins make AI Cloud usable for a team. The job is to keep projects, members, access, service accounts, spend, and recovery paths in a reviewable state.

Admin First-Run Checklist

Step	Outcome
Confirm tenant	Workspace name and default project are visible.
Review projects	Project names, owners, and lifecycle state are understandable.
Review members	Users have only the roles they need.
Review service accounts	Automation identities are scoped, rotatable, and auditable.
Review spend and quota	Balance, entitlement, and quota posture are clear before launch.
Review security	MFA, SSH keys, API keys, and sessions have an owner and support path.

Project Lifecycle

Projects are the normal boundary for work, access, and usage attribution.

Recommended project practices:

• Use names that explain the team or workload purpose.
• Keep a clear project owner.
• Review membership before launching sensitive work.
• Archive or remove projects that no longer have an owner.
• Keep billing or cost-center attribution current when it is enabled.

Project Setup Walkthrough

1. Open Access.
2. Open Projects.
3. Confirm the project name, owner, and default status.
4. Create or rename only when the project purpose and owner are known.
5. Set the default project only when the team expects new launches to land there.
6. Remove or archive projects only after checking active workloads, storage, service accounts, and billing ownership.

Project names should be meaningful to users. Prefer team or workload names over temporary labels. Keep billing-unit or department attribution visible when the tenant uses those controls; if the field is not visible yet, record the intended owner in the project description or handoff packet.

Tenant Onboarding Flow

Tenant onboarding should end with a usable project and a known owner.

When platform operators create the tenant, tenant admins should still be able to verify the resulting workspace, project, members, and handoff path in the product.

Members And Roles

Use least privilege. Add users to the projects they need and avoid broad roles for temporary work.

Role posture	Recommended use
Viewer or reader	Inspection and handoff without mutation.
Member	Normal workload launch and operation.
Project admin	Project-level membership and runtime coordination.
Tenant admin	Tenant-wide access, support, and governance.

Membership Review Steps

1. Open Access.
2. Confirm the tenant and project context.
3. Open Projects to check project ownership.
4. Open Memberships to review user roles.
5. Add only the member and role needed for the project.
6. Remove stale users or downgrade roles after temporary work.
7. Use the visible correlation ID if a role change is denied.

An access-denied result can be correct when the current user lacks the required admin role. If it appears during tenant-admin setup, fix the admin role first instead of retrying the same action.

Membership Lifecycle

Action	Use when	What to verify
Add member	A user needs access to the tenant or project.	tenant, project, tenant role, project role, and source.
Change role	A user changed duty or temporary work ended.	old role is removed, new role is visible, and audit evidence exists.
Remove project access	A user no longer needs a project.	tenant membership remains only if the user still belongs to the workspace.
Offboard user	A user leaves the workspace.	memberships, keys, service accounts, workloads, and storage ownership are reviewed.
Investigate denied change	The UI shows an access-denied message.	current admin role, target user, project, correlation ID, and timestamp are captured.

Do not use an access-denied screenshot as a happy-path guide image. It belongs in troubleshooting or blocked-state documentation so a new admin does not mistake a denied mutation for normal setup.

Service Account Lifecycle

Create service accounts for automation, not for interactive user shortcuts. Each service account is scoped to a project and should have a named owner, purpose, and rotation plan.

For each service account, keep:

• owner;
• purpose;
• project scope;
• credential rotation plan;
• last-used review;
• cleanup owner.

Create A Service Account

Use a human admin session to create the automation identity. The initial client secret is shown once.

gpuaas service-accounts create \
  --project-id <project_id> \
  --name "CI deployer" \
  --slug ci-deployer \
  --description "Publishes verified app artifacts from CI"

Store the returned key ID and client secret in the CI or secret-management system immediately. Do not store them in source control or a shared CLI config.

Mint A Short-Lived Automation Token

Automation uses the service-account credential to mint a short-lived access token, then calls project-scoped APIs with the matching project context.

export GPUAAS_CLI_HOME=/secure/ci/gpuaas-cli

gpuaas --base-url https://api.<your-ai-cloud-domain> auth service-account-token \
  --service-account-id <service_account_id> \
  --key-id <key_id> \
  --client-secret "$AI_CLOUD_SERVICE_ACCOUNT_SECRET"

gpuaas context set project-id <project_id>
gpuaas context show

Use one service account per project automation purpose. Cross-project automation should use separate identities so ownership, billing attribution, and audit evidence stay clear.

Review, Rotate, Disable, And Delete

gpuaas service-accounts list --project-id <project_id>
gpuaas service-accounts get --project-id <project_id> --id <service_account_id>

gpuaas service-accounts rotate-key \
  --project-id <project_id> \
  --id <service_account_id>

gpuaas service-accounts disable \
  --project-id <project_id> \
  --id <service_account_id>

gpuaas service-accounts delete \
  --project-id <project_id> \
  --id <service_account_id>

Rotate when a credential is older than policy, when a CI runner changes, or when exposure is suspected. Disable first when you need a reversible stop. Delete when the automation purpose has been retired.

Service-account changes are privileged actions. Keep the correlation ID from any failed operation so support can trace the access decision without asking for secrets.

Billing, Storage, And Launch Readiness

Before users start launching compute or apps, verify:

• balance is sufficient for the walkthrough;
• budget or low-balance state is not blocking launches;
• project quota can cover the expected runtime;
• at least one storage bucket exists for data-heavy work;
• storage ownership and retention expectations are clear;
• the runtime catalog shows the intended compute or app options.

If any item is blocked, capture the visible state and route it through the support path before starting launch UAT. A launch test should not be the first place a missing quota, storage, or billing prerequisite is discovered.

Security And Recovery

Tenant admins should know the recovery path for:

• lost MFA device;
• stale or compromised session;
• SSH/API key rotation;
• service-account credential rotation;
• user offboarding;
• workload ownership transfer.

Use Account Security as the user-facing account-protection baseline.

Handoff To Users

Before giving users a tenant for UAT or production work, confirm:

• sign-in works for the intended users;
• at least one project is ready;
• runtime catalog entries are visible;
• quotas and balance are enough for the walkthrough;
• account security path is clear;
• support contact and escalation evidence are known.

Use Billing And Storage to prepare quota, balance, storage, and cleanup guidance before handoff.

Offboarding Checklist

Area	Tenant-admin check
Memberships	remove project access and tenant access when no longer needed
SSH/API keys	confirm the user has removed or rotated personal credentials
Service accounts	rotate, disable, or delete automation identities the user owned
Workloads and apps	transfer ownership, decommission, or document who keeps them running
Storage	transfer bucket ownership or apply the tenant retention policy
Billing	confirm no orphaned spend remains under the user's project or automation
Evidence	keep correlation IDs, timestamps, and final state screenshots for support

Operator Boundary

Tenant admins should not need provider credentials, direct database access, or operator runbooks for normal user administration. Provider setup, node enrollment, deployment, runtime repair, and emergency cleanup belong to the platform operator path.