Secret Manager Scaleway : versions, protection et politique éphémère

Un secret qui vit dans un fichier de configuration finit dans un dépôt Git, et un secret dans un dépôt Git est un secret public. Secret Manager résout ce problème en le déplaçant : l'application ne détient plus la valeur, elle détient le droit de la demander au moment de s'en servir. Cette leçon construit ce chemin de bout en bout, du choix du type jusqu'à la suppression, et provoque volontairement les quatre erreurs qui coûtent le plus de temps quand on découvre le service.

Ce que vous allez apprendre

• Choisir le bon type parmi les six que l'API accepte, et savoir pourquoi ce choix est définitif.
• Créer un secret, y ajouter des versions, et comprendre laquelle une application lit.
• Protéger un secret contre la suppression, et connaître la commande qui retire cette protection.
• Poser une politique éphémère en sachant qu'elle ne se retire jamais.
• Distinguer la suppression immédiate de la suppression programmée à 7 jours.

Pourquoi un service dédié plutôt qu'un fichier chiffré ?

Parce qu'un fichier chiffré déplace le problème sans le résoudre : il faut encore distribuer la clé qui le déchiffre. C'est le serpent qui se mord la queue de la gestion des secrets, et il finit toujours de la même façon, avec la clé de déchiffrement dans une variable d'environnement du serveur de build.

Secret Manager casse cette boucle en s'appuyant sur une identité que vous avez déjà : celle de l'appelant. L'application ne présente pas un mot de passe pour obtenir un mot de passe, elle présente son identité IAM, et le service décide. Trois propriétés en découlent, et ce sont elles qui justifient le service plutôt qu'un fichier :

Ce que vous obtenez	Ce qu'un fichier chiffré ne donne pas
Révocation immédiate	il faut retrouver toutes les copies du fichier
Journal des accès	personne ne sait qui a lu le fichier, ni quand
Rotation sans redéploiement	changer la valeur impose de redéployer le fichier

Glissez pour voir

Le service chiffre par enveloppe en AES-256 et, d'après sa documentation, n'écrit jamais le secret en clair sur un stockage permanent : il le déchiffre à la demande et le transmet en TLS.

Ce que cette leçon suppose acquis

Vous devez savoir créer une application IAM et lui attacher une politique, parce que c'est ce qui donnera le droit de lecture. Si ce n'est pas le cas, lisez d'abord IAM Scaleway : donner le droit minimal à une CI, et le prouver, qui construit exactement cette identité.

Quel type de secret choisir, et pourquoi c'est définitif ?

Le type se choisit à la création et s'applique à toutes les versions suivantes : il ne se change plus. C'est la première décision irréversible du service, et elle passe souvent inaperçue parce que opaque accepte n'importe quoi.

Le CLI en accepte six, et la commande d'aide est la façon la plus sûre de vérifier ce que votre version propose :

scw secret secret create -h

La sortie doit contenir, sur la ligne [type], l'énumération suivante. Relevé le 10 septembre 2026 avec scw 2.62.0 :

(unknown_type | opaque | certificate | key_value | basic_credentials
 | database_credentials | ssh_key)

Type	Ce qu'il attend	Quand le choisir
basic_credentials	un identifiant et un mot de passe	un compte applicatif simple
database_credentials	moteur, identifiant, mot de passe, hôte, base, port	une base de données, pour que le format soit vérifié
key_value	un objet clé-valeur libre	plusieurs paramètres liés, à lire d'un bloc
ssh_key	une clé privée SSH	un accès machine automatisé
certificate	un certificat	une chaîne TLS applicative
opaque	n'importe quoi	quand aucun autre ne correspond, et seulement alors

Glissez pour voir

Le typage n'est pas cosmétique : il fait vérifier les champs obligatoires à votre place. Un database_credentials auquel il manque le port est refusé à l'écriture, avec un message qui nomme le champ manquant :

