Secrets

Chinaski garde ses valeurs secrètes importantes (le secret maître sur lequel il tourne, et les credentials pour les services auxquels il parle) hors du texte en clair et hors de la vue. Cette page explique comment fonctionne CHINASKI_SECRET, quels réglages sont stockés chiffrés, et ce qui se passe si vous faites tourner le secret maître.

La variable d'environnement CHINASKI_SECRET

C'est l'unique secret maître d'une instance Chinaski, et il doit exister avant que le serveur démarre : sans lui le CMS refuse de tourner du tout.

Il protège deux choses :

1. Les sessions admin. Votre cookie de session de connexion est signé cryptographiquement avec cette clé. Les utilisateurs ne le voient ni ne le manipulent jamais.
2. Le stockage chiffré. La clé de chiffrement protégeant les credentials stockés dans la base de données en est dérivée. Ces credentials ne sont jamais écrits sur le disque en texte clair.

Sa génération est une étape ponctuelle que l'installateur fait pour vous dans le déploiement standard : la valeur est écrite dans un fichier env verrouillé en permissions (0600, dans un répertoire 0700) que seul l'utilisateur de service du CMS peut lire. Dans le flux d'installation hors ligne, la recette est :

export CHINASKI_SECRET=$(openssl rand -hex 32)    # do this once; save the value

Ne le commitez jamais dans des dépôts, ne le partagez pas entre instances, et gardez-en une copie en lieu sûr : vous ne pouvez pas le récupérer depuis le système en marche.

Ce qui est stocké chiffré

Plusieurs réglages dans la zone admin sont des valeurs sensibles à la sécurité et sont stockés dans la base de données chiffrés. Les réglages secrets enregistrés sont :

• Mot de passe SMTP
• Secret de webhook
• Secret key S3 de deploy
• Secret key Turnstile
• Secret key de backup (Spaces)
• Client secret OAuth

Le chiffrement est authentifié (AES-256-GCM avec un nonce aléatoire par valeur et une balise d'intégrité). Les valeurs chiffrées sont stockées avec un préfixe de version pour que le format puisse évoluer. Si une ligne a été écrite par une version plus ancienne en texte clair, le système le tolère jusqu'à la prochaine sauvegarde du réglage, moment où il est mis à niveau vers la forme chiffrée.

Secrets et API

L'API de lecture ne renvoie jamais les réglages secrets ; ils sont retirés de la réponse même pour les clés API authentifiées. Les écritures API chiffrent une nouvelle valeur de la même façon que l'UI admin. Les intégrations tierces ne peuvent pas lire vos credentials stockés via l'API.

Faire tourner le secret maître

Changer CHINASKI_SECRET est une opération sérieuse avec des conséquences connues :

• Tout le monde est déconnecté. Les cookies de session existants étaient signés avec l'ancienne clé et deviennent invalides dès que la nouvelle clé prend effet ; tous les admins et éditeurs doivent se reconnecter. Il n'y a aucune clé de recouvrement ni de repli.
• Les credentials stockés cessent de fonctionner. Les credentials chiffrés de la base de données (SMTP, webhook, Turnstile, OAuth, S3, backup) étaient chiffrés sous une clé dérivée de l'ancien secret. Avec le nouveau secret, ils ne peuvent pas être déchiffrés.
• Le corriger signifie re-sauvegarder. Après la rotation, ouvrez les réglages pertinents dans la zone admin et re-sauvegardez chaque valeur de credential pour qu'elle soit re-chiffrée sous la nouvelle clé. Cette même action met à niveau toute valeur en texte clair legacy que vous auriez encore.

Il n'y a aucune commande intégrée pour automatiser la migration des secrets stockés à travers une rotation dans la release actuelle ; planifiez la rotation : choisissez une fenêtre de maintenance, faites tourner la valeur env, redémarrez l'instance, reconnectez-vous à neuf, et re-sauvegardez chaque réglage affecté. Testez le mail, les webhooks et toute autre intégration configurée ensuite.

Pratiques d'hygiène imposées par le système

• Les secrets vivent uniquement dans l'environnement ou dans des valeurs chiffrées de la base de données ; l'application ne garde une copie en clair en mémoire que là où c'est nécessaire pour parler à un service.
• Le fichier de base de données et le fichier env ne sont lisibles que par le propriétaire ; le répertoire de backup est réservé au propriétaire. Les installations standard les placent dans des répertoires auxquels seul l'utilisateur de service chinaski peut accéder.
• L'outil de configuration scripté préfère lire le mot de passe admin depuis une variable d'environnement plutôt que depuis un flag en ligne de commande, pour que le mot de passe n'apparaisse pas dans la liste des processus pendant la configuration.
• Pour les hôtes isolés/airgappés, définir CHINASKI_AIRGAP=1 désactive tout appel sortant que le CMS pourrait faire. Rien dans votre déploiement ne doit quitter la machine pour que le cœur tourne.