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 managed in CCDB, not in Keycloak. The PI adds or removes users from the Cloud RAP at ccdb.alliancecan.ca; there is no Kestrel-side group store to update and no RCS ticket required for routine membership changes.

Only the PI holding the Cloud RAP (or a delegate with the appropriate CCDB role) can modify the RAP’s user list. Graduate students, postdocs, and research staff cannot add themselves — they must ask their PI.

Adding a user

1. Log in to ccdb.alliancecan.ca with your Alliance CCI.
2. Navigate to your Cloud RAP (e.g. def-profname or crg-profname-xx).
3. Add the user’s CCRI to the RAP’s member list.
4. The user runs kubelogin once — their next OIDC login through Keycloak returns an id_token with the Cloud RAP’s group name in the groups claim, and kubectl works.

The user must already have a CCDB account with a sponsored role under your supervision. If they do not, they need to register at ccdb.alliancecan.ca first — see Requesting access for the full end-to-end flow.

Cloud RAPs do not auto-add sponsored users

Alliance HPC RAPs (rrg-*, rpp-*) automatically include all of a PI’s sponsored users. Cloud RAPs do not. You must explicitly add each user to the Cloud RAP in CCDB. This is the single most common “why can’t I access my tenant?” question on Kestrel.

The propagation chain

When you add or remove a user in CCDB, the change flows through three systems before it takes effect in kubectl:

1. CCDB — the PI makes the change in the Cloud RAP’s user list.
2. Alliance LDAP — CCDB propagates the membership change to the Alliance LDAP directory (dc=computecanada,dc=ca). This is usually immediate but can take a few minutes.
3. Keycloak — Kestrel’s OIDC broker reads Alliance LDAP on every authentication. The next time the user runs kubelogin, Keycloak issues an id_token reflecting the updated group membership.
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 cache to flush or sync to trigger — the chain is pull-based. The user simply runs kubelogin again and the updated membership takes effect.

Removing a user

1. Log in to ccdb.alliancecan.ca.
2. Open your Cloud RAP and remove the user’s CCRI from the member list.
3. The next time the user runs kubelogin, their id_token no longer contains the Cloud RAP’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	LDAP propagation delay	Wait a few minutes, then run kubelogin again
User added but still denied	User not on the Cloud RAP (only in the CCDB roster)	Verify the user is on the Cloud RAP specifically, not just sponsored under you
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
CCDB shows the user but Keycloak does not	Alliance LDAP issue	Contact accounts@tech.alliancecan.ca — this is an Alliance infrastructure issue, not a Kestrel issue

For CCDB account issues (role approval, missing CCRI, RAP application questions), contact accounts@tech.alliancecan.ca. For Kestrel-specific issues after membership is confirmed in CCDB, open a ticket with RCS.