Managing membership

Before you start

• You are the PI (or a delegate acting on the PI’s behalf) for a Cloud RAP that backs a Kestrel tenant.
• You understand the tenancy model — one Cloud RAP = one Capsule Tenant, 1:1.
• You have a CCDB account at ccdb.alliancecan.ca with an active faculty role.

Who manages membership

Tenant membership on Kestrel is currently managed by RCS in Keycloak. Each tenant has a Keycloak group (named after the Cloud RAP group), and RCS staff add and remove users in that group — open a ticket to request a change. PI self-service (managing membership through the Cloud RAP in CCDB) is planned but not live yet.

Membership requests should come from the PI holding the Cloud RAP (or a delegate). Graduate students, postdocs, and research staff cannot add themselves — ask your PI to request it.

Adding a user

The user must already have a CCDB account (for students, postdocs, staff, and external collaborators, that means a sponsored role under your supervision). Keycloak’s user store is federated strictly from the Alliance (CCDB) LDAP — accounts are never created directly in Keycloak — so RCS cannot add a user to the tenant group until their CCDB account exists and has synced through. If they have no account yet, they register at ccdb.alliancecan.ca first — see Requesting access for the full end-to-end flow. Once they do:

1. Open a ticket with RCS asking to add the user to your tenant, including the user’s CCDB username / CCRI and your tenant name.
2. RCS adds the user to the tenant’s Keycloak group and confirms on the ticket.
3. The user runs kubelogin once — their next OIDC login returns an id_token with the tenant’s group name in the groups claim, and kubectl works.

Tenant membership is not automatic

Neither CCDB sponsorship nor Cloud RAP membership grants Kestrel access by itself — RCS must add each user to the tenant’s Keycloak group. This is the single most common “why can’t I access my tenant?” question on Kestrel. If a user’s kubectl auth whoami shows no oidc:<your-tenant> group, first check that the add-user ticket was filed and completed.

The propagation chain

Access takes effect through four systems:

1. CCDB — the user’s account and sponsored role exist here. This is the prerequisite; nothing on the Kestrel side can happen without it.
2. Alliance LDAP → Keycloak — Keycloak federates its users from the Alliance LDAP directory (dc=computecanada,dc=ca). A brand-new CCDB account can take a sync cycle before it is visible in Keycloak.
3. Keycloak group — RCS adds the user to the tenant’s group. This is the step that actually grants access.
4. kube-apiserver — validates the OIDC token’s groups claim and maps it to the Capsule Tenant owner group (oidc:<rap-group-name>).

There is no Kestrel-side cache to flush: once RCS confirms the change, the user runs kubelogin again and the next token reflects the updated membership.

Removing a user

1. Open a ticket with RCS asking to remove the user from your tenant.
2. RCS removes the user from the tenant’s Keycloak group.
3. The next time the user’s token is issued, it no longer contains the tenant’s group name, and kubectl requests against tenant namespaces are denied.

Existing running workloads are not affected — Kubernetes does not kill Pods when a user loses access. The user simply cannot create, modify, or delete resources in the tenant’s namespaces going forward.

Troubleshooting membership issues

Symptom	Likely cause	Fix
User added but kubectl get ns returns nothing	An empty namespace list is normal — a fresh tenant has no namespaces until someone creates one	Have the user run kubectl auth whoami and check the Groups row contains oidc:<your-tenant>. If it does, access is working
oidc:<your-tenant> group still missing after RCS confirms the add	Stale cached token	Have the user run kubectl oidc-login clean, then any kubectl command to force a fresh login
RCS cannot find the user in Keycloak	The CCDB account is brand-new (not yet synced) or does not exist — Keycloak only knows users federated from CCDB’s LDAP	Verify the CCDB account and role are active; allow time for a new account to sync, then follow up on the ticket
User removed but can still run commands	Cached kubelogin token has not expired	Token expires on its own; no action needed unless urgency requires RCS intervention

For CCDB account and role issues (role approval stuck, missing CCRI), contact accounts@tech.alliancecan.ca. For Cloud RAP application and allocation questions, contact cloud@tech.alliancecan.ca. For membership changes and any other Kestrel-specific issues, open a ticket with RCS.