Invalid arguments 'data'
Details:
- 'data' is wrongly formatted
Hint:
- (root): port is required

C'est exactement le genre d'erreur qu'on préfère voir au moment de poser le secret plutôt qu'au premier démarrage en production. Un secret opaque, lui, accepte n'importe quoi et ne vous préviendra de rien. Mesuré le 10 septembre 2026 avec scw 2.62.0.

La documentation de référence en oublie un

La page officielle des types et formats JSON n'en documente que cinq : elle omet certificate, que le CLI accepte pourtant. Quand la documentation et le binaire divergent, c'est l'aide du CLI et l'API qui font foi pour ce que vous pouvez réellement créer, et la documentation qui fait foi pour le format JSON attendu. Relevé le 10 septembre 2026.

Créer un secret et y mettre une première version

Un secret est un contenant : sa valeur vit dans ses versions. La création du secret ne stocke donc aucune donnée, et c'est ce qui surprend au premier essai, avec un version_count à zéro.

1. Créez le contenant, en le nommant et en l'étiquetant pour le retrouver.

   scw secret secret create \
     name=demo-application \
     type=opaque \
     tags.0=formation \
     -o json

   La sortie doit afficher "status":"ready", "version_count":0 et "protected":false. Notez l'id renvoyé, toutes les commandes suivantes s'en servent.

2. Ajoutez la première version. La valeur se transmet telle quelle, sans encodage. Le CLI accepte aussi un fichier avec la syntaxe @/chemin/fichier, ce qui évite de faire passer un secret par l'historique du shell.

   SECRET_ID="<l-id-renvoye-ci-dessus>"
   scw secret version create secret-id="$SECRET_ID" data='mot-de-passe-initial'

   La sortie doit afficher "revision":1, "status":"enabled" et "latest":true.

3. Relisez la valeur, ce qui est la seule preuve que l'écriture a fonctionné.

   scw secret version access secret-id="$SECRET_ID" revision=latest -o json

   La sortie renvoie un champ data encodé en base64, qu'il faut décoder :

   scw secret version access secret-id="$SECRET_ID" revision=latest -o json \
     | python3 -c 'import json,sys,base64; print(base64.b64decode(json.load(sys.stdin)["data"]).decode())'

   La sortie doit afficher mot-de-passe-initial.

L'asymétrie qui fait perdre une heure : brut en écriture, base64 en lecture

Le service n'utilise pas le même format dans les deux sens, et rien ne le signale. C'est le piège le plus coûteux du service, parce qu'il ne produit aucune erreur sur un secret opaque.

Sens	Format attendu ou renvoyé
Écriture (version create data=…)	la valeur brute
Lecture (version access)	la valeur encodée en base64

Glissez pour voir

Le réflexe naturel, quand on voit du base64 en sortie, est d'en envoyer à l'entrée. Sur un secret opaque, cela fonctionne sans rien signaler : le service stocke consciencieusement votre chaîne base64 comme valeur, et vous récupérez à la lecture un base64 de base64. L'application qui consomme le secret reçoit alors une valeur illisible, et le diagnostic est long parce que toutes les commandes répondent avec succès.

Sur un secret typé, le même geste échoue au moins avec un message, même s'il est trompeur :

Invalid arguments 'data'
Details:
- 'data' is wrongly formatted
Hint:
Invalid json

Le message parle de JSON invalide alors que le JSON était valide : ce qui était invalide, c'est le fait de l'avoir encodé. Mesuré le 10 septembre 2026 avec scw 2.62.0.

Que devient l'ancienne version quand vous en ajoutez une nouvelle ?

Elle reste lisible, et c'est voulu. C'est la propriété la plus utile du service, et celle qui rend la rotation possible sans coupure : pendant qu'une partie de votre parc lit encore la version 1, l'autre bascule sur la version 2.

Mesuré le 10 septembre 2026 avec scw 2.62.0, sur un secret à deux versions :

