Bóveda de secretos

Las credenciales se sellan en cuanto se escriben y ningún endpoint las devuelve. Solo el worker las abre, en el momento de una llamada saliente.

La bóveda guarda las credenciales que usted introduce: una clave de proveedor de modelos, el token de una herramienta HTTP o de un servidor MCP, el token de un conector de fuentes, un token de Slack introducido a mano, el secreto de firma de un webhook programado. Usa cifrado de sobre: cada secreto se cifra con su propia clave de datos (AES-256-GCM), y esa clave se cifra con la clave pública del par de claves de sellado de la instancia (RSA-OAEP).

El par de claves de sellado se reparte entre los 2 servicios. El servidor de API recibe la clave pública (RIKOO_SECRETS_PUBLIC_KEY): puede sellar un valor, no abrirlo. Solo el worker tiene la clave privada (RIKOO_SECRETS_PRIVATE_KEY, o un archivo con RIKOO_SECRETS_PRIVATE_KEY_FILE).

Las credenciales que Rikoo obtiene por sí mismo, en lugar de las que usted escribe, se sellan con el mismo sobre pero se guardan con el recurso al que pertenecen: los tokens OAuth de un servidor MCP, los tokens de Slack obtenidos al instalar la aplicación, los secretos de firma de los webhooks salientes.

Las reglas

• De solo escritura desde fuera. Ningún endpoint devuelve el valor de un secreto. La pantalla Secrets muestra su nombre, su tipo, su alcance (un proyecto o toda la organización) y los 4 últimos caracteres del valor como pista.
• El servidor de API nunca descifra. Solo lo hace el worker, únicamente en la pila de una llamada saliente, y retira el valor de sus propias líneas de registro.
• Cada acceso queda auditado. Una entrada secret_accessed registra qué secreto se abrió, para qué ejecución y cuándo. Se escribe antes de entregar el valor: si la entrada no puede escribirse, el acceso se rechaza.
• Un secreto referenciado no se puede eliminar. La eliminación se rechaza mientras un proveedor de modelos, una herramienta HTTP, un servidor MCP, una fuente o una programación de agente siga apuntando a él.
• Un secreto caducado permanece cerrado. Cuando un secreto tiene fecha de caducidad, el worker se niega a abrirlo una vez pasada la fecha.

Proteger el par de claves de sellado le corresponde a usted

Rikoo no incluye ningún par de claves: usted lo genera al instalar la plataforma (consulte Docker Compose o Kubernetes (Helm)). Fuera de producción, si falta la clave pública, el servidor de API crea un par temporal y la bóveda pasa a solo lectura: la pantalla Secrets lo indica y rechaza los secretos nuevos. En producción, el par es obligatorio. Mantenga la clave privada fuera de las imágenes, prefiera la variante de archivo y haga una copia de seguridad en un lugar distinto de la base de datos que protege. Perder la clave privada deja ilegible todo valor sellado, y entonces hay que volver a introducir las credenciales.

Rotación

Para sustituir una credencial, use Rotate the value (rotar el valor) en la pantalla Secrets y pegue el valor nuevo. No hay que volver a introducir nada en otro sitio, porque los proveedores, las herramientas y los servidores referencian el secreto, no su contenido. La fecha de caducidad sigue al valor: la rotación puede fijar una nueva o borrarla.

El valor anterior sigue sellado durante 24 horas y después se purga. Durante ese plazo solo sirve para verificar firmas entrantes producidas antes de la rotación; nunca se envía a un tercero. Los proveedores de modelos que usan el secreto rotado quedan marcados como pendientes de una nueva prueba de conexión.

La rotación del propio par de claves de sellado es una tarea del operador. El worker conserva las claves privadas anteriores en RIKOO_SECRETS_PRIVATE_KEYS_PREVIOUS hasta que la tarea de resellado (make secrets-rewrap) haya vuelto a sellar cada clave de datos con el par nuevo.