Lab fil rouge sécurité : une application qui lit un secret, et rien d'autre

Le moindre privilège ne se prouve pas par ce qui marche, il se prouve par ce qui est refusé. Ce lab de synthèse assemble tout le volet en un seul scénario : un projet dédié qui sert de frontière, une application IAM avec sa politique et une clé qui expire, un secret qu'elle doit lire, une clé de chiffrement qu'elle doit utiliser, et l'Audit Trail qui raconte ce qu'elle a tenté. Vous vérifierez que le chemin nominal fonctionne, puis vous ferez volontairement échouer la même clé sur ce qui déborde de sa politique. Vous finirez par un démontage complet, y compris d'un objet que Scaleway a créé sans vous le dire.

Ce que vous allez faire

• Poser un projet, une application, une politique et une clé qui expire.
• Choisir le jeu de permissions qui autorise vraiment la lecture d'une valeur.
• Prouver le moindre privilège par deux refus exacts.
• Lire dans l'Audit Trail ce que l'application a tenté, refus compris.
• Détruire dans l'ordre, y compris ce que Scaleway a créé pour vous.

Que va coûter ce lab, et pendant combien de temps ?

Presque rien, et c'est ce qui en fait un bon terrain de répétition. IAM, les projets et l'Audit Trail sont gratuits. Secret Manager et Key Manager se facturent au secret, à la clé et à l'appel, pour des montants de l'ordre du centime sur une session d'une heure.

Le seul poste qui compte, si vous ajoutez l'étape facultative sur les listes filtrées, est l'Instance que vous créerez quelques minutes. Comptez une session de quarante minutes, largement sous le centime pour les briques de sécurité.

Étape 1 : pourquoi commencer par un projet dédié ?

Parce qu'une politique IAM a besoin d'une frontière, et que le projet est la seule qui existe. Les jeux de permissions de Secret Manager et de Key Manager ont tous une portée projects : sans projet séparé, « limiter » une application revient à lui ouvrir tout votre compte.

1. Créez le projet qui servira de périmètre.

   PROJ=$(scw account project create name=capstone-secu -o json | jq -r .id)
   scw account project list -o json

   La sortie doit afficher deux projets : le vôtre et celui-ci.

2. Créez l'application, c'est-à-dire l'identité non humaine.

   APP=$(scw iam application create name=capstone-app -o json | jq -r .id)
   scw iam application get "$APP" -o json

   La sortie doit afficher le nom et un id.

Quel jeu de permissions autorise vraiment à lire un secret ?

SecretManagerSecretAccess, et surtout pas SecretManagerReadOnly. C'est le piège central de ce lab, et son nom le rend invisible : « ReadOnly » laisse croire qu'il donne la lecture, alors qu'il ne donne que la lecture des métadonnées, pas de la valeur.

Mesuré le 11 septembre 2026 avec scw 2.62.0 : une politique portant SecretManagerReadOnly échoue à lire la valeur du secret avec

scaleway-sdk-go: insufficient permissions: access secret

La liste des jeux disponibles répond elle-même à la question, et c'est le bon réflexe plutôt que de deviner :

scw iam permission-set list -o json

La sortie doit contenir SecretManagerSecretAccess, décrit « Retrieve the plaintext value of secret versions ». La formulation est explicite là où le nom ne l'était pas.

Lisez ce tableau par la colonne Besoin : partez de ce que votre application doit faire, jamais du nom de jeu qui vous paraît le plus proche.

Besoin	Jeu à choisir	Pourquoi pas l'autre
Lister les secrets et voir leurs versions	SecretManagerReadOnly	il s'arrête aux métadonnées
Lire la valeur d'une version	SecretManagerSecretAccess	seul jeu décrit « Retrieve the plaintext value »
Créer un secret ou une version	SecretManagerSecretCreate	lire n'implique jamais écrire
Tout faire, suppression comprise	SecretManagerFullAccess	à réserver à un humain, pas à une chaîne d'intégration

Glissez pour voir

La leçon dépasse Secret Manager. Un nom de jeu de permissions est un libellé commercial, pas un contrat : la description est la seule source, et elle se lit avant d'écrire la politique. Cette page a coûté une passe de lab entière pour l'apprendre.