Commande	Ce qu'elle renvoie
secret version access … revision=latest	la révision 2
secret version access … revision=1	la révision 1, toujours lisible

Glissez pour voir

Une conséquence pratique en découle immédiatement. Une application qui demande latest change de valeur sans prévenir, au moment où quelqu'un ajoute une version. C'est parfait pour une rotation voulue, et redoutable si l'ajout était une erreur. Sur un secret critique, épinglez donc un numéro de révision dans la configuration de l'application, et changez-le délibérément.

Une version se désactive sans être supprimée, ce qui la rend inaccessible tout en la conservant. C'est le geste à préférer pendant une rotation : on désactive l'ancienne, on vérifie que plus rien ne casse, et on ne supprime qu'ensuite.

Empêcher une suppression accidentelle

La protection est le seul mécanisme qui vous sauve d'un delete de trop, et elle se pilote par des commandes dédiées, ce qui n'est pas évident.

scw secret secret protect secret-id="$SECRET_ID"

La sortie doit afficher "protected":true. Tentez alors la suppression :

scw secret secret delete secret-id="$SECRET_ID"

Le message est sans ambiguïté :

scaleway-sdk-go: precondition failed: , cannot delete a protected secret

Le piège : `update` n'accepte pas `protected`

Le réflexe naturel est d'écrire scw secret secret update secret-id=… protected=false. Cela ne fonctionne pas, et le message est déroutant parce qu'il ne parle pas de protection :

unknown argument 'protected'

L'indication qui suit liste les arguments réellement acceptés par update, et protected n'y est pas. Ce sont deux sous-commandes distinctes qui le pilotent, secret protect et secret unprotect, et l'argument protected n'existe qu'à la création.

Le retrait se fait donc ainsi, et c'est la commande à noter avant d'en avoir besoin :

scw secret secret unprotect secret-id="$SECRET_ID"

La sortie doit afficher "protected":false. Mesuré le 10 septembre 2026 avec scw 2.62.0.

Une nuance importante : la protection couvre le secret, pas ses versions. La documentation officielle le dit explicitement, et c'est logique une fois compris que le secret est un contenant : vous pouvez supprimer toutes les versions d'un secret protégé, et vous retrouver avec un contenant intact et vide.

La politique éphémère, et pourquoi elle ne se retire pas

Une politique éphémère fait expirer les versions toutes seules, soit après un délai, soit après un premier accès. C'est le mécanisme à utiliser pour un jeton de bascule ou un mot de passe temporaire, dont l'oubli serait un risque.

scw secret secret create \
  name=demo-jeton-court \
  type=opaque \
  ephemeral-policy.time-to-live=60s \
  ephemeral-policy.action=delete \
  -o json

La sortie doit afficher un bloc ephemeral_policy complet, avec "time_to_live":"60.000000000s" et "action":"delete". Le délai accepté va d'une seconde à un an, et l'action au terme est soit delete, soit disable.

Cette politique se pose une fois, et pour toujours

Il n'existe aucune commande pour retirer une politique éphémère. La tentative naturelle échoue avec un message qui ne dit rien du caractère définitif :

Cannot unmarshal arg 'ephemeral-policy=null': missing field name for type secret.EphemeralPolicy

La conséquence est simple et coûteuse : un secret créé avec une politique éphémère verra ses versions disparaître, et le seul recours est de créer un autre secret puis de faire pointer les applications dessus. Sur un secret que plusieurs services consomment, cela veut dire une migration.

Ne posez donc jamais une politique éphémère « au cas où ». Posez-la quand le caractère temporaire est la raison d'être du secret, et jamais autrement. Mesuré le 10 septembre 2026 avec scw 2.62.0.

Suppression immédiate ou suppression programmée ?

Ce sont deux mécanismes différents, et confondre les deux fait croire à un filet de sécurité qui n'existe pas.

