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?
AEach token's entity ID, passed to vault token revoke when the job ends
BA response-wrapped copy of each token, unwrapped and revoked when the job ends
CEach token's accessor, revoked at job end with vault token revoke -accessor
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.
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?
AHash the accessor through sys/audit-hash and search for the result
BRun vault token lookup -accessor, which lists the token's audit entries
CSearch for the token value instead, which the audit log keeps in clear text
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.
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?
ANothing is needed, because accessors are always written in clear text
BSet hmac_accessor=false on the device; log readers could then revoke tokens
CEnable the device with log_raw=true, which writes only the accessors unhashed
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.