SECURITYATLAS✳

✳ The reference desk / In practice

Secrets management

Storing, rotating, and auditing passwords, keys, and tokens so they are not copied into chat or source.

What it means

A secret is information whose possession can grant access or enable a sensitive operation: a password, private key, application programming interface (API) token, or signing credential. Managing secrets covers their whole lifecycle, from creation and distribution to use, rotation, revocation, and disposal. A dedicated store can centralize access controls and audit records, but applications still need a secure way to obtain secrets and handle them in memory. Short-lived workload credentials can reduce reliance on long-lived copied keys. Ownership matters because an unexplained credential is difficult to rotate safely when an incident occurs.

See the idea / Data

Changing the store is not revoking a credential.

Compare issuer revocation with a store-only update after the replacement works.

Synthetic SecretShelf supplies W161’s scoped CarrierDesk label-preview credential. K161 initially works and is held by W161. Nora’s authorized rotation creates K162 at the issuer and makes it current in the store. W161 retrieves and tests the replacement. Compare revoking K161 at CarrierDesk with leaving that issuer step undone. No real secret or shipment is used.

Secrets management: Compare issuer revocation with a store-only update after the replacement works. The chapter text below describes every state.CarrierDesk · scoped key rotationKey IDs shown; no credential valuesCarrierDesk · issuer validityK161 accepted · K162 absentC161 preview · original retainedSecretShelf · current versionCurrent: K161W161 may retrieve this secretW161 · locally held copyW161 holds K161W162 has no retrieval grantNora · independent key checksRotation probes not runAudit keeps IDs, never valuesSTORE ACCESS ≠ ISSUER VALIDITY

01 / 04

Retain scope

K161 works for C161 label preview. SecretShelf permits W161 to retrieve this one secret; another workload has no retrieval grant.

More about this step

CarrierDesk validates credentials for this selected C161 preview scope. SecretShelf separately authorizes W161’s retrieval through its configured identity. W162 has no such grant. K161 is initially active, current in the store and held by W161. Nora may rotate the selected issuer credential. Protected delivery and safe handling in memory are assumed; no secret value appears in the figure or audit.

Keep in mindK161/K162 label test credentials; values are never displayed or logged. Authenticated workload/rotation identities and protected delivery are exercise assumptions. Updating the store cannot invalidate an already-copied issuer credential. This checks one preview scope, not all consumers, earlier disclosure, sessions derived from credentials, issuer outages or incident recovery.

Read the visual, step by step

Revoke at issuer

  1. Retain scope. K161 works for C161 label preview. SecretShelf permits W161 to retrieve this one secret; another workload has no retrieval grant. CarrierDesk validates credentials for this selected C161 preview scope. SecretShelf separately authorizes W161’s retrieval through its configured identity. W162 has no such grant. K161 is initially active, current in the store and held by W161. Nora may rotate the selected issuer credential. Protected delivery and safe handling in memory are assumed; no secret value appears in the figure or audit.
  2. Replace. Nora creates K162 at CarrierDesk and publishes it as current in SecretShelf. K161 still works; W161 has not refreshed its copy. This selected rotation batch creates a distinct K162 credential with the same limited preview permission, then publishes it in SecretShelf. Both steps must succeed before the new state appears. The store pointer changes, not the issuer’s acceptance of K161 or the workload’s local copy. K161/K162 and rotation metadata remain as correlation records; their actual values are synthetic and omitted.
  3. Retrieve + test. Authorized W161 retrieves K162, then a fresh CarrierDesk preview test succeeds. K161 is still valid at the issuer. W161 receives the current value through its authorized retrieval path before testing it against CarrierDesk. The selected batch combines retrieval and the replacement test; it does not treat a vault response alone as issuer success. The C161 preview returns 200 using K162. Unrelated W162 is denied retrieval. Audit records retain actor, credential reference and result, never either credential value.
  4. Revoke + probe. Nora revokes K161 at CarrierDesk. Fresh tests refuse the held old value and permit K162’s preview. After K162’s successful test, the primary batch revokes K161 at its issuer and independently tests both held values. It observes old 401 with no preview and new 200. The comparison leaves issuer revocation undone and observes old 200 and new 200. SecretShelf and W161 hold K162 in both. The original C161 record remains unchanged; these are preview reads, not shipment creation or delivery. Wider consumer and incident work is separate.

