Coffre de secrets

Les identifiants sont scellés dès leur écriture et aucun point d'accès ne les renvoie. Seul le worker les ouvre, au moment d'un appel sortant.

Le coffre contient les identifiants que vous saisissez : une clé de fournisseur de modèles, le jeton d'un outil HTTP ou d'un serveur MCP, le jeton d'un connecteur de source, un jeton Slack saisi à la main, le secret de signature d'un webhook planifié. Il utilise un chiffrement par enveloppe : chaque secret est chiffré avec sa propre clé de données (AES-256-GCM), et cette clé est chiffrée avec la clé publique de la paire de clés de scellement de l'instance (RSA-OAEP).

La paire de clés de scellement est partagée entre les 2 services. Le serveur d'API reçoit la clé publique (RIKOO_SECRETS_PUBLIC_KEY) : il peut sceller une valeur, pas l'ouvrir. Seul le worker détient la clé privée (RIKOO_SECRETS_PRIVATE_KEY, ou un fichier avec RIKOO_SECRETS_PRIVATE_KEY_FILE).

Les identifiants que Rikoo obtient lui-même, plutôt que ceux que vous tapez, sont scellés dans la même enveloppe mais rangés avec la ressource à laquelle ils appartiennent : les jetons OAuth d'un serveur MCP, les jetons Slack obtenus en installant l'application, les secrets de signature des webhooks sortants.

Les règles

• Écriture seule depuis l'extérieur. Aucun point d'accès ne renvoie la valeur d'un secret. L'écran Secrets montre son nom, son type, sa portée (un projet ou toute l'organisation) et les 4 derniers caractères de la valeur comme indice.
• Le serveur d'API ne déchiffre jamais. Seul le worker le fait, uniquement dans la pile d'un appel sortant, et il retire la valeur de ses propres lignes de journal.
• Chaque accès est audité. Une entrée secret_accessed consigne quel secret a été ouvert, pour quelle exécution et à quel moment. Elle est écrite avant que la valeur soit remise : si l'entrée ne peut pas être écrite, l'accès est refusé.
• Un secret référencé ne se supprime pas. La suppression est refusée tant qu'un fournisseur de modèles, un outil HTTP, un serveur MCP, une source ou une planification d'agent pointe encore vers lui.
• Un secret expiré reste fermé. Quand un secret a une date d'expiration, le worker refuse de l'ouvrir une fois la date passée.

C'est à vous de protéger la paire de clés de scellement

Aucune paire de clés n'est livrée avec Rikoo : vous la générez à l'installation de la plateforme (voir Docker Compose ou Kubernetes (Helm)). Hors production, si la clé publique manque, le serveur d'API fabrique une paire temporaire et le coffre passe en lecture seule : l'écran Secrets le signale et refuse les nouveaux secrets. En production, la paire est exigée. Gardez la clé privée hors des images, préférez la variante fichier, et sauvegardez-la ailleurs que dans la base qu'elle protège. Perdre la clé privée rend illisible toute valeur scellée, et les identifiants doivent alors être saisis de nouveau.

Rotation

Pour remplacer un identifiant, utilisez Rotation de la valeur sur l'écran Secrets et collez la nouvelle valeur. Rien n'est à ressaisir ailleurs, parce que les fournisseurs, les outils et les serveurs référencent le secret, pas son contenu. La date d'expiration suit la valeur : la rotation peut en fixer une nouvelle, ou l'effacer.

L'ancienne valeur reste scellée pendant 24 heures, puis elle est purgée. Pendant cette fenêtre, elle ne sert qu'à vérifier les signatures entrantes produites avant la rotation ; elle n'est jamais envoyée à un tiers. Les fournisseurs de modèles qui utilisent le secret remplacé sont marqués comme devant repasser un test de connexion.

La rotation de la paire de clés de scellement elle-même revient à l'exploitant. Le worker garde les anciennes clés privées dans RIKOO_SECRETS_PRIVATE_KEYS_PREVIOUS jusqu'à ce que la tâche de re-scellement (make secrets-rewrap) ait scellé de nouveau chaque clé de données avec la nouvelle paire.