Étape 2 : la politique et la clé qui expire

1. Créez la politique, limitée au projet et aux trois jeux nécessaires.

   POL=$(scw iam policy create name=capstone-pol application-id="$APP" \
     rules.0.project-ids.0="$PROJ" \
     rules.0.permission-set-names.0=SecretManagerSecretAccess \
     rules.0.permission-set-names.1=KeyManagerKeyEncrypt \
     rules.0.permission-set-names.2=KeyManagerKeyDecrypt \
     -o json | jq -r .id)
   scw iam policy get "$POL" -o json

   La sortie doit afficher la règle avec le project_ids attendu.

2. Créez la clé d'API, avec une date d'expiration.

   EXP=$(date -u -d '+2 hours' +%Y-%m-%dT%H:%M:%SZ)
   scw iam api-key create application-id="$APP" expires-at="$EXP" -o json > cle.json
   
   AK=$(jq -r .access_key cle.json)
   SK=$(jq -r .secret_key cle.json)
   ORG=$(scw config get default-organization-id)

   La sortie affiche access_key et secret_key. La partie secrète n'est montrée qu'une fois : notez-la immédiatement.

L'expiration n'est pas facultative

Sans expires-at, la création échoue :

organization security settings require an expiration date for API keys

Ce n'est pas une règle du produit mais un réglage de sécurité de votre Organisation, que vous consultez avec scw iam security-settings get. Une Organisation qui ne l'impose pas laissera passer des clés éternelles, ce qui est précisément ce que ce réglage existe pour empêcher.

Étape 3 : le secret et la clé de chiffrement

Ces deux ressources se créent avec votre profil, celui de l'Organisation : l'application n'a pas le droit de les créer, et c'est voulu.

SECRET=$(scw secret secret create name=capstone-secret \
  project-id="$PROJ" region=fr-par -o json | jq -r .id)
printf 'mot-de-passe-du-capstone' > /tmp/val.txt
scw secret version create secret-id="$SECRET" data=@/tmp/val.txt region=fr-par -o json

KEY=$(scw keymanager key create name=capstone-key project-id="$PROJ" \
  region=fr-par usage.symmetric-encryption=aes_256_gcm -o json | jq -r .id)

La sortie de la version doit afficher "revision":1 et "status":"enabled".

Étape 4 : la clé restreinte fait-elle son travail ?

C'est le chemin nominal, et il doit réussir avant qu'on s'intéresse aux refus. Une politique qui ne laisse rien passer n'est pas du moindre privilège, c'est une panne.

La clé restreinte s'utilise par variables d'environnement, sans jamais toucher votre configuration :

env SCW_ACCESS_KEY="$AK" SCW_SECRET_KEY="$SK" \
    SCW_DEFAULT_PROJECT_ID="$PROJ" SCW_DEFAULT_ORGANIZATION_ID="$ORG" \
  scw secret version access secret-id="$SECRET" revision=latest region=fr-par -o json

La sortie doit ressembler à ceci, relevée le 11 septembre 2026 :

{"secret_id":"6cc5b648-…","revision":1,"data":"bW90LWRlLXBhc3NlLWR1LWNhcHN0b25l","type":"opaque"}

La valeur revient encodée en base64, comme partout dans Secret Manager. Elle se décode en mot-de-passe-du-capstone :

echo "bW90LWRlLXBhc3NlLWR1LWNhcHN0b25l" | base64 -d

Key Manager échoue en silence sur du texte brut

L'aide de la commande est explicite mais facile à survoler : plaintext est une donnée « Base64 Plaintext ». Avec du texte brut, l'API ne renvoie aucune erreur et un ciphertext vide, et le script qui ne relit pas sa sortie croit avoir chiffré.

# ✅ correct
scw keymanager key encrypt key-id="$KEY" \
  plaintext="$(printf 'donnee-sensible' | base64)" region=fr-par -o json

Aller-retour vérifié : le chiffré commence par AQAAAAE… et le déchiffré, décodé, redonne donnee-sensible. Contrôlez toujours que le ciphertext n'est pas vide avant de considérer un chiffrement comme fait.