Store update only

  1. Retain scope. K161 works for C161 label preview. SecretShelf permits W161 to retrieve this one secret; another workload has no retrieval grant. CarrierDesk validates credentials for this selected C161 preview scope. SecretShelf separately authorizes W161’s retrieval through its configured identity. W162 has no such grant. K161 is initially active, current in the store and held by W161. Nora may rotate the selected issuer credential. Protected delivery and safe handling in memory are assumed; no secret value appears in the figure or audit.
  2. Replace. Nora creates K162 at CarrierDesk and publishes it as current in SecretShelf. K161 still works; W161 has not refreshed its copy. This selected rotation batch creates a distinct K162 credential with the same limited preview permission, then publishes it in SecretShelf. Both steps must succeed before the new state appears. The store pointer changes, not the issuer’s acceptance of K161 or the workload’s local copy. K161/K162 and rotation metadata remain as correlation records; their actual values are synthetic and omitted.
  3. Retrieve + test. Authorized W161 retrieves K162, then a fresh CarrierDesk preview test succeeds. K161 is still valid at the issuer. W161 receives the current value through its authorized retrieval path before testing it against CarrierDesk. The selected batch combines retrieval and the replacement test; it does not treat a vault response alone as issuer success. The C161 preview returns 200 using K162. Unrelated W162 is denied retrieval. Audit records retain actor, credential reference and result, never either credential value.
  4. Revoke + probe. K161 is not revoked at CarrierDesk. Fresh tests still permit both values, despite K162 being current in the store. After K162’s successful test, the primary batch revokes K161 at its issuer and independently tests both held values. It observes old 401 with no preview and new 200. The comparison leaves issuer revocation undone and observes old 200 and new 200. SecretShelf and W161 hold K162 in both. The original C161 record remains unchanged; these are preview reads, not shipment creation or delivery. Wider consumer and incident work is separate.

K161/K162 label test credentials; values are never displayed or logged. Authenticated workload/rotation identities and protected delivery are exercise assumptions. Updating the store cannot invalidate an already-copied issuer credential. This checks one preview scope, not all consumers, earlier disclosure, sessions derived from credentials, issuer outages or incident recovery.

Flow references: OWASP: secret lifecycle, access and revocation

AN ILLUSTRATIVE SCENARIO

Current in the store, still valid at the issuer

Nora creates K162 at CarrierDesk and makes it current in SecretShelf. Authorized W161 retrieves it and a label-preview test succeeds. Only issuer revocation makes a held K161 value fail a fresh check. A store-only update leaves both credentials usable at CarrierDesk. Values are neither displayed nor logged, and the unchanged C161 record is synthetic.

Put it to work

  1. Inventory application and administrative secrets, including their owners, permissions, consumers, and expiry. Prioritize credentials embedded in code, shared documents, build output, or manual deployment notes.
  2. Use an approved store and workload identity where possible. Limit retrieval to the necessary application and people, protect delivery, and prevent secret values from appearing in logs or support tickets.
  3. Practice rotation and emergency revocation, including dependent services and rollback constraints. When a secret is exposed, replace and revoke it; removing the visible copy does not invalidate copies already taken.

How to check your work

Using test credentials, confirm an authorized workload can retrieve only its own secret, an unrelated workload is denied, and the old value stops working after rotation. Check that audit records explain access without containing the credential itself.

Connect the ideas

  • Least privilege

    Granting each identity only the actions, objects, and time window required for the current job.

  • Encryption

    Transforming data so only holders of the appropriate key can read it, protecting confidentiality in transit or at rest.

  • Blast radius

    How much additional loss a failure or a response action can cause beyond the original asset.

Explore a field lesson

Find your next idea.

Tip: press / to open search. Escape closes this window.