IAM Scaleway : donner le droit minimal à une CI, et le prouver

Une chaîne d'intégration qui déploie avec une clé d'administration est la faille la plus banale d'un compte cloud, et la plus facile à refermer. Cette leçon pose le modèle IAM de Scaleway en cinq briques, puis vous fait construire l'identité d'une CI Terraform limitée à un seul Project, avec une clé qui expire. Vous terminerez par l'étape que presque personne ne fait : prouver que la restriction tient, par une écriture refusée puis dans Audit Trail, en découvrant au passage qu'une lecture interdite ne renvoie pas une erreur.

Ce que vous allez apprendre

• Distinguer un utilisateur d'une application, et savoir lequel porte une clé.
• Composer une politique à partir d'un principal, de jeux de permissions et d'une portée.
• Créer une clé API qui expire, parce que votre organisation peut l'exiger.
• Vérifier une restriction par une écriture, jamais par une lecture, puis la retrouver dans Audit Trail.
• Nettoyer sans toucher aux rôles gérés par Scaleway.

Le modèle IAM en cinq briques

Tout se ramène à une phrase : une politique donne à un principal des jeux de permissions sur une portée, éventuellement sous condition. Retenez ces cinq mots et vous saurez lire n'importe quelle configuration IAM Scaleway.

Brique	Ce que c'est	Exemple concret
Principal	qui reçoit les droits	une utilisatrice, une application, un groupe
Jeu de permissions	ce qu'on a le droit de faire	InstancesFullAccess, BillingReadOnly
Portée	où ces droits s'appliquent	un Project précis, plusieurs, ou toute l'Organization
Condition	sous quelle réserve	seulement depuis une adresse IP, avant une date, ou sur une ressource précise
Politique	l'objet qui assemble le tout	une ou plusieurs règles, un seul principal

Glissez pour voir

Une contrainte structure toute votre organisation IAM : une politique ne porte qu'un seul principal. Vous ne pouvez pas attacher la même politique à trois personnes. Pour un droit partagé, la réponse est un groupe : on écrit la politique une fois, on l'attache au groupe, et on gère ensuite les entrées et les sorties de personnes. Deux groupes gérés existent depuis le 2 septembre 2026, All Users et All Applications, à membres dynamiques : commodes pour une lecture partagée, dangereux pour tout ce qui écrit, puisque chaque nouveau membre en hérite. Une politique ne sait qu'accorder : il n'existe pas de règle « interdire », le point de départ de tout principal est zéro droit, et une modification met jusqu'à une minute à s'appliquer.

Regardez ce que votre organisation propose comme vocabulaire de permissions, c'est le catalogue dans lequel vous piocherez :

scw iam permission-set list -o json \
  | python3 -c 'import sys,json; d=json.load(sys.stdin); print(len(d), "jeux disponibles"); [print(" ", p["name"]) for p in d if p["name"].startswith("Instances")]'

La sortie doit afficher le nombre de jeux, puis les quatre jeux Instances (InstancesFullAccess, InstancesReadOnly, InstancesServerStart, InstancesServerStop). Relevé le 2026-09-08 avec scw 2.56.3 : le catalogue compte 179 jeux de permissions, et il en comptait 178 quelques heures plus tôt le même jour : ce nombre bouge à chaque produit ajouté, relancez la commande plutôt que de le retenir. Leurs noms se lisent seuls : InstancesReadOnly autorise la lecture, InstancesFullAccess tout le reste. C'est volontairement plus grossier qu'une permission unitaire, et c'est ce qui rend l'ensemble utilisable.

Utilisateur ou application : qui doit porter la clé API ?

Un utilisateur est une personne, une application est un robot. La distinction n'est pas cosmétique : une application n'a aucun accès à la console, elle n'existe que par sa clé API. C'est exactement ce qu'on veut pour une chaîne d'intégration.

	Utilisateur	Application
Correspond à	une personne	un programme, une CI, un script
Accès à la console	oui	non, jamais
S'authentifie par	mot de passe, deuxième facteur, clé API	clé API uniquement
Ce qu'on fait à son départ	on le retire de l'Organization	on supprime l'application et sa clé
Quota par Organization	50	100

Glissez pour voir

Le tableau se lit par la colonne Choix : trouvez le besoin, il dit quel principal porte la clé.

