Gestión de credenciales

Casi toda automatización necesita acceder a sistemas que piden usuario y contraseña: un ERP, un servidor de correo, una API, una base de datos. El problema es obvio: no debes escribir esas contraseñas dentro del playbook. Si lo haces, cualquiera con acceso al proyecto las ve, quedan en los logs y cambiarlas obliga a reeditar la automatización.

Las credenciales de Nexus resuelven esto. Guardan los datos sensibles cifrados dentro de un entorno, y tus bots los obtienen en tiempo de ejecución por nombre, sin que el valor real aparezca nunca en el playbook ni en los registros.

Idea central

En el playbook escribes = credential("erp-produccion"), no la contraseña. El valor real lo inyecta el agente de forma segura justo al ejecutar. Cambiar la contraseña es actualizar la credencial en el portal — el playbook no se toca.

Crear una credencial

1. Entra al entorno y abre la pestaña Credenciales.
2. Haz clic en Nueva credencial.
3. Dale un nombre único y descriptivo (ej. erp-produccion, smtp-notificaciones, gmail-api). Este es el nombre con el que la referenciarás.
4. Agrega los datos que la credencial necesita (ver los dos formatos abajo).
5. Guarda.

Dos formatos de credencial

Valor único

Para un secreto simple, como un token o una sola contraseña. Lo recuperas con .ToPlainText().

Campo	Valor
valor	sk-prod-9f2a...

Múltiples campos (clave-valor)

Para sistemas que requieren varios datos juntos. Cada campo se recupera por su clave con ["campo"]. Por ejemplo, una conexión a base de datos:

Clave	Valor
host	db.miempresa.com
user	nexus_user
password	••••••••
database	produccion

Los valores no se vuelven a mostrar

Una vez guardados, los valores quedan cifrados y no se pueden ver desde el portal — solo reemplazar. Esto protege los secretos incluso de quien administra Nexus. Guarda el valor original en tu gestor de contraseñas si necesitas conservarlo.

Llave de service account (Google)

Para autenticación servidor-a-servidor (p. ej. una service account de Google), guarda el JSON completo de la llave —tal cual lo descargas de Google Cloud— como el valor único de una credencial. La actividad la referencia por nombre y construye la autenticación desde ese JSON.

Nunca pegues la llave dentro del playbook

La private_key de una service account es tan sensible como una contraseña. Guárdala solo como credencial cifrada y referénciala por nombre; jamás la pongas como parámetro literal de una actividad ni como ruta de archivo en el robot.

¿Credencial u conexión OAuth?

Si el acceso es a una cuenta de terceros vía OAuth (Google, Microsoft…), normalmente usarás una conexión OAuth en lugar de una credencial. La credencial con JSON de service account es la alternativa sin consentimiento de usuario (ideal para desatendido).

Las credenciales viven en un entorno

Una credencial pertenece al entorno donde la creas y solo es visible para los agentes de ese entorno. Esto es intencional y muy útil:

• En Pruebas apuntas a un sistema de pruebas; en Producción, al real.
• El mismo playbook funciona en ambos sin cambios, porque referencia la credencial por nombre (erp), y cada entorno resuelve su propio valor.

Playbook:  = credential("erp")
                  │
   ┌──────────────┴───────────────┐
Entorno "Pruebas"          Entorno "Producción"
 erp → erp-test.com         erp → erp.miempresa.com

Convención: mismo nombre en cada entorno

Usa el mismo nombre lógico para la credencial en todos los entornos (erp, no erp-prod y erp-test). Así el playbook es idéntico en todos lados y solo cambia el valor según dónde se ejecuta.

Actualizar una credencial

Puedes agregar, modificar o reemplazar los valores de una credencial existente. Los cambios aplican desde la próxima ejecución que la use; las ejecuciones en curso no se ven afectadas. No necesitas volver a publicar ningún paquete.

Buenas prácticas de seguridad

• Nombres descriptivos y consistentes: erp-produccion, gmail-notificaciones.
• Una credencial por sistema y por entorno: no reutilices la misma en producción y pruebas.
• Rota periódicamente los secretos actualizando solo el valor en el portal.
• Principio de mínimo privilegio: que la cuenta detrás de la credencial tenga solo los permisos que el bot necesita.

Siguientes pasos

• Uso de credenciales en automatizaciones — cómo referenciarlas desde un playbook.
• Entornos — cómo separar producción y pruebas.