scw secret secret delete supprime immédiatement. Mesuré le 10 septembre 2026 sur un secret portant une version : le champ deletion_requested_at était à null avant la commande, la réponse a été « Secret has been successfully deleted. », et le secret avait quitté la liste dans la seconde.

La suppression programmée est un mécanisme distinct, qu'on demande explicitement. Elle place le secret dans une fenêtre de 7 jours pendant laquelle il reste lisible mais ni modifiable, ni accessible, ni supprimable, et pendant laquelle une récupération est possible. Cette récupération est facturée 0,01 € par version associée au secret.

	Suppression immédiate	Suppression programmée
Ce qui se passe	le secret disparaît	il entre dans une fenêtre de 7 jours
Récupération	aucune	possible, facturée 0,01 € par version
Pendant la fenêtre	sans objet	lecture possible, modification et accès refusés
Au terme	sans objet	suppression définitive de toutes les versions

Glissez pour voir

La discipline qui en découle : sur un secret de production, protégez-le plutôt que de compter sur une fenêtre de récupération que la commande par défaut ne déclenche pas.

Comment une application lit-elle son secret au démarrage ?

Une application ne lit pas un secret comme elle lit un fichier : elle s'authentifie d'abord, puis demande une valeur précise. Le chemin complet tient en quatre étapes, et il est identique quel que soit le langage. L'application démarre en portant une identité IAM, celle d'une application Scaleway à laquelle une politique donne le droit de lire les secrets d'un Project. Elle appelle ensuite l'API de Secret Manager en désignant le secret par son identifiant et la version par son numéro de révision, ou par le mot-clé latest. Le service vérifie la politique, déchiffre la valeur et la renvoie encodée en base64 sur une connexion TLS. L'application décode, garde la valeur en mémoire pour la durée de vie du processus, et ne l'écrit jamais sur disque ni dans ses journaux. La différence avec un fichier de configuration est là : la valeur n'a jamais existé ailleurs que dans la mémoire du processus qui en avait besoin, et le service sait exactement qui l'a demandée et quand.

Limites, quotas et plafonds

Les plafonds de Secret Manager sont bas et dépendent de l'état de votre compte, ce qui surprend sur un service qu'on imagine élastique. Les valeurs ci-dessous viennent de la page officielle des capacités et limites, et la dernière a été confirmée en lab.

Limite	Paiement validé	Identité validée aussi	Source
Secrets par Organisation	100	250	doc « capabilities and limits »
Versions par secret	20	20	doc « capabilities and limits »
Requêtes d'accès à la valeur	300 000	750 000	doc « capabilities and limits »
Taille d'une version	65 535 octets	65 535 octets	mesuré en lab, message d'erreur exact

Glissez pour voir

Le plafond de 20 versions par secret est celui qui arrive le plus vite, et il mérite une politique de rotation qui supprime les anciennes plutôt que de les empiler. Le plafond de taille, lui, vaut la peine d'être connu précisément : la FAQ officielle annonce « 64 KB », le message d'erreur du service dit 65 535 octets, soit 64 Kio moins un.

Vérifier la disponibilité par région plutôt que la mémoriser

La FAQ officielle annonce Secret Manager dans trois régions, Paris, Amsterdam et Varsovie. Le catalogue public de Scaleway, interrogé le 10 septembre 2026, le donne dans les quatre, Milan comprise. La FAQ est en retard, ce qui illustre la méthode posée dans régions et zones : le catalogue est la source la plus fraîche, la prose des pages produit l'est rarement.

Ce que ça coûte

La facturation porte sur deux choses seulement : les versions stockées et les requêtes d'accès. Une version est facturée tant qu'elle est activée ou désactivée ; seule sa suppression arrête le compteur, ce qui explique pourquoi désactiver une version ne fait pas baisser la facture.

