Skip to main content

Tenants & API Keys

Administration → Tenants & API Keys is the platform-administration surface of Beak Hub. It registers the tenants permitted to use the Hub and manages the API keys their services authenticate with. The page description reads "Register tenants and manage the API keys their services use to authenticate with Hub."

Everything else in Hub is a catalogue that people browse. This is the only page that decides who may call Hub at all.

Access​

This page requires the platform admin role. Operators without it see Admin access required, explaining that the role is needed and to ask an administrator. Tenant-level Hub users never see it, which is intended — issuing a Hub credential is a platform action, not a tenant one.

Registering a tenant​

Register tenant records a tenant against the Hub with a display name, for example Acme Corp. The tenant identifier can be assigned explicitly or left to auto-assign.

A tenant must be registered before any key can be issued to it. Until at least one exists, the page shows No tenants registered with the explanation that registering one is how key issuance starts.

Issuing an API key​

Keys are minted per tenant and given a name describing what will use them — Runtime deploy key or CI pipeline, for example. The name is the only thing distinguishing one key from another later, so it is worth writing for the person who will read it in six months rather than for yourself today.

Note: The key value is shown when it is minted and is not retrievable afterwards. Capture it at that moment; if it is lost, revoke it and mint a replacement rather than trying to recover it.

The key list​

Each tenant's keys are listed with:

  • Name — What the key was issued for.
  • Prefix — The leading characters of the key, enough to match a key in a log or a configuration file against this row without exposing the secret.
  • Status — Whether the key is currently valid.
  • Created — When it was issued.
  • Last used — When it last authenticated. This is the column that identifies keys nobody needs any more.
  • Actions — Revocation.

A tenant with no keys shows No API keys yet.

Revoking a key​

Revocation asks for confirmation (Revoke API key?) because it takes effect immediately and cannot be undone. Any service still presenting that key stops being able to reach Hub at once — so revoke during a change window unless you are responding to an incident, where immediate is the point.

Best Practices​

  • Name keys after the consumer, not the person — CI pipeline survives a change of owner; Priya's key does not.
  • Issue one key per consuming service — A shared key cannot be revoked without taking down everything that shares it, which in practice means it never gets revoked.
  • Use Last used as the retirement signal — A key that has not authenticated in months is either dead or a credential nobody is watching. Both are reasons to revoke.
  • Record the key value at mint time — It is not recoverable afterwards.
  • Keep the platform admin role narrow — It is the role that decides which tenants can reach Hub at all.