Secret Manager

Pourquoi

Faites l'inventaire des secrets de Signalements à ce stade du cours : le mot de passe de la base, en clair dans /etc/signalements/env sur chaque instance ; le même, en variable secrète du conteneur serverless de préproduction ; les clés d'accès au bucket de la fonction de vignettes ; celles du job d'export, déjà dans Secret Manager ; la clé de lecture du registre sur les instances et dans Kapsule ; la clé d'écriture du registre dans les secrets de GitHub ; bientôt la clé du service d'e-mail. Une dizaine de secrets, copiés à la main à sept endroits, dont personne ne sait dire de mémoire lesquels ont changé depuis l'arrivée de la personne qui vient de partir.

C'est le problème qu'un gestionnaire de secrets résout : un seul endroit qui garde chaque secret, ses versions et qui peut le lire, et d'où chaque consommateur le tire au moment où il en a besoin. Le cours GitOps avec Argo CD a montré comment Kapsule lit Secret Manager avec External Secrets ; la leçon 6 a référencé deux secrets dans un job. Cette leçon fait le tour du service, pour tous les consommateurs de Signalements, et traite la question que les démonstrations évitent : comment changer un secret sans rien casser.

Les concepts

Secrets, versions, chemins

Un secret est un conteneur logique, rangé dans une région et un projet, qui porte un nom, un chemin (par défaut /), des étiquettes et un type. Ses versions, numérotées à partir de 1, contiennent les données ; elles sont immuables : changer un secret, c'est créer une nouvelle version. Une version est enabled (lisible), disabled (temporairement illisible), ou programmée pour suppression.

Le chemin organise les secrets comme des dossiers : le secret db rangé sous /signalements/prod est accessible par /signalements/prod/db. Les noms d'éléments de chemin font de 1 à 255 caractères alphanumériques, points, tirets bas et tirets. Depuis le 15 juillet 2026, le chemin sert aussi aux droits (plus bas).

Les types imposent un format au contenu, ce qui évite les versions mal formées et facilite l'intégration :

