Skip to content
Create free account
Create free account
Teams7 min read

When an admin leaves: the keys that sign everything

An admin holds the keys and accounts that vouch for everyone else's access. The order that closes them: ownership, vault keys, recovery channels, review.

Crunu teamPublished 7 min read

Example. Kiteline is a fictional company.
On this page

When an admin leaves, you replace more than their access. Admins hold the things that vouch for everyone else's access: the vault's signing and recovery keys, the right to add people and tokens, the recovery email and second factor of cloud root accounts, the domain, billing, and the trust policies that let CI in. Work in this order: make sure someone else already owns everything; remove them from the vault and change the organization's own keys; take over every account that can recover or re-grant access; review what they changed recently; then reissue the values they saw. The vault part can be done in one sitting. The accounts around it are a list you work through by hand.

The guide on what to rotate when a developer leaves covers any departure. This post is about what changes when the person was the one granting access.

What an admin has that a member doesn't

A member has values: the environments they could read. An admin has the power to decide who else gets values, and usually some keys that prove those decisions are genuine.

Inside a vault like Crunu, owners and admins:

  • manage members, access profiles, machines and service tokens;
  • know the organization's signing key, which signs who may read which environment, the certificates of members and machines, and the revocation list;
  • know the organization's recovery key, which can open members' personal environments when the organization setting for that is on;
  • saw every service token they created, because a token is shown once, to its creator.

Outside the vault, the same person may also hold the accounts nobody else logs into: the cloud root user and its recovery channels, the domain registrar, the identity provider, owner rights on the code host, the release signing key, the alert and billing contacts.

A member's departure is a question of what they saw. An admin's is also a question of what they could still sign, approve or recover.

Step 0: make sure nothing depends on them

Do this before their last day, ideally long before. GitHub's documentation puts the rule simply: "we recommend that at least two people within each organization have the owner role", because "if an organization only has one owner, the organization's projects can become inaccessible if the owner is unreachable" (GitHub Docs).

In Crunu the same rule is enforced and has a harder edge. The last owner of an organization can't be removed, and only an owner can remove an admin or another owner. Because the server can't reset passwords, an organization whose owners and admins have all lost access has nobody who can manage it. Two owners, each with their Emergency Kit stored safely, is the minimum.

Apply the same check to every outside account on the list: a second owner on the code host, a group mailbox as the cloud root email, a registrar account that isn't tied to one person's phone.

Step 1: remove them from the vault and change its keys

In Crunu, removing an admin or owner runs the same Member removal wizard as for anyone else, with one more consequence. Because the person knew the organization's signing and recovery keys, the wizard moves the organization to a new key generation: new organization keys, every member's and machine's certificate reissued, and a new key for every shared environment. The rotation runs in the browser of the owner doing it, so the page stays open until it finishes; anything left over appears in Pending actions (offboarding a teammate).

What that achieves:

  • The server stops serving them anything in the organization at once.
  • A new signed revocation list means agents and apps stop accepting signatures they make after the removal. Signatures they made before stay valid, or old versions couldn't be read.
  • Their old organization keys sign nothing the new generation accepts. Each member's own pin of the organization's keys is updated the next time they sign in, by their own signature.
  • New environment keys mean that ciphertext they might obtain later opens nothing new.
Example. Kiteline is a fictional company.

The wizard also shows what they could have carried away, such as service tokens they created, machines whose enrollment code they may have kept, invitations and share links, and lets you revoke each. For an admin that list can be longer than for anyone else. Revoke all of it unless you know a token is in use and was never in their hands, and then still plan to replace it.

If you host the Crunu server yourself and they had access to its hosting or its .env, rotate the server key as well (rotate the server key).

Step 2: take over the accounts that can recover or re-grant access

These are the accounts where the person could get back in through a side door: a password reset, a second factor, a support call.

  • Cloud root and organization admin accounts. AWS recommends "a group email address for root user credentials", so that messages reach someone "even if individuals are on vacation, out sick, or have left the business", and "multi-person approval to make sure that no one person can access both MFA and password for the root user" (AWS IAM: root user best practices). If the departing admin knew the root password or held an MFA device, change the password and replace the device. Check the recovery phone number too.
  • Domain registrar and DNS. Whoever controls DNS can redirect mail, including password resets for every other account, and can get TLS certificates for your names. Change the account password, its second factor and its contact email.
  • Identity provider and code host. Remove owner rights, then check for personal access tokens, deploy keys and OAuth apps they authorized for the organization.
  • Signing keys. Release signing keys, package registry tokens and SSH certificate authorities they could read are values like any other, with a wider blast radius: they let someone publish in your name.
  • Billing and support. A billing contact can sometimes open support cases that end in account recovery. Update contacts.

Step 3: review what they changed recently

A departing admin's last weeks deserve a read, not because of suspicion, but because changes made in a hurry before leaving are easy to miss. Look for things that grant access later:

  • In the vault. Filter the audit log by that person: access granted, access profiles changed, service tokens created, machines enrolled, network rules relaxed, alert channels edited. Run the integrity check on the log's hash chain first, so you know the record is complete.
  • In the clouds. New IAM roles or changed trust policies, especially OIDC trust policies that accept a repository or branch you don't recognize. A trust policy is a quiet way to keep access without any key.
  • On the code host. New deploy keys, webhooks, and changes to branch protection.

Crunu adds one guard here: relaxing a network rule doesn't take effect for 15 minutes, raises an alert and can be canceled, unless a second person signs it. A rule can't be opened silently on the way out.

Step 4: reissue the values they saw

This is the same work as for any member, possibly with a longer list. The wizard's exposure report shows which versions of which environments the server gave them, and the reissue checklist lists the values that are still in use, by name and path only. Reissue at each provider, save the new value, and tick it off. Who saw which secret? explains how that report is built.

Example. Kiteline is a fictional company.

Until a value is reissued at its provider, the former admin can still use it. Rotation inside the vault closes new versions, not old knowledge.

What stays manual

  • Crunu doesn't manage access in other systems. The accounts in step 2 are yours to change.
  • It doesn't reissue values at providers. It tells you which ones to reissue.
  • It can't remove what someone has already seen.
  • It can't tell you about accounts nobody wrote down. Keep a list of admin-only accounts while everyone is still here; the offboarding checklist generator is a starting point, and the glossary entries on break-glass access and digital signatures explain two of the terms above.

Checklist

Sources

Terms in this post