Las credenciales siguen viajando por correo y por Slack en proyectos por lo demás cuidados. Toda integración con un servicio externo las necesita, y reenviarlas de una parte a otra es tan rutinario que el riesgo apenas se cuestiona. Esa costumbre se puede evitar, y evitarla cambia quién custodia los secretos y quién no necesita verlos nunca.
La costumbre de pasar contraseñas por correo o por Slack
Recibir una contraseña en texto plano por correo o por Slack es algo habitual en cualquier proyecto Drupal. Pasa porque toda integración con un servicio externo, ya sea una pasarela de pago, un CRM o una API de terceros, necesita credenciales de acceso. Usuarios y contraseñas, tokens, URLs privadas y otros datos sensibles que en algún momento tienen que viajar de un sitio a otro.
Esas credenciales no deberían acabar nunca en un repositorio de código ni en los archivos YAML de configuración de Drupal. El riesgo de exposición es demasiado alto. La alternativa más habitual, sin embargo, no resuelve el problema de fondo.
Los problemas de aprovisionar credenciales en un proyecto
Lo más extendido es guardar los secretos en un archivo fuera del webroot, o definirlos como variables de entorno accesibles solo para PHP. Funciona, pero tiene un coste operativo que aparece en cuanto hay que cambiar una contraseña: esos archivos se editan a mano y, si se usan variables de entorno, puede hacer falta recargar Apache o Nginx.
El problema de fondo es el traspaso en sí. Imagina un proyecto Drupal que necesita integrarse con dos servicios externos: una pasarela de pago (Servicio A) y un CRM (Servicio B). Para montar cada integración, el cliente contacta con cada proveedor del servicio, consigue las credenciales y se las entrega a quien gestiona Drupal, que las guarda con el método que permita la infraestructura.
El proceso se repite con cada servicio nuevo y el riesgo se acumula en cada paso. Desde quien gestiona el servicio integrado hasta quien gestiona dónde se guarda el secreto, hay una cadena de transporte que puede comprometerse en cualquier punto, aunque nadie actúe de mala fe.
La exposición tampoco termina con la puesta en marcha. Cuando las credenciales caducan o toca rotarlas, la cadena entera vuelve a ejecutarse: el cliente contacta con el proveedor, el proveedor actualiza la configuración, se prueba y se despliega. Cada rotación arrastra su propia coordinación: mensajes de ida y vuelta con el proveedor, verificación por entornos y un despliegue.
Los servicios Vault solucionan los problemas de traspasos de credenciales
Los servicios Vault (Hashicorp Vault, OpenBao, Infisical, entre otros) están pensados justo para esto: almacenar secretos y controlar quién accede a cada uno, sin necesidad de transferirlos entre las partes.
La integración con Drupal funciona así: el cliente comparte una única credencial de conexión al Vault, el role_id y el secret_id en la terminología de Hashicorp Vault, y no las credenciales de cada servicio. A partir de ahí, quien gestiona Drupal puede configurar el Servicio A y el Servicio B sin recibir nunca las credenciales de esos servicios. Drupal las obtiene bajo demanda directamente del Vault. El flujo es siempre unidireccional: del Vault a Drupal. Drupal solo lee secretos, nunca los escribe.
Hay dos escenarios habituales donde la ventaja se ve con claridad. El primero es la rotación de credenciales: cuando las claves caducan por política de seguridad, el cliente las actualiza en su Vault y Drupal recoge los valores nuevos de forma automática, sin que el proveedor tenga que hacer nada. El segundo es el control de acceso granular: si se añade un Servicio C gestionado por otro proveedor, el cliente incorpora esas credenciales al Vault y da acceso solo al role_id de ese segundo proveedor. Las credenciales del Servicio C siguen siendo invisibles para el primero.
Qué hace falta para empezar
El Vault es del cliente, no del proveedor. Ahí está la clave del modelo: quien contrata el desarrollo conserva la propiedad y el control de sus secretos. Puede ser un Vault autoalojado o un servicio gestionado, y si todavía no existe, montarlo y definir las políticas de acceso forma parte del arranque del proyecto.
A partir de ese momento el Vault es una dependencia en tiempo de ejecución. Drupal cachea temporalmente las credenciales que recupera, lo que amortigua cortes breves, pero una caída prolongada del Vault afecta a las integraciones que dependen de esos secretos. Se gestiona como cualquier otro servicio crítico de la infraestructura: monitorización, alta disponibilidad si el proyecto lo justifica y un plan de recuperación documentado.
Mantener un servicio Vault añade su propio coste de infraestructura, y conviene decirlo. La diferencia es que ese coste se asume como una inversión deliberada en seguridad, no como fricción operativa que no devuelve nada.
Vault en la práctica: de la configuración a la rotación automática
Lo que sigue describe la integración más habitual, la de Hashicorp Vault con Drupal. OpenBao funciona igual, al ser un fork del mismo proyecto. Otros productos como Infisical parten del mismo modelo conceptual, pero cambian la API y, con ella, los módulos y la configuración necesarios.
La integración con Drupal se apoya en dos módulos base, Vault y Key, que resuelven la conexión con el servidor Vault y la obtención de los secretos como claves reutilizables en todo el proyecto. De forma opcional, el módulo Encrypt cifra los leases temporales: las credenciales que Drupal obtiene bajo demanda y guarda de forma temporal en memoria o en base de datos.
El método de autenticación depende de cómo esté configurado el Vault del cliente. Uno de los más habituales es approle, con el módulo vault_auth_approle, aunque otros como la autenticación por token, con vault_auth_token, pueden encajar mejor según la organización.
El primer paso es guardar el secret_id del Vault como una key de Drupal, que después consume el módulo de autenticación.
Hay un detalle técnico propio de Hashicorp Vault y OpenBao, no una característica común a todos los productos, que conviene verificar antes de empezar: la versión del motor de almacenamiento clave-valor (v1 o v2) determina si el módulo estándar de obtención de secretos, vault_key_kv, es compatible. Si no lo es, quedan dos caminos: desarrollar un key provider a medida, o pedir al cliente que migre sus secretos a la versión compatible.
A partir de ahí, cada secreto se declara como una key más de Drupal con el proveedor Vault Key/Value. La key guarda una referencia a la ruta del Vault, y el valor se obtiene en cada lectura.
En un proyecto de Metadrop con un Vault autoalojado y una configuración propia, las credenciales llegaban en un formato inesperado que obligó a escribir un módulo a medida. Lo que hizo especialmente difícil el diagnóstico es que los primeros síntomas parecían errores de permisos, no una incompatibilidad de formato. Una vez resuelta esa capa, el resultado fue el esperado: añadir un servicio nuevo o rotar las credenciales de uno existente solo requiere crear claves nuevas en Drupal, que se obtienen del Vault automáticamente.
Conclusión
La gestión segura de credenciales forma parte de cómo se construye cualquier integración en un entorno Drupal serio, y así se plantea en los proyectos de Metadrop desde el primer día. Un servicio Vault resuelve el problema estructural: elimina el traspaso manual de credenciales entre cliente y proveedor y reduce el riesgo de exposición en cada punto de la cadena.
El efecto se nota en la siguiente rotación. Lo que antes era coordinación entre cliente y proveedor, verificación por entornos y un despliegue pasa a ser ninguna intervención. El cliente cambia la credencial en su Vault y Drupal empieza a usarla.
El caso del Vault autoalojado ilustra bien cómo se ve esto en la práctica: no todo funciona nada más enchufarlo, pero los obstáculos se resuelven y el resultado compensa el esfuerzo.
Si este artículo te resulta útil, compártelo con alguien a quien le pueda hacer falta.