Toutes les versions d'un secret ont son type. Une version fait 64 Ko au plus, et un secret garde au plus 20 versions, ce qui oblige à supprimer les anciennes quand on fait tourner un secret souvent. Les quotas d'une organisation limitent aussi le nombre de secrets (100, ou 250 une fois l'identité vérifiée) et le nombre de lectures de valeurs.

Les versions se désignent par leur numéro, ou par deux alias : latest (la plus récente) et latest_enabled (la plus récente des versions activées). Le second est celui qu'un consommateur doit lire : désactiver la dernière version fait alors revenir les lecteurs à la précédente.

Protéger contre la suppression et l'erreur

• La protection empêche de supprimer un secret, même avec les droits complets ; il faut d'abord la retirer. Elle ne protège pas les versions.
• La suppression différée : depuis avril 2025, un secret ou une version supprimés restent sept jours « programmés pour suppression », illisibles mais récupérables, pour un centime par version récupérée. Les versions en attente de suppression ne sont pas facturées.
• Les politiques éphémères, fixées à la création et impossibles à retirer ensuite, font expirer chaque version après une durée (jusqu'à un an) ou après une seule lecture, puis la désactivent ou la suppriment. Utile pour un jeton d'amorçage qu'une machine ne doit lire qu'une fois.

Chiffrement

Secret Manager chiffre chaque version par chiffrement d'enveloppe, avec AES-256, dans une hiérarchie de clés : une clé racine gardée hors ligne, des clés de chiffrement de clés, et des clés de données (documentation de Scaleway). Depuis juin 2025, un secret peut être chiffré par une clé de Key Manager que vous gérez, choisie à la création (le champ key_id n'est pas modifiable ensuite). Avec une clé à vous, désactiver la clé rend toutes les versions illisibles d'un coup : c'est l'effacement cryptographique décrit dans Réduire la dépendance. Le service déchiffre pour vous à chaque lecture et transmet la valeur en TLS ; il n'écrit jamais la valeur en clair sur un stockage permanent, selon la FAQ.

Les droits

Sept jeux de permissions découpent finement les actions :

Un consommateur n'a besoin que de SecretManagerSecretAccess, plus SecretManagerReadOnly s'il doit retrouver un secret par son chemin ou lister. La personne qui fait tourner un secret a besoin de SecretManagerSecretCreate, pas de FullAccess.

Jusqu'en juillet 2026, ces droits portaient sur tout un projet : l'application qui lit le mot de passe de la base lisait aussi la clé du service d'e-mail. Les conditions au niveau de la ressource changent cela. Une règle de politique peut porter une expression CEL sur la ressource visée : resource.name (pour Secret Manager, le chemin complet du secret), resource.id et resource.locality. La documentation donne l'exemple qui nous intéresse :

resource.name.startsWith("/signalements/prod/") || !has(resource.id)

La première partie limite l'accès aux secrets du dossier. La seconde, que la documentation recommande explicitement, préserve les opérations de liste, qui ne visent pas une ressource unique et seraient sinon toutes refusées. La granularité est le secret, pas la version. Et la documentation prévient : la console et l'API ne vérifient que la syntaxe d'une condition, pas qu'elle puisse être satisfaite ; une faute de frappe dans le chemin donne une règle valide qui n'autorise rien.

Qui lit quoi : les consommateurs

La dernière colonne est la vraie limite du modèle : pour lire un secret, il faut une clé, qui est elle-même un secret. C'est le problème du secret zéro. Les grands fournisseurs l'ont résolu par des identités de charge de travail (un rôle attaché à une machine, une fédération OIDC depuis la CI) ; le cours précédent a constaté que Scaleway n'en propose pas au 5 octobre 2026 (Identité et accès). Le secret zéro existe donc toujours ; l'objectif est d'en avoir un seul par consommateur, avec le moins de droits possible, qui expire, plutôt qu'une dizaine de secrets recopiés partout.

Ce que l'audit voit

Audit Trail enregistre les opérations de gestion de Secret Manager : créer, modifier, supprimer un secret, activer ou retirer la protection, créer, désactiver, activer, supprimer une version. La liste des points d'accès enregistrés, au 5 octobre 2026, ne contient pas la lecture d'une valeur. Audit Trail répond donc à « qui a changé le mot de passe de la base, et quand ? », pas à « qui l'a lu ? ». C'est une raison de plus de limiter strictement qui peut lire.

En pratique

Les commandes ont été vérifiées avec l'aide de la CLI scw 2.62 et le SDK Go ; le comportement de scw rdb user update décrit plus bas vient du code source de la CLI. La leçon ne reproduit pas de sortie.

Organiser

Une arborescence par environnement, un secret par usage :

/signalements/prod/db                  database_credentials   lu par l'API
/signalements/prod/email               key_value              lu par l'API (leçon 10)
/signalements/prod/registre-lecture    basic_credentials      lu par les instances et Kapsule
/signalements/export/s3-access-key     opaque                 lu par le job (leçon 6)
/signalements/export/s3-secret-key     opaque                 lu par le job (leçon 6)

Créez le secret de la base, protégé, chiffré par une clé de Key Manager du projet :

$ SEC_DB=$(scw secret secret create name=db path=/signalements/prod \
    type=database_credentials protected=true key-id="$CLE_KM" \
    description="Compte applicatif de sig-db" tags.0=app=signalements \
    project-id="$PROJET" region=fr-par -o json | jq -r .id)

Sans key-id, Scaleway utilise une clé interne ; ce choix est définitif pour ce secret.

Une première version, sans passer par l'écran

La première version contient le compte actuel de la base. Pour ne pas taper le mot de passe en clair, on le régénère au passage, et l'on fait écrire la nouvelle valeur directement dans le secret. Le code de la CLI 2.62 révèle deux comportements à connaître de scw rdb user update :

• l'option generate-password vaut true par défaut : toute mise à jour d'un utilisateur sans mot de passe explicite en génère un nouveau, y compris quand on voulait seulement changer is-admin ;
• le mot de passe généré est imprimé (« Your generated password is ... ») quand la CLI se croit interactive, c'est-à-dire quand l'entrée standard et la sortie d'erreur sont des terminaux, ce qui casse un | jq. Rediriger l'entrée standard depuis /dev/null désactive ce mode ; le mot de passe n'apparaît alors que dans le champ password de la sortie JSON.

$ scw rdb user update instance-id="$DB_ID" name=signalements region=fr-par -o json < /dev/null \
    | jq -c --arg host "$DB_IP" --arg port "$DB_PORT" \
        '{engine: "postgres", username: .name, password: .password, host: $host, port: $port, dbname: "rdb"}' \
    | scw secret version create "$SEC_DB" data=@/dev/stdin disable-previous=true region=fr-par > /dev/null

La chaîne ne fait jamais apparaître le mot de passe à l'écran ni dans l'historique : il passe de la réponse de l'API de la base à l'API de Secret Manager par des tubes. data=@/dev/stdin utilise la lecture de fichier que l'aide de scw secret version create annonce pour cet argument. Dès cette commande, le mot de passe de la base a changé : tout consommateur qui l'avait en dur cesse de fonctionner, ce qui est exactement l'occasion de les migrer vers la lecture du secret.

Des droits limités à un dossier

L'application sig-api-prod sert aux consommateurs de production :

$ APP=$(scw iam application create name=sig-api-prod -o json | jq -r .id)
$ scw iam policy create name=sig-api-prod-secrets application-id="$APP" \
    rules.0.project-ids.0="$PROJET" \
    rules.0.permission-set-names.0=SecretManagerSecretAccess \
    rules.0.permission-set-names.1=SecretManagerReadOnly \
    rules.0.condition='resource.name.startsWith("/signalements/prod/") || !has(resource.id)'

Testez la règle avec la clé de l'application : la lecture de /signalements/prod/db doit réussir, celle de /signalements/export/s3-secret-key échouer. Une condition se teste, elle ne se relit pas seulement.

Lire depuis une instance

Sur sig-app-1, un petit script, lancé par systemd avant le service, lit le secret par son chemin et écrit le fichier d'environnement dans /run, un système de fichiers en mémoire :

#!/usr/bin/env bash
# /usr/local/sbin/signalements-secrets : écrit /run/signalements/env depuis Secret Manager.
set -euo pipefail
umask 077
API=https://api.scaleway.com/secret-manager/v1beta1/regions/fr-par
PROJET=$(cat /etc/signalements/projet-id)
install -d -m 0750 -o root -g signalements /run/signalements

curl -fsS --max-time 10 -H @/etc/signalements/scw-auth-header \
  "$API/secrets-by-path/versions/latest_enabled/access?secret_path=/signalements/prod&secret_name=db&project_id=$PROJET" \
  | jq -r '.data | @base64d | fromjson
           | "DATABASE_URL=postgresql://\(.username | @uri):\(.password | @uri)@\(.host):\(.port)/\(.dbname)"' \
  > /run/signalements/env.tmp
chgrp signalements /run/signalements/env.tmp
chmod 0640 /run/signalements/env.tmp
mv /run/signalements/env.tmp /run/signalements/env

Et dans l'unité, par une surcharge (systemctl edit signalements) :

[Service]
ExecStartPre=+/usr/local/sbin/signalements-secrets
EnvironmentFile=/run/signalements/env

Les détails comptent :

• -H @/etc/signalements/scw-auth-header : curl lit l'en-tête X-Auth-Token: <clé secrète> dans un fichier (root, 0600) au lieu de la recevoir en argument, où elle serait visible dans la liste des processus. Ce fichier est le secret zéro de l'instance : la clé de sig-api-prod, déposée une fois par l'équipe (pas dans les données utilisateur, cours précédent, leçon 4), avec une expiration.
• latest_enabled : désactiver une version mauvaise fait revenir l'instance à la précédente au prochain redémarrage du service.
• @base64d puis fromjson : l'API renvoie la valeur encodée en base64 dans data ; c'est un JSON du type database_credentials.
• @uri : le mot de passe généré contient des caractères spéciaux, qui casseraient l'URL de connexion s'ils n'étaient pas encodés. C'est la cause de beaucoup de « mot de passe refusé » après une rotation.
• /run : le fichier disparaît au redémarrage de la machine et n'est jamais écrit sur disque ; le préfixe + d'ExecStartPre exécute le script en root, alors que le service tourne sous le compte signalements (cours Linux : premiers pas).
• L'écriture atomique (fichier temporaire, puis mv) évite qu'un service démarre sur un fichier à moitié écrit.

Lire depuis Kapsule et depuis Serverless

Kapsule. Deux voies documentées par Scaleway. External Secrets Operator, déjà en place chez Lyneko (cours GitOps avec Argo CD), crée des objets Secret de Kubernetes à partir de Secret Manager et les met à jour périodiquement. Le pilote CSI Secrets Store avec le fournisseur Scaleway monte les secrets comme fichiers dans les pods, sans créer d'objet Secret ; sa documentation précise qu'il ne s'authentifie pas encore par un compte de service Kubernetes, mais par une clé d'API rangée dans un Secret du cluster, avec au minimum SecretManagerReadOnly et SecretManagerSecretAccess. Dans les deux cas, la clé du cluster reçoit la même condition de dossier que plus haut.

Serverless Containers et Functions. Pas d'intégration au 5 octobre 2026. La CI lit le secret et l'écrit en variable secrète du conteneur :

$ DATABASE_URL=$(scw secret version access "$SEC_DB" revision=latest_enabled raw=true region=fr-par \
    | jq -r '"postgresql://\(.username | @uri):\(.password | @uri)@\(.host):\(.port)/\(.dbname)"')
$ scw container container update "$CT_ID" \
    secret-environment-variables.DATABASE_URL="$DATABASE_URL" region=fr-par --wait
$ unset DATABASE_URL

C'est un compromis : le secret existe maintenant à deux endroits, et un changement dans Secret Manager ne se propage qu'au prochain passage de cette étape. Documentez-le, et faites tourner la CI après chaque rotation.

Jobs. La référence native de la leçon 6 : rien à copier, chaque exécution lit la version référencée.

Faire tourner le mot de passe sans coupure

Changer le mot de passe d'un compte utilisé par des instances en service les déconnecte toutes : les nouvelles connexions échouent jusqu'à ce que chaque consommateur ait relu le secret. La méthode classique pour l'éviter utilise deux comptes qui alternent :

1. La base a deux comptes applicatifs aux mêmes droits, signalements_a et signalements_b ; le secret désigne aujourd'hui signalements_a.
2. On régénère le mot de passe de signalements_b, qui ne sert à personne, et l'on écrit une nouvelle version du secret désignant signalements_b (la commande de la section « Une première version », avec name=signalements_b).
3. On fait relire le secret à chaque consommateur (redémarrage progressif des services, passage de la CI pour le serverless, synchronisation d'External Secrets). Pendant ce temps, les anciens consommateurs continuent avec signalements_a, qui fonctionne toujours.
4. Quand plus personne n'utilise signalements_a (la vue pg_stat_activity de PostgreSQL le montre), on désactive la version précédente du secret.
5. À la rotation suivante, on fait de même dans l'autre sens.

Aucune connexion n'échoue, et un retour arrière reste possible tant que l'ancien compte n'a pas changé. La création des comptes et de leurs droits relève de la leçon 3.

Désactiver, récupérer, nettoyer

$ scw secret version list "$SEC_DB" region=fr-par -o json | jq -r '.[] | [.revision, .status, .created_at] | @tsv'
$ scw secret version disable "$SEC_DB" revision=3 region=fr-par
$ scw secret version delete "$SEC_DB" revision=1 region=fr-par

Avec la limite de 20 versions, une rotation mensuelle impose de supprimer les anciennes versions désactivées. Une suppression est récupérable pendant sept jours (SecretManagerSecretRestore).

Sous le capot

Chiffrement d'enveloppe à trois niveaux. Chaque version est chiffrée par une clé de données ; cette clé est chiffrée par une clé de chiffrement de clés ; celles-ci sont protégées par une clé racine conservée hors ligne. Les trois niveaux sont stockés séparément, sur des bases de données répliquées distinctes. Quand le secret utilise une clé de Key Manager à vous, c'est elle qui joue le rôle de clé de chiffrement de clés : sans elle, le service ne peut plus déchiffrer. Chaque lecture est donc un appel au gestionnaire de clés, d'où une latence et un coût par accès qui justifient de lire un secret au démarrage plutôt qu'à chaque requête.

Une lecture, c'est un appel d'API comme un autre. L'API vérifie la clé, évalue les politiques de son porteur (jeux de permissions, projet, puis la condition CEL avec les attributs du secret visé), déchiffre, et renvoie la valeur en base64 dans un objet JSON. Rien ne distingue, côté réseau, la lecture d'un secret d'un autre appel à api.scaleway.com : la protection tient entièrement à la clé et à la politique.

Ce que l'application fait ensuite. Une fois lu, le secret vit dans la mémoire du processus et, souvent, dans son environnement. Le cours Linux : premiers pas a montré que l'environnement d'un processus est lisible par son propriétaire et par root dans /proc/<pid>/environ, et qu'il est hérité par tous les processus enfants. Secret Manager protège le secret au repos et en transit ; il ne protège pas le processus qui l'utilise.

Pièges courants

Un mot de passe régénéré par accident. scw rdb user update ... is-admin=true, lancé pour changer un droit, régénère le mot de passe (option generate-password à true par défaut dans la CLI 2.62). La production perd sa base. Passez toujours generate-password=false quand vous ne voulez pas changer le mot de passe.

Une condition qui n'autorise rien, ou plus aucune liste. Une faute dans le chemin ne produit aucune erreur à la création de la politique. Oublier || !has(resource.id) casse les commandes de liste et une partie de la console. Testez avec la clé du consommateur.

latest au lieu de latest_enabled. Désactiver une version défectueuse ne sert à rien si les consommateurs lisent latest.

L'URL de connexion qui casse à la rotation. Un mot de passe avec @, / ou : non encodé dans une URL postgresql:// produit une erreur d'authentification ou d'hôte inconnu. Encodez (@uri), ou passez les paramètres séparément.

La 21e version refusée. Vingt versions au plus par secret : un processus de rotation automatique qui ne supprime jamais finit par échouer.

Un job dans une autre région. Un job ne peut référencer que des secrets de sa région. Une version désactivée fait échouer l'exécution avec la raison secret_disabled.

Le secret dans les journaux. set -x dans un script, un print(os.environ) de débogage, une exception qui affiche l'URL de connexion : la valeur se retrouve dans Cockpit, conservée des jours, lisible par plus de monde que Secret Manager. Relisez ce que vos programmes journalisent.

Sécurité

Moins de copies, moins de lecteurs. Le gain principal de Secret Manager n'est pas le chiffrement, c'est la réduction du nombre d'endroits où vit chaque secret et du nombre d'identités qui peuvent le lire. Une condition de dossier par consommateur, et aucune identité humaine avec SecretManagerSecretAccess en production au quotidien.

Le secret zéro. Chaque clé d'API qui lit des secrets doit avoir une expiration, un seul usage, une condition de dossier, et figurer dans un inventaire. Sa fuite donne accès à un dossier, pas à tous les secrets du projet ; sans condition, c'était le cas avant juillet 2026.

La lecture n'est pas auditée. Au 5 octobre 2026, Audit Trail ne journalise pas les accès aux valeurs. Combinez des droits de lecture très étroits avec la journalisation des modifications, et surveillez le nombre de lectures (métriques et facture) : une hausse brutale signale un consommateur qui boucle, ou quelqu'un qui lit ce qu'il ne devrait pas.

Une clé à vous, et sa garde. Chiffrer les secrets par une clé de Key Manager donne un interrupteur général (désactiver la clé). Il coupe aussi la production : la désactivation de la clé doit être un geste préparé, réservé à très peu de personnes, et distinct des droits sur Secret Manager.

Faire tourner, vraiment. Une rotation qui n'a jamais été jouée échouera le jour où une fuite l'imposera. Jouez la rotation à deux comptes en préproduction, puis en production, à intervalles réguliers.

En production

• Un projet par environnement, et dans chaque projet une arborescence par application et par usage. Les conditions de dossier rendent ce découpage efficace.
• La rotation est un processus, écrit et chronométré : qui la déclenche, quels consommateurs relire, comment vérifier, comment revenir en arrière. Automatisez-la en job quand elle est stable.
• L'inventaire des secrets zéro (clés d'API des instances, des clusters, de la CI), avec dates d'expiration, propriétaires et procédure de renouvellement, fait partie de la revue des accès (leçon 15).
• Lire au démarrage, pas à chaque requête : les lectures sont facturées, limitées par quota, et ajoutent de la latence.
• Chez Lyneko, les applications de Kapsule lisent Secret Manager par External Secrets ; la clé de l'opérateur est le seul secret zéro du cluster.

Exercices

1. La bonne politique (niveau 200). Écrivez la règle de politique de l'application sig-export (le job de la leçon 6) pour qu'elle ne puisse lire que les secrets de /signalements/export/. Quels jeux de permissions lui donnez-vous, et pourquoi le job a-t-il, en réalité, moins besoin de ces droits qu'une instance ?

2. Diagnostiquer une rotation (niveau 200). Après une rotation, la moitié des requêtes de l'API échouent avec password authentication failed, l'autre moitié réussit. Les deux instances ont été redémarrées. Donnez deux hypothèses et la vérification de chacune.

3. Le secret zéro (niveau 200). Proposez, pour une nouvelle instance de Signalements créée par une procédure automatisée, une façon de déposer la clé de sig-api-prod qui n'utilise pas les données utilisateur, et dites quel risque reste.

Récapitulatif

• Un secret a un chemin, un type et des versions immuables (20 au plus) ; on lit latest_enabled.
• Protection, suppression différée de sept jours, politiques éphémères (durée ou lecture unique), chiffrement d'enveloppe, éventuellement par une clé Key Manager choisie à la création.
• Des jeux de permissions fins, et depuis juillet 2026 des conditions au niveau de la ressource : resource.name.startsWith("/dossier/") || !has(resource.id).
• Consommateurs : jobs par référence native ; serverless par copie faite par la CI ; Kapsule par External Secrets ou CSI ; instances par un appel d'API au démarrage, vers /run.
• Le secret zéro demeure, faute d'identité de charge de travail : un par consommateur, étroit, qui expire.
• Rotation sans coupure avec deux comptes qui alternent ; attention à generate-password=true par défaut dans scw rdb user update.
• Audit Trail journalise les modifications, pas les lectures.

Pour aller plus loin

• L'OWASP Secrets Management Cheat Sheet, pour le cycle de vie complet d'un secret et les erreurs les plus fréquentes.
• Le cours Gestion des secrets, qui compare Secret Manager, OpenBao et les solutions des autres fournisseurs.
• La documentation des conditions IAM au niveau de la ressource, qui s'étendront à d'autres produits.
• La leçon 15, qui reprend l'inventaire des clés et la revue des accès.