Skip to content

003 · Domain 3: Vault tokens · 15% of the exam

Task 3.3: Explain the purpose of token accessors

A reference that can look up, renew and revoke a token or check its capabilities without revealing it, and how to list and use accessors.

Study it

  • Token accessors: look up, renew and revoke without the token

    Lesson coming

Sample questions

Try each one before opening the answer. Every option is explained, with the HashiCorp documentation page that proves it.

Question 1 · choose 1

A job scheduler creates a Vault token for each job and hands the token to the job. The scheduler must be able to revoke a job's token, together with everything leased under it, as soon as the job ends, but it must not retain the token values themselves. What should the scheduler keep, and how does it revoke?

  1. AEach token's entity ID, passed to vault token revoke when the job ends
  2. BA response-wrapped copy of each token, unwrapped and revoked when the job ends
  3. CEach token's accessor, revoked at job end with vault token revoke -accessor
  4. DEach token's accessor, revoked with vault lease revoke -prefix and the accessor
Show the answer and why
  • AEach token's entity ID, passed to vault token revoke when the job ends

    Incorrect

    Tokens created by the token store usually have no entity, and token revoke takes a token or an accessor, not an entity ID.

  • BA response-wrapped copy of each token, unwrapped and revoked when the job ends

    Incorrect

    Unwrapping yields the token value, so the scheduler would hold the very secret it must not keep.

  • CEach token's accessor, revoked at job end with vault token revoke -accessor

    Correct

    An accessor references a token without revealing it and can be used to revoke it; revoking a token also revokes its leases.

  • DEach token's accessor, revoked with vault lease revoke -prefix and the accessor

    Incorrect

    lease revoke takes lease IDs or their prefix, not token accessors.

The scheduler acts on each job token through a reference and never holds the token itself.

Question 2 · choose 1

During an incident review an operator needs a list of the currently active service tokens. How is that done?

  1. AList auth/token/lookup, which returns every token ID
  2. BRead sys/leases/lookup/auth, which returns the tokens behind each lease
  3. CLIST on auth/token/accessors, a root-protected endpoint
  4. DRun vault token lookup without arguments, which lists all tokens
Show the answer and why
  • AList auth/token/lookup, which returns every token ID

    Incorrect

    Token IDs are never listed; only accessors are.

  • BRead sys/leases/lookup/auth, which returns the tokens behind each lease

    Incorrect

    Lease lookup lists lease IDs, not a listing of tokens.

  • CLIST on auth/token/accessors, a root-protected endpoint

    Correct

    Listing accessors is the only way to list tokens, and the endpoint is root-protected.

  • DRun vault token lookup without arguments, which lists all tokens

    Incorrect

    Without arguments it looks up the current token only.

Listing accessors is the closest Vault comes to listing tokens, which is why the endpoint is root-protected.

Question 3 · choose 1

During an incident, responders know the accessor of a suspicious token and want to find every audit log entry where that token was used. The file audit device runs with its default settings. How do they search?

  1. AHash the accessor through sys/audit-hash and search for the result
  2. BRun vault token lookup -accessor, which lists the token's audit entries
  3. CSearch for the token value instead, which the audit log keeps in clear text
  4. DSearch the log for the accessor exactly as it is written down
Show the answer and why
  • AHash the accessor through sys/audit-hash and search for the result

    Correct

    sys/audit-hash computes the HMAC with that device's salt, which matches the hashed accessor in its entries.

  • BRun vault token lookup -accessor, which lists the token's audit entries

    Incorrect

    Token lookups return a token's properties; Vault keeps no per-token index of audit entries.

  • CSearch for the token value instead, which the audit log keeps in clear text

    Incorrect

    Tokens and other sensitive strings are hashed in the audit log as well.

  • DSearch the log for the accessor exactly as it is written down

    Incorrect

    By default audit devices hash token accessors with HMAC-SHA256, so the plain accessor does not appear in the entries.

Audit devices HMAC most strings with a per-device salt; sys/audit-hash produces the same HMAC for any value, so responders can match entries without logging secrets in clear text.

Question 4 · choose 1

A cleanup job uses its own token to revoke other tokens by accessor. The revocations are denied. Whose permissions does Vault check?

  1. ANobody's, since accessor operations need no authorization
  2. BThe target token's, whose policies must allow its own revocation by accessor
  3. CBoth tokens', which must share a policy
  4. DThe calling token's, which needs rights on the accessor endpoints
Show the answer and why
  • ANobody's, since accessor operations need no authorization

    Incorrect

    Accessor operations are authorized like any other request.

  • BThe target token's, whose policies must allow its own revocation by accessor

    Incorrect

    The target token's policies are not consulted.

  • CBoth tokens', which must share a policy

    Incorrect

    Only the caller's permissions matter.

  • DThe calling token's, which needs rights on the accessor endpoints

    Correct

    The token making the call, not the token associated with the accessor, must have the permissions.

Vault authorizes accessor operations against the token that sends the request.

Question 5 · choose 1

The security team wants audit log entries to show token accessors in clear text, so that a suspicious token can be revoked straight from the log. What makes that possible, and what is the trade-off?

  1. ANothing is needed, because accessors are always written in clear text
  2. BSet hmac_accessor=false on the device; log readers could then revoke tokens
  3. CEnable the device with log_raw=true, which writes only the accessors unhashed
  4. DIt cannot be done, because accessors never appear in audit logs
Show the answer and why
  • ANothing is needed, because accessors are always written in clear text

    Incorrect

    By default hmac_accessor is true, so accessors are hashed.

  • BSet hmac_accessor=false on the device; log readers could then revoke tokens

    Correct

    Audit devices can skip hashing accessors, which helps emergency revocation but lets log readers mount a denial of service.

  • CEnable the device with log_raw=true, which writes only the accessors unhashed

    Incorrect

    log_raw writes all sensitive values unhashed, not just accessors.

  • DIt cannot be done, because accessors never appear in audit logs

    Incorrect

    Accessors appear in audit logs, hashed by default.

Clear-text accessors trade a faster response for a larger attack surface on the logs.

Practice domain 3 →Practice all domains →