Claiming a deployment

A fresh node has no accounts on it. Claiming is what makes the first one, and it is an act by whoever runs the machine rather than something a stranger can do over the network.

Why it works this way

A node reachable on a network with no accounts yet is the one moment a deployment is genuinely open. If the first account could be created over HTTP, whoever reached the port first would own the deployment. So the first account is created on the machine, by someone who already has a shell on it, and every account after that is created by invitation from inside.

There is no bootstrap password, no default account, and no setup wizard listening on the port.

Claim it

automaton identity claim -data /var/lib/automaton -email you@example.com

That prints a link. Open it, finish setting up how you sign in, and you have an owner account with an organization and a project under it. The owner holds the admin role, which is what lets that first person invite everyone else. Roles is the full model.

The link is single use and it expires. Claim a node when you are ready to finish the claim, not hours before.

Mint the first key

Keys are minted on the command line, never over the network, so there is no bootstrap credential for anyone to find:

automaton apikey create -data /var/lib/automaton -project acme -role agent

The plaintext is printed once and never stored. Mint a second key with -role approver and keep it where a person uses it rather than where a program does. The split between the key that acts and the key that approves is enforced rather than suggested: an approver key never releases work its own key id submitted.

List and revoke are on the same command:

automaton apikey list   -data /var/lib/automaton
automaton apikey revoke -data /var/lib/automaton -id ak_...

-role takes any of the four: admin, agent, approver, viewer. It defaults to agent, which is the one an assistant holds.

What the first hour looks like

1. Claim the node and finish the sign-in setup for the owner.
2. Mint an agent key for whatever will be calling atmon, and an approver key for the person who answers approvals.
3. Register the sign-in applications for the apps you intend to connect (First boot).
4. Configure a real mail driver, because everything below this line involves a second person and a second person needs email that arrives.
5. Invite your administrators, set -signup to match how you want accounts made, and read Hardening before the node faces anything wider than your own network.