Le prorata s'applique à la journée : une version conservée cinq jours est facturée cinq jours, pas le mois. Et la récupération d'un secret en suppression programmée coûte 0,01 € par version associée.

La conséquence opérationnelle est contre-intuitive. Sur un service aussi peu cher, le poste qui dérive n'est pas le stockage mais le nombre d'appels : une application qui relit son secret à chaque requête plutôt qu'au démarrage consomme le quota d'accès et la ligne de facture. Mettez la valeur en cache pour la durée de vie du processus, et relisez-la sur événement, pas sur chaque requête.

Secret Manager sous l'angle Well-Architected

Security : qui peut lire ce secret, et comment le prouver ?

La question clé : si l'identité d'une de vos applications fuite, quels secrets devient-elle capable de lire ?

La réponse ne se lit pas dans Secret Manager mais dans la politique IAM attachée à l'appelant. Un jeu de permissions large donne accès à tous les secrets du périmètre, et le service n'a aucun moyen de deviner que ce n'était pas l'intention.

La discipline : une politique par usage, limitée au Project qui porte les secrets concernés, et jamais un jeu de permissions général sur l'Organisation. La preuve se fait comme dans la leçon IAM, en tentant une lecture depuis une identité qui ne devrait pas l'avoir et en vérifiant le refus.

Operational Excellence : que se passe-t-il quand vous faites tourner ce secret ?

La question clé : votre rotation est-elle une opération sans coupure, ou un redémarrage global ?

Les versions rendent la rotation sans coupure possible, à condition que les applications ne demandent pas toutes latest au même instant. La séquence sûre est : ajouter la version, basculer les consommateurs un par un, désactiver l'ancienne, vérifier que rien ne casse, puis supprimer.

La discipline : épingler une révision sur les secrets critiques, et n'utiliser latest que là où un changement de valeur inattendu est acceptable.

Cost Optimization : qui paie les versions que personne ne lit ?

La question clé : combien de versions dorment dans vos secrets, activées ou désactivées, et donc facturées ?

Le plafond de 20 versions par secret protège d'une dérive infinie, mais il ne supprime rien : il bloque simplement l'ajout suivant, au pire moment.

La discipline : une politique de rétention décidée dès le premier secret, et un contrôle périodique du nombre de versions par secret, version_count étant renvoyé par secret secret list.

Pièges courants

Ces quatre situations ont toutes été provoquées en lab le 10 septembre 2026 avec scw 2.62.0. Les messages sont ceux que le service renvoie, mot pour mot.

Symptôme	Cause	Solution
unknown argument 'protected'	update ne gère pas la protection, contrairement à ce que le nom laisse croire	utiliser scw secret secret protect ou unprotect
scaleway-sdk-go: precondition failed: , cannot delete a protected secret	le secret est protégé, ce qui est le comportement voulu	retirer la protection avec unprotect, puis supprimer
Must be between 1 and 65535 bytes long	la version dépasse la taille maximale	stocker une référence volumineuse ailleurs et garder le secret pour la clé d'accès
Hint: Invalid json alors que le JSON est valide	la valeur a été encodée en base64 avant d'être envoyée	envoyer la valeur brute : le base64 ne concerne que la lecture
Hint: - (root): port is required	un champ obligatoire du type manque dans le JSON	compléter le JSON selon le format du type, documenté par Scaleway
Cannot unmarshal arg 'ephemeral-policy=null': missing field name for type secret.EphemeralPolicy	on tente de retirer une politique éphémère, ce qui n'existe pas	créer un nouveau secret sans politique et migrer les consommateurs
scaleway-sdk-go: precondition failed: , cannot act on deleted resource	on agit sur un secret déjà supprimé, souvent dans un script de nettoyage rejoué	rendre le nettoyage idempotent en ignorant cette erreur précise

Glissez pour voir

Antipatterns à éviter

