Why
The local and remote admin CLIs can create a bot account with
account create --bot --key ... --role ..., but the browser accounts page can
only create a person by issuing an enrollment link. An instance admin who is
already in the web UI has to drop to a shell and hold the config file or an admin
key just to set up an automation account.
Bots have no browser sign-in, so the enrollment-link path is not just missing but wrong for them: their first credential is an SSH public key, and they cannot hold the instance-admin role.
Scope
- Add a “Create a bot account” form to the instance Accounts page.
- Collect a name, an SSH public key, and an instance role.
- Do not offer
adminfor a bot; the identity layer already refuses it. - Reuse
identity.Store.CreateBot, so the same validation and audit line are used as the CLI. - Mark bots on the accounts list and account detail page.
- Hide the enrollment-link action and remove
adminfrom the role picker on a bot’s account page. - Update the accounts page copy so it names both paths.
- Document that the web UI can create a bot.
Acceptance criteria
- An instance admin can create a bot from
/usersand is sent to its account page, where the key is listed. - A bot created that way has kind
bot, the chosen role, and the pasted key. - The form refuses a missing key, an invalid name, and the
adminrole, and creates nothing in each case. - A non-admin cannot reach the create-bot route.
- A bot’s account page does not offer an enrollment link or the
adminrole. - The relevant Go tests pass, and
vole workflow checkpasses.