Use Proxmox API tokens as delegated identities with a visible owner
Proxmox VE automation often begins with a user's password and ends with a long-lived API token stored in a script. The token is not a separate account with its own independent rights. Its permissions are a subset of the backing user's permissions. That relationship is the key to reviewing it safely.
The token inherits a ceiling
Proxmox documentation states that API token permissions are always a subset of those of the corresponding user. A token cannot perform a task the backing user cannot perform. This gives the organization a useful ceiling, but it does not guarantee the token is narrow. A token belonging to an administrator remains an administrative path unless its ACLs and privilege settings narrow it.
Review the backing user's group membership and the ACLs on the token. Then review the ACL paths the token can reach. A token for backups may need access to a storage path and a VM pool, while a monitoring token may need read-only status information. A token with permission on / is a broad control surface regardless of its display name.
Separate human login from machine identity
Human accounts change roles, leave the organization, or require interactive login factors. A machine token tied to a human account can become difficult to audit after the person moves teams. Prefer a dedicated automation identity with a clear owner and a documented purpose. If the deployment requires a backing user, make that user non-interactive where possible and restrict its scope.
Treat token creation as an administrative event. The secret should be delivered once through a protected channel and stored in a secret manager. Avoid putting it in command history, repository files, or deployment logs. Record the token identifier, owner, creation time, and intended systems. The secret itself should not be copied into tickets or chat.
Test effective permissions
The ACL view is not enough. Test the token against the API operations the automation uses and against operations it should not use. Include a VM outside the intended pool, a storage operation, a user-management endpoint, and a cluster-wide action. Confirm that the denials are authorization decisions.
Test the backing user's permissions separately. If the user is later granted a broader role, the token's effective access can change without any token rotation. Alert on privilege changes to backing users and group membership. Review token ACLs when the role model changes, not only when the automation script changes.
Monitor and retire
Use distinct tokens per automation when the platform supports it. A shared token obscures which system performed an action and makes rotation risky. If one consumer is compromised, a distinct token can be revoked without breaking every integration.
Check whether the token has an expiration option in the deployed version and use it where the workflow permits. For long-lived tokens, maintain a rotation schedule and an emergency revocation path. Remove tokens belonging to retired jobs. A token that no longer appears in current automation may still be accepted by the API.
Proxmox's permission model makes delegation possible. The security value comes from preserving the owner relationship and testing the effective boundary. A token is only as trustworthy as the identity behind it and the ACLs in front of it.
Top comments (0)