A separate key for automation instead of sharing a password: tokens and their limits
Giving a script a password writes everything that person owns into a file. A token is a separate key: it can be revoked on its own, given an end date, and held to less authority than the account.
AtlasPVE ·
This entry answers
- proxmox create api token
- proxmox sharing password for automation
- proxmox api token permissions
- what is proxmox token privilege separation
- proxmox terraform ansible access
A backup script, a monitoring tool or a provisioning job has to connect to the system. The first reflex is to hand it a password, and usually the password of the most privileged account. That is where the trouble starts.
What handing over a password hands over
A password belongs to a person. When you give a script a password you have given it everything that person holds, and in plain text in a file at that. When the password changes the automation stops, and when the person leaves the password is changed, but the fact that automation depended on it is usually remembered on that same day.
What a token does
A token is a separate key tied to an account. It separates three things: it can be revoked on its own, it can carry its own end date, and because it has a name you know which job uses it. Being able to switch off one automation without changing a password looks like a small detail; as the setup grows it turns out to be the most useful one.
The real question: what the token is allowed to do
The most important setting on a token is whether it carries the account's authority as it stands. If it does, the token is as powerful as its owner. If the owner is fully privileged then so is the token, and it now lives inside a file on some machine.
With the separation on, the token holds only the authority granted to the token itself. You give a backup script just enough to take backups, and even if that script is compromised, that is all that is taken. Choose the narrow side by default and open the wide side only deliberately.
The secret is shown once
When a token is created you see its secret once. This is not an interface quirk: the system does not keep that value in readable form. If you lose it you create a new one, and that is the correct behaviour. If it could be read back somewhere, that would be the real problem.
Where the key ends up living
Where the key sits matters more than how strong it is. A script committed to a repository, a configuration that ended up inside a backup file, a window caught in a screenshot: all of them carry the key. Decide where it will be written before you create it.
End dates and rotation
A key with an end date stops being a risk one day even if nobody attends to it. A key without one lives for years and usually outlasts whoever created it. Put a note on every key: which job uses it, who owns it.
What Atlas does
Atlas manages tokens per account. When you create one, keeping the token's authority separate from the account is on by default, so the narrow side is the starting point and widening it is a deliberate step. The secret is shown once at the moment of creation and is not kept in the panel. Existing tokens are listed with their note and end date, so the question "which automation on this machine connects with which key" is answered by reading.
Sources
Proxmox's own documentation. In English, and it has the final word on this subject.