The initial root token from operator init, generating one with a quorum of key holders, using it only for set-up and emergencies, and revoking it afterwards.
Study it
Root tokens: initial set-up, generate-root and revocation
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
After initial set-up the team revoked the initial root token. Months later, a bad policy change locks every administrator out of sys/policy. The cluster uses Shamir unseal keys held by five officers, with a threshold of three. How does the team obtain a root token?
ARun vault operator init again to get a fresh root token
BRun vault operator generate-root and have three key holders enter their unseal keys
CRun vault token create -policy=root with an administrator's token
DRestart the cluster, because a root token is printed once the unseal keys are entered again
Show the answer and why
ARun vault operator init again to get a fresh root token
Incorrect
Initialization happens once per cluster; an initialized Vault does not issue a new root token through init.
BRun vault operator generate-root and have three key holders enter their unseal keys
Correct
generate-root creates a root token once a quorum of unseal key holders authorizes it.
CRun vault token create -policy=root with an administrator's token
Incorrect
Only an existing root token can create a root token, and the administrators' tokens are not root.
DRestart the cluster, because a root token is printed once the unseal keys are entered again
Incorrect
Unsealing prints no token; restarting only makes every node sealed again.
generate-root needs a quorum of unseal key holders, which keeps the creation of root access under shared control.
An operator has finished the initial set-up of a new cluster while logged in with the initial root token, which is now the CLI's current token. She must revoke it before handing over, without pasting its value into any command. Which command does it?
Avault policy delete root
Bvault operator seal
Cvault token revoke -self
Dvault token renew -increment=0
Show the answer and why
Avault policy delete root
Incorrect
Deleting a policy changes what the tokens that carry it may do; it never revokes a token.
Bvault operator seal
Incorrect
Sealing makes the node stop serving requests until it is unsealed; it revokes no token.
Cvault token revoke -self
Correct
-self revokes the token the command authenticates with, here the root token.
Dvault token renew -increment=0
Incorrect
Renewal adjusts a token's TTL; it never revokes the token.
With -self, vault token revoke acts on the token the CLI is using, so the value never has to be typed or pasted.
Integration tests start a throwaway Vault dev server on every run and must know its root token in advance instead of reading a random value from the server's output. How is that done?
AExport VAULT_TOKEN=root in the shell before starting the server
BRun vault operator init against the dev server with the chosen value
CCreate one after start with vault token create -policy=root -orphan
DStart it with vault server -dev -dev-root-token-id=root
Show the answer and why
AExport VAULT_TOKEN=root in the shell before starting the server
Incorrect
VAULT_TOKEN sets the token the CLI sends; it does not choose the server's initial root token.
BRun vault operator init against the dev server with the chosen value
Incorrect
A dev server is initialized for you, and init has no option that chooses the root token's value.
CCreate one after start with vault token create -policy=root -orphan
Incorrect
The new token would still get a random value, and creating it needs the printed root token first.
DStart it with vault server -dev -dev-root-token-id=root
Correct
-dev-root-token-id sets the dev server's initial root token, here the literal string root.
Root tokens belong in development and in emergencies. -dev-root-token-id, or VAULT_DEV_ROOT_TOKEN_ID, applies only in dev mode, which must never run in production.