Besoin	Choix	Pourquoi
Une personne qui travaille depuis la console et son poste	utilisateur	mot de passe, MFA, sessions ; sa clé API expire et se révoque avec elle
Une CI, Terraform, un script planifié, un agent	application	aucun accès console, survit aux départs, s'inventorie
Un droit partagé par une équipe	groupe avec une politique	on gère les membres, pas les politiques
Un accès temporaire à un prestataire	utilisateur membre avec politique limitée et date de fin	retirable de l'Organization en une action

Glissez pour voir

La faute classique consiste à créer une clé API sur son propre compte d'utilisateur et à la coller dans une CI. Cette clé porte alors tous vos droits, y compris la facturation et la gestion IAM. Elle survit à votre départ, personne ne sait plus à quoi elle sert, et elle n'apparaît dans aucun inventaire d'accès. Une application coûte une commande de plus et retire tout cela.

Lab : le droit minimal pour une CI Terraform

Objectif : une identité qui peut déployer dans un Project et rien qu'un Project. Tous les objets créés ici sont gratuits.

1. Créez le Project cible

   La portée d'une politique s'appuie sur les Projects : sans séparation, il n'y a rien à restreindre.

   PROJ=$(scw account project create name=lab-ci-cible -o json \
     | python3 -c 'import sys,json; print(json.load(sys.stdin)["id"])')
   echo "Project cible : $PROJ"

2. Créez l'application, c'est-à-dire l'identité de la CI

   APP=$(scw iam application create name=ci-terraform \
     description="Deploiement CI, un seul Project" -o json \
     | python3 -c 'import sys,json; print(json.load(sys.stdin)["id"])')
   scw iam application list

   La liste doit afficher ci-terraform.

3. Écrivez la politique

   Trois jeux de permissions suffisent à déployer une petite stack, et la portée se limite au Project créé à l'étape 1.

   POL=$(scw iam policy create name=ci-deploy \
     application-id=$APP \
     rules.0.project-ids.0=$PROJ \
     rules.0.permission-set-names.0=InstancesFullAccess \
     rules.0.permission-set-names.1=VPCFullAccess \
     rules.0.permission-set-names.2=BlockStorageFullAccess \
     -o json | python3 -c 'import sys,json; print(json.load(sys.stdin)["id"])')

   Relisez ce qui a été enregistré, c'est le seul moyen de savoir ce que la politique accorde réellement :

   scw iam rule list policy-id=$POL -o json \
     | python3 -c 'import sys,json; [print(r["permission_set_names"], "->", r["project_ids"]) for r in json.load(sys.stdin)]'

   La sortie doit afficher les trois jeux, suivis de l'identifiant du seul Project cible.

4. Créez la clé API portée par l'application

   EXPIRE=$(date -u -d "+30 days" +%Y-%m-%dT%H:%M:%SZ)
   scw iam api-key create application-id=$APP expires-at=$EXPIRE \
     default-project-id=$PROJ description="cle de la CI"

   La clé secrète ne s'affiche qu'une seule fois. Copiez-la immédiatement dans le coffre de votre chaîne d'intégration ; si vous la perdez, il faut en créer une autre. scw iam api-key list doit ensuite montrer la clé avec son échéance.

Le refus qui est une bonne nouvelle

Si la création de la clé échoue sur ce message :

organization security settings require an expiration date for API keys

votre organisation impose déjà une durée de vie maximale aux clés API. C'est un garde-fou, pas une gêne : il rend la rotation obligatoire au lieu de la laisser à la bonne volonté de chacun.

Vous pouvez lire le réglage en vigueur :

scw iam security-settings get

La sortie lisible affiche MaxAPIKeyExpirationDuration 365 days. En JSON, le même réglage apparaît sous son nom d'API et en secondes, ce qui est la forme à utiliser dans un script :

scw iam security-settings get -o json

"max_api_key_expiration_duration":"31536000.000000000s"

Sur une organisation qui n'a pas encore posé ce réglage, sa valeur est 0, ce qui signifie aucune durée maximale. C'est la première chose à activer : une clé sans date d'expiration est une clé que personne ne révoquera jamais.

Comment prouver qu'une restriction tient ?

Une politique qu'on n'a pas testée est une hypothèse. Configurez un profil séparé avec la clé de la CI, puis mesurez ce qu'elle peut et ne peut pas faire.

cat > ~/.config/scw/ci.yaml <<'EOF'
access_key: SCWXXXXXXXXXXXXXXXXX
secret_key: votre-cle-secrete
default_organization_id: votre-organization-id
default_project_id: votre-project-cible
default_region: fr-par
default_zone: fr-par-1
EOF
chmod 600 ~/.config/scw/ci.yaml