Étape 5 : prouver le moindre privilège par le refus

Une autorisation qui réussit ne prouve rien sur ce qui est interdit. Il faut tenter ce qui doit échouer, et lire le message.

env SCW_ACCESS_KEY="$AK" SCW_SECRET_KEY="$SK" … \
  scw secret secret create name=interdit project-id="$PROJ" region=fr-par

env SCW_ACCESS_KEY="$AK" SCW_SECRET_KEY="$SK" … \
  scw keymanager key delete key-id="$KEY" region=fr-par

Les deux sorties doivent afficher un refus explicite :

scaleway-sdk-go: insufficient permissions: create secret
scaleway-sdk-go: insufficient permissions: delete key

Ces deux lignes sont le vrai livrable de ce lab. Elles disent que la clé posée dans une chaîne d'intégration ne peut pas créer de secret, ni détruire la clé de chiffrement, même si elle fuite.

Une liste vide n'est ni une absence, ni un refus

Voici le résultat le plus contre-intuitif de ce lab, mesuré le 11 septembre 2026 avec une Instance bien réelle dans le projet.

La clé de l'Organisation voit 1 Instance. La clé restreinte, qui n'a aucun droit sur les Instances, reçoit [] et un code de retour 0 : ni erreur, ni avertissement. Mais un accès direct à cette même Instance est refusé sans ambiguïté :

scaleway-sdk-go: insufficient permissions: read compute_servers

IAM filtre les listes en silence et ne refuse explicitement que les lectures directes. La conséquence pratique est sérieuse : un script de vérification de fin de session qui utilise une clé restreinte conclura que le compte est vide alors qu'il ne l'est pas. Vos contrôles de retour à zéro se font donc avec une clé qui voit tout, sans quoi ils mesurent leur propre aveuglement.

Étape 6 : que raconte l'Audit Trail ?

Il nomme l'application, et il enregistre aussi ce qu'elle n'a pas eu le droit de faire. C'est ce qui permet de repérer une clé qui cherche à déborder de son périmètre.

scw audit-trail event list region=fr-par -o json

Sur le lab, deux événements portaient l'identifiant de l'application comme principal : CreateSecret et DeleteKey. Les deux avaient été refusés. Une tentative bloquée laisse donc une trace, et c'est exactement le signal qu'une supervision doit remonter.

L'Audit Trail est asynchrone : comptez une vingtaine de secondes avant qu'un événement apparaisse. Un script qui interroge immédiatement après l'action ne trouvera rien et conclura à tort.

Étape 7 : dans quel ordre tout détruire ?

Le tableau ci-dessous est le vrai résumé du lab : il dit quel objet bloque la suppression de quel autre, et chaque ligne a été provoquée volontairement.

Vous supprimez	Ce qui bloque	Message exact	L'ordre correct
le projet	tout ce qu'il contient encore	resource is still in use, all resources are not deleted	vider le projet d'abord
un secret protégé	sa propre protection	cannot delete a protected secret	secret unprotect puis delete
une clé Key Manager protégée	sa protection	même famille de message	key unprotect puis delete
le projet, alors qu'il paraît vide	le groupe de sécurité par défaut créé par Scaleway	message générique, aucune mention du groupe	supprimer le groupe à la main
l'application	rien : elle part même avec sa politique	aucun	supprimer quand même la politique, sinon elle reste

Glissez pour voir

1. Libérez les protections, puis supprimez secret et clé.

   scw secret secret unprotect secret-id="$SECRET" region=fr-par
   scw secret secret delete secret-id="$SECRET" region=fr-par
   scw keymanager key unprotect key-id="$KEY" region=fr-par
   scw keymanager key delete key-id="$KEY" region=fr-par

2. Supprimez la clé d'API, la politique, puis l'application.

   scw iam api-key delete access-key="$AK"
   scw iam policy delete policy-id="$POL"
   scw iam application delete application-id="$APP"

3. Supprimez le projet, en nommant l'argument.

   scw account project delete project-id="$PROJ"

   La sortie doit afficher Project has been successfully deleted.

