Una clave aparte para la automatización en lugar de compartir una contraseña: los tokens y sus límites

Darle una contraseña a un script escribe en un archivo todo lo que esa persona posee. Un token es una clave aparte: se revoca sola, tiene fecha de fin y puede llevar menos autoridad que la cuenta.

AtlasPVE ·

Esta entrada responde a

  • proxmox crear token api
  • proxmox compartir contraseña para automatización
  • proxmox permisos del token api
  • proxmox separación de privilegios del token
  • proxmox acceso terraform ansible

Un script de copias, una herramienta de supervisión o una tarea de aprovisionamiento tiene que conectarse al sistema. El primer reflejo es darle una contraseña, y casi siempre la de la cuenta con más privilegios. Ahí empiezan los problemas.

Qué entrega una contraseña entregada

Una contraseña pertenece a una persona. Cuando se la das a un script le has dado todo lo que esa persona tiene, y además en texto claro dentro de un archivo. Cuando la contraseña cambia la automatización se detiene, y cuando la persona se va se cambia la contraseña, pero que la automatización dependía de ella se recuerda casi siempre ese mismo día.

Qué hace un token

Un token es una clave aparte ligada a una cuenta. Separa tres cosas: se revoca sola, puede llevar su propia fecha de fin, y como tiene nombre se sabe qué trabajo lo usa. Poder apagar una automatización sin cambiar una contraseña parece un detalle; a medida que el montaje crece resulta ser lo más útil.

La pregunta real: qué puede hacer el token

El ajuste más importante de un token es si lleva la autoridad de la cuenta tal cual. Si la lleva, el token es tan poderoso como su dueño. Si el dueño tiene todos los privilegios, el token también, y ahora vive dentro de un archivo en alguna máquina.

Con la separación activa, el token solo tiene la autoridad concedida al propio token. A un script de copias le das lo justo para hacer copias, y aunque ese script quede comprometido, eso es todo lo que se va. Elige por defecto el lado estrecho y abre el ancho solo a propósito.

El secreto se muestra una vez

Al crear un token ves su secreto una vez. No es un capricho de la interfaz: el sistema no guarda ese valor en forma legible. Si lo pierdes creas uno nuevo, y ese es el comportamiento correcto. Si pudiera releerse en algún sitio, ese sería el problema de verdad.

Dónde acaba viviendo la clave

Dónde está la clave importa más que lo fuerte que sea. Un script subido a un repositorio, una configuración que entró en un archivo de copia, una ventana capturada en una imagen de pantalla: todos llevan la clave. Decide dónde se va a escribir antes de crearla.

Fecha de fin y renovación

Una clave con fecha de fin deja de ser un riesgo algún día aunque nadie se ocupe. Una sin fecha vive años y suele sobrevivir a quien la creó. Pon una nota en cada clave: qué trabajo la usa, quién responde de ella.

Qué hace Atlas

Atlas gestiona los tokens por cuenta. Al crear uno, mantener la autoridad del token separada de la de la cuenta viene activado por defecto: el lado estrecho es el punto de partida y ampliarlo es un paso consciente. El secreto se muestra una vez en el momento de la creación y no se guarda en el panel. Los tokens existentes se listan con su nota y su fecha de fin, de modo que la pregunta "qué automatización de esta máquina se conecta con qué clave" se responde leyendo.

Fuentes

La documentación oficial de Proxmox. En inglés, y en este asunto es ella la que tiene la última palabra.

Entradas relacionadas

¿Cómo se ve esto dentro de Atlas?

Ir a la página del producto