Ces cinq erreurs ont un point commun : elles reproduisent, dans Secret Manager, l'habitude qu'on cherchait justement à quitter. Déplacer un secret dans un service dédié ne sert à rien si on continue de le traiter comme un fichier.

Antipattern	Conséquence	Discipline
Copier la valeur dans une variable d'environnement au déploiement	le secret revit dans la configuration, et dans les journaux de déploiement	l'application lit le secret à l'exécution, par l'API
Demander latest sur un secret critique	une version ajoutée par erreur bascule la production sans prévenir	épingler un numéro de révision, et le changer délibérément
Poser une politique éphémère « par prudence »	elle ne se retire jamais : migration forcée le jour où le secret doit durer	la réserver aux secrets dont le caractère temporaire est la raison d'être
Relire le secret à chaque requête	le quota d'accès et la facture suivent le trafic	mettre en cache pour la durée de vie du processus
Empiler les versions sans en supprimer	le plafond de 20 bloque l'ajout au moment d'une rotation urgente	supprimer les versions obsolètes dans la foulée de chaque rotation

Glissez pour voir

Nettoyer

Un secret protégé résiste à la suppression : c'est tout son intérêt, et c'est ce qui fait échouer un nettoyage naïf. L'ordre ci-dessous tient compte de cette dépendance.

1. Retirez la protection de tout secret qui en porte une.

   scw secret secret unprotect secret-id="$SECRET_ID"

2. Supprimez les secrets créés pendant la leçon.

   scw secret secret delete secret-id="$SECRET_ID"

   La sortie doit afficher « Secret has been successfully deleted. »

3. Vérifiez le retour à zéro, sans quoi vous ne savez pas ce qui reste.

   scw secret secret list -o json

   La sortie doit être une liste vide, [].

Supprimer le secret supprime toutes ses versions, donc toute la facturation associée. Il n'y a pas de reste discret sur ce service, contrairement au stockage : c'est l'un des rares où le nettoyage se vérifie d'une seule commande.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Un secret est un contenant, la valeur vit dans ses versions : version_count vaut 0 juste après la création, et ce n'est pas une anomalie.
• Le type se fixe à la création et s'applique à toutes les versions suivantes. Six sont acceptés par scw 2.62.0, dont certificate, que la documentation de référence omet.
• Les révisions antérieures restent lisibles après l'ajout d'une nouvelle : c'est ce qui rend la rotation sans coupure possible.
• On écrit en clair et on lit en base64. Envoyer du base64 à l'écriture stocke le base64 lui-même, sans aucune erreur sur un secret opaque.
• update ne gère pas la protection : ce sont secret protect et secret unprotect, et l'argument protected n'existe qu'à la création.
• Une politique éphémère ne se retire jamais : ephemeral-policy=null échoue, et le seul recours est un nouveau secret.
• delete supprime immédiatement, sans fenêtre de récupération. Les 7 jours relèvent de la suppression programmée, qui est un mécanisme distinct.
• La taille maximale d'une version est de 65 535 octets, message d'erreur à l'appui, là où la FAQ arrondit à 64 KB.
• 20 versions par secret est le plafond qui arrive le plus vite, et il bloque l'ajout au pire moment si aucune rétention n'a été décidée.

Pour aller plus loin

• Terraform : provisionner, et surtout détruire : le provider sait lire un secret pour alimenter une ressource, ce qui évite de le poser en clair dans le code.
• Ansible au quotidien : exploiter ce qui existe déjà : la rotation d'un secret est une opération de Day-2, pas de provisionnement.

Ressources externes

• Documentation Secret Manager : les concepts, les guides pas à pas et la référence de l'API.
• Capacités et limites de Secret Manager : les quotas par Organisation, à relire avant de dimensionner.
• Types de secrets et formats JSON attendus : la structure exacte que chaque type attend, indispensable pour database_credentials.
• Chiffrement des données dans Secret Manager : le détail du chiffrement par enveloppe employé par le service.

×

📖 Voir la documentation →