4. Vérifiez le retour à zéro sur chaque famille, avec une clé qui voit tout.

   scw iam application list -o json
   scw secret secret list region=fr-par -o json
   scw keymanager key list region=fr-par -o json
   scw account project list -o json

   Les trois premières doivent être vides, la dernière ne doit plus contenir que vos projets habituels.

Le positionnel ne marche pas sur un argument optionnel

Passer l'identifiant sans le nommer produit un message déroutant :

Invalid argument '63b1049a-…': arg name must only contain lowercase letters, numbers or dashes

La règle, vérifiable dans l'aide : le CLI accepte un positionnel pour un argument obligatoire, jamais pour un argument optionnel. Or scw account project delete déclare [project-id] entre crochets, donc optionnel, parce qu'il vaut par défaut le projet de votre configuration. Il se nomme donc toujours.

Ce que ce lab a prouvé

• Le chemin nominal fonctionne : une clé ne portant que trois jeux de permissions lit la valeur d'un secret et chiffre une donnée, sans aucun autre droit.
• Le moindre privilège tient, et se lit dans deux refus : insufficient permissions: create secret et insufficient permissions: delete key.
• Un nom de jeu de permissions ment : SecretManagerReadOnly ne lit pas les valeurs, SecretManagerSecretAccess le fait, et seule la description le dit.
• Key Manager échoue en silence sur du texte brut, renvoyant un chiffré vide sans erreur ni code de retour non nul.
• Une liste vide n'est pas une preuve : la clé restreinte reçoit [] là où la clé de l'Organisation voit une Instance, et seul un accès direct révèle le refus.
• Une tentative refusée est journalisée, avec l'application comme auteur, une vingtaine de secondes après coup.
• Scaleway crée un objet que vous n'avez pas demandé, le groupe de sécurité par défaut, et il bloque la suppression du projet sans jamais se nommer.

Limites, quotas et plafonds

Ces valeurs encadrent ce que vous venez de construire. Elles se relèvent toutes en lecture, sans rien créer.

Limite	Valeur	Source
Portée des jeux Secret Manager et Key Manager	projects, sans exception	scw iam permission-set list, 2.62.0, 2026-09-11
Jeux Key Manager distincts	10, dont Encrypt, Decrypt, Sign, Verify, Wrap, Unwrap	scw iam permission-set list
Jeux Secret Manager distincts	7, dont SecretAccess séparé de ReadOnly	scw iam permission-set list
Expiration des clés d'API	imposée par les réglages de l'Organisation	scw iam security-settings get
Délai d'apparition dans l'Audit Trail	environ 20 secondes	mesuré en lab le 2026-09-11
Encodage des valeurs de secret et de plaintext	base64 dans les deux sens	aide du CLI et sorties du lab

Glissez pour voir

Le lab fil rouge sous l'angle Well-Architected

Security : que peut faire votre clé si elle fuite ?

La question clé : si la clé posée dans votre chaîne d'intégration se retrouve dans un dépôt public, quel est le pire scénario ?

Ici, la réponse est bornée et vérifiée : lire un secret et chiffrer, dans un seul projet, pendant deux heures. Elle ne peut ni créer, ni supprimer, ni voir les autres produits.

La discipline : écrire la politique en partant de ce qu'on accepte de perdre, puis prouver les refus, parce qu'une politique non testée est une intention.

Operational Excellence : sauriez-vous dire ce que cette clé a tenté ?

La question clé : disposez-vous d'une trace des actions refusées, et pas seulement des actions réussies ?

L'Audit Trail enregistre les deux, avec l'application comme auteur. Une clé qui tente régulièrement ce qu'elle n'a pas le droit de faire est soit mal configurée, soit compromise.

La discipline : surveiller les refus autant que les réussites, et se rappeler qu'un délai d'une vingtaine de secondes sépare l'action de sa trace.

Cost Optimization : que reste-t-il après un lab de sécurité ?

La question clé : un projet supprimé emporte-t-il tout ce qu'il contenait ?

Non : il refuse de partir tant qu'il reste quoi que ce soit, y compris un objet que vous n'avez jamais créé. Les briques de ce lab coûtent peu, mais un projet fantôme masque des ressources qui, elles, peuvent coûter.

