Skip to content
PulsVaultDocs
Get started
Solo ProTeamBusinessEnterprise

Re-scope & settings

Changing what a live key may do, and where and how long it may be used — without re-issuing the credential.

Everything about a key except the token itself can be changed while it is live. The credential in your CI keeps working: no redeploy, no overlap window, no coordination with whoever owns the pipeline.

Two separate actions on the Credentials tab, because they answer different questions:

Action Changes Reach for it when
Re-scope which permissions this key holds the key can do more than its job needs
Settings IP allowlist · rate limit · lifetime where and how long the key may be used
Why this beats revoke-and-re-issue

Before these existed, tightening anything on a running key meant issuing a new one, deploying it and revoking the old — a change to one CIDR cost a full rotation, so in practice nobody did it. Leaving the token untouched is what makes tightening cheap enough to actually happen.

Both are audited at high severity, and a settings change records the before and after — a fence going up and a fence coming down are indistinguishable otherwise.

Re-scope: the ceiling-and-narrow model#

The machine identity holds the permissions — that is the ceiling. Each key may hold the whole ceiling or any subset of it, and never anything outside it.

text
identity  "deploy-web"     read prod/**  ·  write prod/web/**  ·  list prod/**
   ├── key pv_live_a3f9…   (inherits everything — the default)
   └── key pv_live_77c2…   (limited: read prod/** only)

Two modes in the dialog:

  • Full access — the key holds whatever the machine holds, now and in future. Attach a permission to the identity and this key picks it up immediately.
  • Limited — the key holds exactly the policies you tick. A read-only preset selects the policies whose actions are only read and list.

Selecting nothing is not offered. A key with no permissions is not a safety measure, it is an inert credential that still authenticates; express "this machine may do nothing" by detaching permissions from the identity.

A limited key does not pick up new permissions

Attach a permission to the identity and every inheriting key gains it at once — but a limited key keeps the exact subset it was given. This is the single most common "my change didn't take": the permission is attached, the pipeline still gets a 403, and nothing looks wrong. The Permissions tab says so explicitly when limited keys are missing something; re-scope them from the Credentials tab.

Re-scoping is refused if you name a policy the machine does not hold. A key cannot be used as a side door to widen a machine — attach the policy to the identity first, then narrow the key to it.

Settings: the network envelope#

Field Leave it blank to Clear it by
IP allowlist keep the current list removing every row — the key becomes reachable from anywhere
Rate limit keep the current limit emptying it — falls back to the 100/min default
Lifetime keep the current expiry not possible — every key keeps an expiry

Clearing is always said explicitly. On a security control the difference between "I did not mention it" and "remove it" must never be a guess, so an empty allowlist is a deliberate "reachable from anywhere" and an empty field is "leave it alone".

The lifetime is a duration, not a date#

You give a number of days from now, and the server computes the instant. It may land earlier or later than the current expiry — both are allowed.

  • Shortening to nothing is not. A lifetime under a day is refused: ending a key now is revocation, and doing it here would leave the audit trail describing a kill as a settings tweak.
  • Removing the expiry is not. See API keys.

The server owns the clock deliberately. When the browser computed the expiry itself, it did the arithmetic in its own timezone against a server comparing in another — every key on a deployment outside UTC expired an offset early.

A revoked key cannot be changed#

Both actions return a conflict on a revoked key. Revocation is final by design; there is no un-revoke, because a credential that can come back is one you can never confidently say was stopped.

Was this page helpful?