Toutes les commandes qui suivent utilisent ce profil avec -c, ce qui garantit que vous testez bien la clé restreinte et non la vôtre.

Une lecture interdite ne renvoie pas d'erreur

C'est le résultat qui compte le plus dans cette leçon, et il prend tout le monde à contrepied. Mesuré en lab : avec la clé d'administration, le Project par défaut contient un groupe de sécurité. Avec la clé restreinte, la même commande sur le même Project renvoie :

[]

Une liste vide, pas un refus. Les ressources hors de votre portée sont filtrées silencieusement, comme si elles n'existaient pas. Vous ne pouvez donc jamais conclure d'un résultat vide que la restriction fonctionne : le Project était peut-être simplement vide.

En écriture, le comportement est l'inverse, et il est sans ambiguïté :

scaleway-sdk-go: insufficient permissions: create compute_security_groups

Vérifiez donc toujours une restriction par une tentative d'écriture. C'est la seule qui produise une réponse exploitable, et c'est aussi celle qui compte vraiment : un attaquant qui lit vous coûte moins cher qu'un attaquant qui crée.

Les quatre contrôles à passer, dans cet ordre :

Ce qu'on tente	Résultat attendu
Créer une ressource dans le Project cible	réussite : la CI peut travailler
Créer une ressource dans un autre Project	insufficient permissions
Lire la facturation	insufficient permissions
Créer une clé API avec cette clé	insufficient permissions

Glissez pour voir

Le dernier contrôle est le plus important et le plus oublié : une identité qui peut créer des clés API peut se donner tous les droits. Si votre politique inclut par mégarde un jeu de permissions IAM, la restriction que vous venez d'écrire ne vaut rien, puisque la CI peut la contourner en fabriquant une nouvelle identité.

La seconde preuve : Audit Trail a tout vu

Un refus mesuré dans le terminal est une preuve pour vous ; un refus dans Audit Trail est une preuve pour un auditeur. Chaque tentative, réussie ou refusée, est enregistrée avec le principal, l'adresse d'origine et le statut. Relisez les événements de la dernière heure :

scw audit-trail event list region=fr-par -o json \
  | python3 -c 'import sys,json; [print(e["recorded_at"][:19], e["principal"]["id"][:8], e["product_name"], e["method_name"], e["status_code"]) for e in json.load(sys.stdin)]'

La sortie doit montrer les créations de l'application et de la politique en 200, la création du groupe de sécurité dans le Project cible en 200 ou 201, et la tentative hors périmètre en 403, portées par l'identifiant de l'application ci-terraform. Mesuré le 2026-09-08 : les événements DeleteApplication (200) et DeleteSecurityGroup (204) du nettoyage y figurent avec l'agent scaleway-cli/2.56.3. C'est ce journal, exporté chaque jour vers un bucket, qui répondra dans six mois à la question « qui a essayé quoi ».

Aller plus loin que le Project : les conditions

Depuis le 15 juillet 2026, une politique peut restreindre au niveau de la ressource, et depuis plus longtemps au niveau de la requête ; pour une CI, deux conditions valent d'être connues. L'argument rules.0.condition de scw iam policy create accepte une expression CEL. Une CI dont on connaît l'adresse publique de sortie peut être bornée par request.ip == "203.0.113.10" ; une CI qui ne doit tourner qu'en journée par request.time.getHours("Europe/Paris") > 7 && request.time.getHours("Europe/Paris") < 20. Au niveau de la ressource, trois produits sont intégrés au 13 juillet 2026, IAM, Key Manager et Secret Manager : une CI peut ainsi lire un seul dossier de secrets (resource.name.startsWith("/ci/")) plutôt que tout le coffre. La leçon d'ouverture du volet détaille les variables disponibles.

Pourquoi une clé API a-t-elle un Project préféré pour l'Object Storage ?

Les outils compatibles S3 ne savent pas transmettre d'identifiant de Project. L'interface S3 n'a pas ce paramètre, et Scaleway a donc rattaché l'information à la clé elle-même : c'est le rôle de default-project-id que vous avez passé à la création.

La conséquence surprend le jour où elle se manifeste : une même clé utilisée avec aws-cli, rclone ou s3cmd travaille par défaut dans son Project préféré, quel que soit le contexte. Un bucket créé depuis la console dans un autre Project reste alors introuvable, sans message d'erreur explicite.

