Guardar secretos en Rundeck es algo que conviene hacer bien desde el principio. Cuando empiezas a probar jobs y automatizaciones, es muy fácil acabar dejando tokens, contraseñas o claves pegados en scripts o dentro del propio job, y luego eso se vuelve un lío.
En mi caso, antes de seguir con más despliegues, prefería dejar esta parte resuelta. La idea es sencilla: usar Key Storage de Rundeck para guardar esos secretos con algo de orden y no ir dejándolos en claro por cualquier parte. La propia documentación de Rundeck presenta Key Storage como el mecanismo para almacenar claves privadas, contraseñas y otros datos sensibles que luego pueden usar jobs, plugins o ejecutores.
Para un laboratorio pequeño o un homelab, con esto suele ser más que suficiente. No hace falta montar nada raro ni complicarse demasiado. Solo dejar bien guardados los secretos para que luego los jobs puedan usarlos sin tener que enseñar su valor en claro.
Requisitos para guardar secretos en Rundeck
Aquí doy por hecho que ya tienes Rundeck funcionando y que ya has dejado la parte base de conexión con Proxmox montada. Si todavía no has pasado por ese paso, aquí conté cómo instalar Rundeck en Proxmox dentro de un LXC.
La documentación oficial de Rundeck deja claro que Key Storage sirve para almacenar datos sensibles reutilizables en distintas partes de la plataforma y que esos datos pueden añadirse como fichero subido o como texto pegado directamente en la interfaz. También recomienda organizar las claves por proyecto para aislar mejor el acceso y que no termine todo mezclado a nivel global.
Arquitectura o escenario que voy a usar
Aquí sigo con el mismo montaje sencillo de los dos artículos anteriores. No voy a meter ni Vault, ni runners, ni varios proveedores de secretos. Solo un Rundeck en el lab y un proyecto que habla con Proxmox.
Red LAN: 192.168.10.0/24
Proxmox: 192.168.10.10
Rundeck LXC: 192.168.10.50
Proyecto en Rundeck: proxmox-lab
Secreto a guardar: token de API de ProxmoxPara este escenario, sinceramente, no hace falta complicarse más. Rundeck permite usar su backend interno para Key Storage y, si más adelante quieres dar un salto a un proveedor externo, también soporta plugins de almacenamiento para servicios como HashiCorp Vault, Azure Key Vault o AWS Secrets Manager. Pero para arrancar, el almacenamiento interno del propio Rundeck es más que suficiente.
Qué no haría yo
Lo primero que no haría sería dejar el token de Proxmox metido directamente dentro del script del job. Funciona, sí. Pero el día que cambies el token, tengas que reutilizarlo en otro job o quieras revisar qué usa cada cosa, te vas a acordar del invento.
Tampoco me gusta dejar secretos como opciones normales del job si no hace falta. Más aún porque Rundeck ha tenido recientemente una corrección de seguridad relacionada con el tratamiento de opciones de job usadas en comandos shell. No es exactamente el mismo problema que dejar un token en claro, pero sí sirve para recordar que mezclar opciones de usuario, shell y secretos en el mismo sitio no suele ser la idea más limpia.
Y la tercera cosa que intentaría evitar es guardar todo a nivel global sin orden ninguno. Rundeck recomienda organizar el almacenamiento por proyecto, y tiene sentido. En cuanto pasas de uno o dos jobs, la diferencia entre tener una estructura clara o tener cinco secretos con nombres improvisados se nota bastante.
Qué usaría yo en Rundeck
Yo aquí usaría directamente Key Storage a nivel de proyecto. Es el comportamiento recomendado por defecto en la documentación actual: cada proyecto puede tener su propio conjunto de claves y las ACL del proyecto controlan quién puede acceder a ellas. Eso te evita compartir secretos entre proyectos sin querer y deja todo mucho más fácil de entender cuando vuelvas dentro de un mes.
Además, la propia documentación de Rundeck recomienda una jerarquía por proyecto. En el manual aparece el patrón keys/project/[project-name]/[key-name], e incluso comenta que puedes añadir subdirectorios bajo esa ruta si el proyecto va creciendo y necesitas ordenar mejor claves, identidades o nodos.
Estructura sencilla para guardar secretos en Rundeck
Para este laboratorio yo no me complicaría. Si el proyecto se llama proxmox-lab, una ruta perfectamente razonable sería esta:
keys/project/proxmox-lab/api-tokenSi quieres dejarlo un poco más fino porque sabes que luego vas a guardar más cosas, puedes abrir algo así:
keys/project/proxmox-lab/proxmox/api-token
keys/project/proxmox-lab/proxmox/user
keys/project/proxmox-lab/proxmox/token-idLa diferencia entre una estructura y otra no es técnica. Es simplemente de orden. Lo importante es que, cuando vuelvas a Key Storage, puedas entender en cinco segundos qué guarda cada ruta y para qué proyecto sirve. El propio manual insiste en que la organización por proyecto ayuda a aislar acceso y a mantener recursos bien separados del contexto global.
Cómo añadir el secreto
Aquí Rundeck no tiene demasiado misterio. En la interfaz de Key Storage puedes añadir una clave o un secreto como texto o como archivo. Para un token de API lo normal es usar la opción de texto.
En la práctica, para este caso yo haría algo así. Entrar al proyecto, abrir Key Storage, crear la ruta del proyecto y guardar ahí el token de Proxmox como contraseña o valor sensible de texto. La documentación oficial muestra precisamente ese flujo y deja claro que el almacén funciona con rutas similares a un sistema de ficheros, algo que luego viene muy bien para ordenar por carpetas.
Cómo usar luego ese secreto en un job
La parte buena de hacer esto bien es que luego los jobs no necesitan llevar el secreto pegado encima. Lo razonable es que el job consuma la ruta del secreto y no el valor directamente.
Aquí no voy a entrar todavía en el job completo del despliegue, porque ese post lo quiero dejar para cuando tenga capturas buenas de Rundeck. Pero sí me interesa dejar clara la idea: el secreto queda guardado en Key Storage y el job lo referencia por su path, no por el valor en claro. Esa es la diferencia importante.
Además, Rundeck documenta que, en general, cuando existe una opción de configuración basada en key storage path, esa ruta tiene prioridad sobre el valor equivalente escrito directamente. Esto se ve muy claro en el caso de la ejecución por SSH, donde las claves y contraseñas se guardan bajo keys/ y se pueden referenciar por ruta.
Qué pasa con los permisos
Aquí también merece la pena pararse un momento. Rundeck no trata Key Storage como un cajón abierto para todo el mundo. La documentación de ACL explica que el acceso puede definirse tanto a nivel de sistema como a nivel de proyecto, y que lo recomendable es usar el almacenamiento por proyecto para mantener mejor el aislamiento. También deja claro que las rutas se pueden controlar por patrón, de forma que un grupo tenga acceso solo a una parte concreta del árbol de claves.
Esto, en un homelab pequeño, puede parecer exagerado. Pero incluso ahí tiene sentido acostumbrarse a hacerlo bien. Hoy eres solo tú. Mañana a lo mejor quieres separar proyectos, probar otro proveedor, o simplemente no mezclar una credencial de Proxmox con otra de cualquier servicio que acabes automatizando después.
Problemas comunes
El primer problema típico aquí es muy simple: guardar el secreto en una ruta sin orden y luego no saber qué job lo usa. No rompe nada el primer día, pero en cuanto crecen dos o tres pruebas, empieza a molestar bastante.
El segundo es equivocarte con la ruta exacta. Rundeck trata las rutas de Key Storage de forma sensible al path, y la propia documentación de troubleshooting del Storage Facility menciona el clásico error de “Key not found” cuando la ruta no coincide exactamente o cuando las ACL no permiten acceder a ella.
El tercero aparece cuando alguien intenta montar Rundeck en clúster y sigue usando un backend de ficheros local sin almacenamiento compartido. La documentación lo señala expresamente como un problema típico: si vas en clúster y el backend no está compartido, las claves pueden no estar accesibles en todos los nodos. Para un único servidor de laboratorio no suele aplicarte, pero conviene saberlo.
Y el cuarto es perder de vista la contraseña del propio mecanismo de cifrado si decides usar un converter plugin sobre el backend. Rundeck documenta esa posibilidad y también avisa de que, si pierdes esa capa de cifrado adicional, luego puedes encontrarte con problemas para actualizar o borrar claves. Para un homelab básico yo no me metería ahí salvo que realmente lo necesites.
Checklist final
Yo daría este paso por bueno cuando puedas decir que el token de Proxmox ya no está en un script ni en una nota rápida, que está guardado en una ruta clara dentro de Key Storage, que el proyecto tiene su propia jerarquía de secretos y que el job solo necesita referenciar esa ruta para usarlo. Si además has dejado medianamente claro el nombre del proyecto y la estructura, luego el resto de la serie va a encajar bastante mejor.
Conclusión
A mí esta parte me parece de las que menos lucen, pero de las que más se agradecen después. Porque instalar Rundeck da satisfacción rápida, sí. Pero cuando empiezas a meter tokens, claves y contraseñas, o lo ordenas un poco desde el principio o el entorno se te convierte en una chapuza incómoda de mantener.
Para este montaje yo lo dejaría muy simple: guardar secretos en Rundeck usando Key Storage, con rutas claras por proyecto y sin dejar el token pegado en scripts o jobs inline. No hace falta montar un sistema enorme para hacerlo bien. Hace falta solo parar cinco minutos y dejarlo con algo de sentido.
En el siguiente artículo seguiré ya con la parte de despliegue desde Rundeck hacia Proxmox, pero aquí quería dejar esta base bien resuelta antes de meter más piezas.
Espero que os sirva