[FEATURE] Rotate Root Endpoint

[stuartpurgavie]

Rotate Root Endpoint

Introduction

Hello,

This is simply a request to allow Vault to rotate its own configuration secret and ensure that Vault is the only entity that knows the credential it uses to do management. This would rely on a user token credential being provided to the configuration endpoint.

Optionally, this could implement a fully-managed parameter, false by default, on the existing terraform/config endpoint. When true, this parameter would help ensure that Vault is the only entity leveraging the User account by deleting extraneous, unknown, or unmanaged tokens that exist in the service account context.

Minimum Requirements

At a high level, this will need to:

• List Tokens from User API
  • If this is not successful, it can be assumed that the token is not a User token (Fail scenario)
• Identify currently leveraged token from the list
• Identify any tokens that have active leases associated with roles in the engine
• Optionally, delete all other tokens (if fully-managed parameter is true)
• Optionally, rotate account password as well (again, if fully-managed parameter is true)
• Create a new User token
• Attempt an API action leveraging the new User token, and wait until successful
• Store new token in engine configuration
• Revoke old token

Mid-level design

Based on current documentation, it seems reasonable to assume the following pattern:

• Add a new endpoint to the engine at /terraform/rotate-root
• Require that a User token be leveraged by the /terraform/config endpoint in documentation
• Suggested parameters might be:
  • nil (no parameters required)
• OPTIONAL: If wishing to implement the fully-managed parameter against the terraform/config endpoint
  • boolean parameter with a default of false
  • if true, affects the operation of the terraform/rotate-root endpoint
  • Adds evaluation of all tokens in the User API
  • If any tokens are found that are not managed by the engine, they are deleted
  • Rotate the User password
• Create a new User token
• Test the new User token
• Store the new User token in the engine configuration
• Revoke the old User token
• Return success 204

Closing comments

I like the idea of a "fully-managed" parameter, but probably unnecessary for an MVP of this feature.

Could theoretically add something to also rotate the TOTP for the user account, but as that would involve mounting a TOTP engine and integrating with it, I'm not sure it's worth the effort. If you did this, it should also be part of the fully-managed flag, as you wouldn't want to be locked out of an account that is meant to allow someone to interactively log in.