Deux sorties existent, et il vaut mieux les connaître avant de multiplier les clés. Le Project préféré s'édite après coup :

scw iam api-key update VOTRE_ACCESS_KEY default-project-id=UN_AUTRE_PROJECT

Et il se surcharge appel par appel, en suffixant la clé d'accès par l'identifiant du Project visé :

aws_access_key_id = SCWXXXXXXXXXXXXXXXXX@votre-project-id

Dans les deux cas, la politique doit évidemment couvrir ce Project : la surcharge change la cible, elle n'accorde aucun droit. Une clé par Project reste la solution la plus lisible quand plusieurs équipes se partagent le stockage, mais ce n'est plus une obligation technique.

Nettoyer

Rien de tout cela n'est facturé, mais une identité oubliée est une porte ouverte que personne ne surveille. On supprime dans l'ordre inverse de la création.

rm -f ~/.config/scw/ci.yaml
scw iam api-key delete VOTRE_ACCESS_KEY
scw iam policy delete $POL
scw iam application delete $APP
scw account project delete project-id=$PROJ

La vérification de sortie porte sur les trois familles :

scw iam application list
scw iam policy list
scw account project list

Les politiques nommées Administrators, Editors et Billing Administrators sont créées par Scaleway, chacune attachée à son groupe, et doivent rester ; il en va de même des cinq groupes (All Users, All Applications et les trois groupes de rôle). Ce ne sont pas des restes de lab.

Limites, quotas et plafonds

Ces valeurs viennent de la page des quotas d'Organisation (validée le 2025-10-29), de la doc des politiques et du lab du 2026-09-08.

Plafond	Valeur	Source
Clés API par Organisation	50 (page des quotas) ; la FAQ IAM dit 100, écart signalé	quotas, FAQ IAM
Applications	100	quotas d'Organisation
Groupes, politiques, utilisateurs	50 chacun	quotas d'Organisation
Principal par politique	1	doc « Understanding IAM policies »
Sens des règles	accorder seulement, aucune règle « interdire »	doc « Understanding IAM policies »
Délai d'application	jusqu'à 1 minute	doc « Understanding IAM policies »
Jeux de permissions	179 relevés le 2026-09-08, chiffre mobile	scw iam permission-set list
Durée maximale d'une clé	réglable par l'Organisation ; 0 = illimité ; 365 jours sur l'organisation de test	scw iam security-settings get
Description d'une clé, d'une politique	200 caractères ; nom de politique 64	aide de scw iam policy create et api-key create
Produits à conditions au niveau ressource	3 au 13 juillet 2026 : IAM, Key Manager, Secret Manager	doc « Products supporting resource-level conditions »
Événements Audit Trail	conservés 90 jours en export ; IAM enregistré à Paris	concepts et FAQ Audit Trail

Glissez pour voir

Antipatterns à éviter

Ces erreurs ont un point commun : IAM les accepte sans un mot, et elles se découvrent dans un rapport d'incident.

Antipattern	Conséquence	Discipline
Clé API d'un humain dans une CI	la CI porte facturation et IAM, et survit au départ	une application par robot
Un jeu IAM… ou AllProductsFullAccess sur une identité de déploiement	elle se réécrit ses droits ; la restriction ne vaut rien	jamais de permission IAM sur un robot, et le quatrième contrôle
Conclure d'une lecture vide que la restriction tient	lecture hors périmètre filtrée en silence	preuve par écriture, puis Audit Trail
Politique attachée à All Applications pour aller vite	toute nouvelle application hérite du droit	groupe nommé à membres explicites
Clé sans expiration parce que l'organisation ne l'impose pas	clé éternelle, jamais tournée	expires-at systématique, et max_api_key_expiration_duration posé
Supprimer une politique Editors « inutile »	rôle géré par Scaleway, membres privés de leurs droits	ne toucher qu'à ce que le lab a créé

Glissez pour voir

L'IAM sous l'angle Well-Architected

Security : une identité par robot, zéro permission IAM, une preuve

Que peut faire cette clé si elle fuit ce soir ? Créer des Instances, des réseaux et des volumes dans un seul Project, pendant au plus trente jours, et rien d'autre : ni lire la facture, ni créer une clé, ni toucher un autre Project. La discipline est celle du lab, avec en plus une condition sur l'adresse de sortie de la CI quand elle est connue, et un export Audit Trail qui garde la trace des refus.

Operational Excellence : lisible et rotatif