La discipline : vérifier le retour à zéro avec une clé qui voit tout, et traiter un refus de suppression de projet comme l'indice qu'il reste une ressource à trouver.

Pièges courants

Chacun de ces messages a été provoqué volontairement le 11 septembre 2026 avec scw 2.62.0.

Symptôme	Cause	Solution
organization security settings require an expiration date for API keys	la clé est créée sans expires-at	ajouter expires-at au format RFC 3339
insufficient permissions: access secret malgré SecretManagerReadOnly	ce jeu ne donne que les métadonnées	utiliser SecretManagerSecretAccess
Un ciphertext vide, sans aucune erreur	plaintext doit être en base64	plaintext="$(printf '…' | base64)"
Invalid argument '<uuid>': arg name must only contain lowercase letters…	un positionnel sur un argument optionnel	nommer l'argument : project-id=<id>
resource is still in use, all resources are not deleted	le projet contient encore une ressource	chercher le groupe de sécurité par défaut
cannot delete a protected secret	la protection est active	secret unprotect avant delete
Une liste vide avec une clé restreinte	IAM filtre le résultat au lieu de refuser	vérifier avec une clé qui voit tout

Glissez pour voir

Antipatterns à éviter

Ces cinq erreurs se ressemblent : elles concluent d'une absence de message que tout va bien, alors que le silence ne prouve rien.

Antipattern	Conséquence	Discipline
Choisir un jeu de permissions sur son nom	ReadOnly ne lit pas les valeurs, l'application échoue en production	lire la description renvoyée par permission-set list
Tester une politique uniquement sur ce qui doit marcher	ce qui est interdit n'a jamais été vérifié	tenter au moins deux actions qui doivent échouer
Vérifier un compte vide avec une clé restreinte	la liste filtrée fait croire au retour à zéro	contrôler avec une clé qui voit tout
Chiffrer sans relire le ciphertext	la donnée n'est pas chiffrée, et rien ne le signale	échouer explicitement si le chiffré est vide
Créer des clés d'API sans expiration	une clé fuitée reste valable indéfiniment	imposer l'expiration au niveau de l'Organisation

Glissez pour voir

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

• Le projet est la seule frontière d'une politique IAM : tous les jeux Secret Manager et Key Manager ont la portée projects.
• SecretManagerSecretAccess lit la valeur d'un secret, SecretManagerReadOnly ne lit que les métadonnées, et seul le champ description le dit.
• expires-at est imposé par les réglages de sécurité de l'Organisation : sans lui, la création de clé est refusée.
• Les valeurs de Secret Manager reviennent en base64, et keymanager key encrypt en attend en entrée.
• Un chiffrement sur du texte brut renvoie un ciphertext vide sans erreur : le contrôler est la seule parade.
• Le moindre privilège se prouve par un refus : insufficient permissions: create secret vaut mieux que n'importe quelle capture d'écran.
• Une liste vide obtenue avec une clé restreinte ne prouve rien : IAM filtre les listes et ne refuse explicitement que les accès directs.
• L'Audit Trail journalise les tentatives refusées et nomme l'application, environ vingt secondes après coup.
• Le groupe de sécurité par défaut, créé par Scaleway, bloque la suppression du projet sans jamais apparaître dans le message d'erreur.
• scw account project delete veut project-id= : le CLI n'accepte un positionnel que pour un argument obligatoire.

Pour aller plus loin

• Terraform sur Scaleway : provisionner et détruire pour de vrai : déclarer projet, application et politique plutôt que de les recréer à la main à chaque lab.
• Packer : construire une image durcie : la suite logique, une image qui embarque déjà ce que cette politique protège.

Ressources externes

• Jeux de permissions IAM : la liste officielle et la description exacte de chaque jeu.
• Documentation Secret Manager : le cycle de vie des versions, la protection et l'encodage des valeurs.
• Documentation Key Manager : les usages de clés, le chiffrement d'enveloppe et la rotation.
• Documentation Audit Trail : les produits couverts et la structure d'un événement.

×

📖 Voir la documentation →