Quelqu'un saura-t-il, dans six mois, à quoi sert ci-terraform ? Oui, si l'application porte son usage dans son nom et sa description, si la politique s'appelle ci-deploy et vise un Project nommé, et si la clé expire, ce qui force la question à se reposer à chaque rotation. La discipline est une revue trimestrielle de scw iam api-key list (échéances, descriptions) et de scw iam policy list.

Pièges courants

Le tableau se lit par la colonne Symptôme : c'est ce que vous voyez à l'écran, message exact compris quand il y en a un ; la colonne Cause dit ce qui se passe réellement, et la colonne Solution la commande ou le geste qui débloque.

Symptôme	Cause	Solution
require an expiration date for API keys	l'organisation impose une durée de vie maximale	ajouter expires-at=<date ISO 8601>
Une lecture hors périmètre renvoie [] au lieu d'une erreur	les ressources hors portée sont filtrées en silence	vérifier la restriction par une écriture, jamais par une lecture
insufficient permissions: create compute_security_groups	la politique ne couvre pas ce Project ou ce produit	relire scw iam rule list policy-id=… ; c'est la preuve attendue hors périmètre
La clé secrète est introuvable	elle n'est affichée qu'à la création	en créer une nouvelle et révoquer l'ancienne
Impossible d'attacher une politique à deux personnes	une politique n'a qu'un seul principal	créer un groupe et attacher la politique au groupe
Un outil S3 écrit dans le mauvais Project	la clé porte un Project préféré appliqué par défaut	l'éditer avec api-key update, ou suffixer la clé par @project-id
La CI peut se donner de nouveaux droits	un jeu de permissions IAM traîne dans la politique	retirer toute permission IAM d'une identité de déploiement
Une clé d'ancien collaborateur encore active	la clé était portée par un utilisateur, pas une application	porter les accès machine par des applications
La politique semble sans effet juste après sa création	délai d'application jusqu'à 1 minute	attendre, puis retester

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

• Une politique donne à un principal des jeux de permissions sur une portée, éventuellement sous condition. Cinq mots, tout le modèle ; les règles accordent seulement, à partir de zéro droit.
• Une politique ne porte qu'un seul principal. Le droit partagé passe par un groupe, jamais par la duplication ; les groupes gérés All Users et All Applications (2 septembre 2026) donnent à tout le monde, y compris aux arrivants.
• Une application n'a pas accès à la console : c'est l'identité correcte pour une CI, un script ou un agent ; 100 applications et 50 clés API par Organisation.
• Une clé API créée sur un compte humain porte tous les droits de cette personne et lui survit. C'est la faille la plus banale.
• Une clé API doit expirer, et l'organisation peut l'imposer via max_api_key_expiration_duration (0 = illimité par défaut).
• Une lecture hors périmètre renvoie une liste vide, pas une erreur. Un résultat vide ne prouve rien.
• Seule une tentative d'écriture prouve une restriction, et Audit Trail l'enregistre en 403.
• Une identité de déploiement ne doit jamais porter de permission IAM, sinon elle peut se réécrire ses propres droits.
• Depuis le 15 juillet 2026, les conditions au niveau ressource (IAM, Key Manager, Secret Manager) et les conditions de requête (IP, heure) bornent une CI plus finement qu'un Project.
• Une clé API travaille dans son Project préféré avec les outils compatibles S3 ; ce réglage s'édite après coup et se surcharge par <access-key>@<project-id>.

Pour aller plus loin

• Terraform : provisionner, et surtout détruire : L'application qui vient d'être créée devient l'identité qui exécute le déploiement.
• Packer : construire une image, et vérifier ce qu'elle laisse : Le même moindre privilège appliqué à une chaîne de construction d'images.
• Ansible : exploiter ce que Terraform a provisionné : Où la clé de cette application finit par vivre, et ce qu'elle a le droit d'y faire.

Ressources externes

Les pages officielles sur lesquelles cette leçon s'appuie, avec ce qu'on y cherche ; leur champ de validation date chaque fait cité.

• IAM concepts : le vocabulaire officiel, principal, règle, portée, condition, Project préféré.
• Understanding IAM policies : un principal par politique, règles qui accordent, délai d'application, exemple JSON.
• Permission sets : le catalogue complet, à consulter avant d'écrire une politique.
• Request-level conditions : restreindre par adresse IP, agent ou horaire, avec la syntaxe CEL.
• Organization quotas : clés, applications, groupes, politiques et utilisateurs par Organisation.

×

📖 Voir la documentation →