Organiser un compte pour la production

Pourquoi

À la fin du cours Le cloud : les fondamentaux, Signalements tenait dans un seul projet, signalements, avec une application IAM pour le pipeline, un groupe de lecture pour les développeurs et votre compte pour le reste. C'était suffisant pour une mairie. Un an plus tard, la situation a changé :

• trois métropoles utilisent l'application, et l'une d'elles exige une préproduction sur laquelle elle valide chaque version avant sa mise en service ;
• l'équipe compte maintenant six personnes : deux développeurs, deux personnes d'exploitation, une cheffe de projet qui suit la facture, un prestataire qui intervient sur la base de données une semaine par trimestre ;
• un audit de sécurité demandé par une métropole a relevé trois points : des clés d'API sans date d'expiration, des personnes qui ont plus de droits que leur rôle n'en demande, et l'absence de règle écrite sur qui peut toucher à la production.

Rien de tout cela ne se règle en créant une ressource de plus. Cela se règle en organisant le compte : où vivent les ressources, qui a le droit de faire quoi, à quel endroit, depuis où, et comment l'organisation elle-même est protégée. Une organisation mal découpée est coûteuse à réorganiser : déplacer des ressources d'un projet à l'autre n'est pas toujours possible, et chaque politique écrite dans l'urgence devient une exception que personne n'ose retirer.

La leçon 7 du cours précédent a posé les mécanismes : principaux, politiques, jeux de permissions, clés, second facteur, fédération. Celle-ci les assemble pour une équipe réelle, avec les limites que Scaleway documente au 5 octobre 2026.

Les concepts

Ce qu'un projet sépare, et ce qu'il ne sépare pas

Rappel de la leçon 7 : une organisation porte la facturation et l'IAM, ses projets regroupent les ressources. Ce qui compte pour l'organisation de la production, c'est ce que le projet sépare réellement :

Deux conséquences. D'abord, un projet est une frontière de droits, pas une frontière de sécurité au sens fort : tout ce qui est réglé au niveau de l'organisation (quotas, réglages de sécurité, facturation, IAM lui-même) reste commun. Ensuite, une organisation compte au plus 25 projets, que le moyen de paiement seul ou l'identité soient validés : c'est la valeur de la page des quotas de Scaleway, et elle ne se négocie pas comme un quota d'instances. Un découpage « un projet par application, par environnement et par équipe » épuise vite ce stock.

Trois découpages possibles

Pour Signalements, le troisième découpage s'impose : la métropole qui valide en préproduction ne doit jamais pouvoir toucher à la production, et l'équipe ne doit pas pouvoir casser la préproduction d'une autre application. Au-delà d'une douzaine d'applications, on passe à plusieurs organisations (une par entité ou par client), ce que Scaleway permet : un même utilisateur peut être membre de plusieurs organisations et passer de l'une à l'autre dans la console.

Le projet default reste, et ne peut pas être supprimé. On n'y met rien, ce qui rend toute ressource qui y apparaît suspecte par construction.

Des rôles, pas des personnes

Une politique attachée à une personne est une dette : elle part avec elle, ou pire, reste. La règle d'or de l'IAM, valable chez tous les fournisseurs, est de décrire des rôles en groupes, d'attacher les politiques aux groupes, puis de placer les personnes dans les groupes. Pour l'équipe de Signalements :

Trois remarques sur ce tableau.

Les jeux de permissions ont une portée. La documentation des permission sets les range en deux familles : ceux qui s'appliquent à l'organisation (IAMManager, ProjectManager, BillingReadOnly, BillingManager, OrganizationManager, SupportTicketManager...) et ceux qui s'appliquent à des projets (tout ce qui touche aux produits). Une règle a soit un organization-id, soit des project-ids, et un jeu de permissions d'organisation n'a de sens que dans une règle d'organisation. C'est pourquoi le groupe sig-dev a besoin de deux règles dans sa politique, une par projet, avec des jeux différents.

Le grain va jusqu'à l'action. Pour les instances, la liste ne s'arrête pas à InstancesFullAccess et InstancesReadOnly : on trouve InstancesServerStart, InstancesServerSerialConsoleAccess, InstancesImageCreate, InstancesSecurityGroupWrite et une cinquantaine d'autres. Le stockage objet distingue lecture des objets, écriture, suppression, et politique de bucket ; Secret Manager distingue la lecture des métadonnées (SecretManagerReadOnly) et la lecture des valeurs (SecretManagerSecretAccess). Ce grain permet d'écrire des rôles précis, au prix de politiques plus longues. On commence large et lisible, on affine là où le risque le justifie : l'accès à la console série d'une instance, la suppression d'objets, la lecture des secrets.

Certains jeux valent tout. La documentation l'écrit en toutes lettres : quiconque bénéficie de IAMManager ou OrganizationManager peut se créer des politiques qui lui donnent accès à toutes les autres actions et ressources de l'organisation. Le groupe iam-admins est donc l'équivalent du propriétaire, et se traite comme tel : deux personnes, second facteur obligatoire, et revue de chaque ajout.

Les conditions : depuis où, quand, sur quoi

Une règle peut porter une condition, une expression écrite en CEL (Common Expression Language, le langage d'expressions conçu par Google et repris par Kubernetes et plusieurs fournisseurs). Si la condition est fausse, la règle ne s'applique pas. Au 5 octobre 2026, la documentation de Scaleway, réorganisée en juillet 2026, distingue deux familles.

Les conditions sur la requête portent sur trois variables :

Les conditions sur la ressource, plus récentes, portent sur la ressource visée : resource.name, resource.id et resource.locality (une région, une zone, ou global). Elles ne sont prises en charge que par trois produits au 5 octobre 2026 : IAM, Key Manager et Secret Manager. Elles servent par exemple à ne donner à une application que les secrets d'un dossier (resource.name.startsWith("/signalements/"), leçon 8), ou que les clés d'une région.

Deux propriétés de l'évaluation sont essentielles, et la documentation les détaille :

• Les politiques s'additionnent. Si une politique avec condition refuse une action, mais qu'une autre politique sans condition l'autorise, l'action est autorisée. Une condition ne restreint donc que la règle qui la porte : pour qu'une restriction soit réelle, il ne doit exister aucune autre règle plus large pour le même principal.
• La console et l'API ne vérifient que la syntaxe. Une expression impossible à satisfaire (resource.locality == "fr-par-1" && resource.locality == "fr-par-3") est acceptée sans avertissement. On teste donc chaque condition après l'avoir écrite.

La sécurité de l'organisation

La leçon 7 a présenté les mesures de sécurité de l'organisation : second facteur imposé, méthodes d'authentification permises, SAML et SCIM. Elles se règlent dans la console, rubrique Security des réglages de l'organisation, et une partie d'entre elles par la CLI, avec scw iam security-settings :

La documentation précise trois comportements qu'il faut connaître avant de régler quoi que ce soit :

• la durée maximale des clés ne touche que les nouvelles clés ; les clés existantes gardent leur expiration, ou leur absence d'expiration, et l'on ne peut pas modifier l'expiration d'une clé existante : on la révoque et on en crée une autre ;
• la durée maximale des sessions, à l'inverse, s'applique aussi aux sessions en cours, dans l'heure ;
• un membre qui ne respecte pas une exigence à la fin du délai de grâce est verrouillé, et ne retrouve l'accès que si quelqu'un le déverrouille.

Quotas et plans de support

Les quotas limitent le nombre de ressources d'une organisation, par produit et par type. Leurs valeurs dépendent du niveau du compte : moyen de paiement validé, puis identité vérifiée, puis demande au support. Quelques valeurs de la page des quotas, au 5 octobre 2026, avec un moyen de paiement et une identité validés : 100 clés d'API, 100 applications, 50 groupes, 50 politiques, 50 utilisateurs, 25 projets, 50 clés SSH ; pour les instances, 5 PRO2-XXS et 4 PRO2-XS. L'envoi de courriels en SMTP depuis les instances n'est permis qu'aux comptes dont l'identité est validée. Plusieurs de ces chiffres sont bas pour une production : 50 politiques, c'est peu si l'on écrit une politique par personne ; 5 instances d'un type, c'est peu pour un groupe d'autoscaling (leçon 2).

Les plans de support déterminent qui vous répond, et en combien de temps, le jour où quelque chose ne va pas chez le fournisseur. La page Understanding Support plans les décrit :

La documentation qualifie le plan Business de « prérequis pour les charges de production ». C'est un argument commercial, mais il pose la bonne question : avec le plan Basic, un ticket ouvert à 22 h pour une base de données injoignable reçoit une première réponse au plus tard à 6 h du matin. Ce délai est-il compatible avec ce que vous avez promis à vos clients ?

L'empreinte environnementale

Scaleway publie pour chaque organisation une estimation de son empreinte environnementale : émissions de gaz à effet de serre (en kgCO2eq) et consommation d'eau, par projet, par région, par zone et par catégorie de produits. La méthode suit le référentiel de l'ADEME pour les services d'hébergement et de cloud (PCR), en analyse de cycle de vie : la fabrication des serveurs compte, pas seulement l'électricité. Elle s'appuie sur l'efficacité énergétique (PUE) et hydrique (WUE) de chaque centre de données, et sur le mix électrique du pays, issu des données d'Ember.

Ce sont des estimations fondées sur des facteurs moyens, pas des mesures de votre consommation réelle ; elles permettent surtout de comparer : deux régions, deux types d'instances, avant et après un redimensionnement. Elles intéressent de plus en plus les clients publics, qui doivent rendre compte de l'empreinte de leurs services numériques.

En pratique

On réorganise le compte de Signalements : deux projets, cinq groupes, leurs politiques, les réglages de sécurité, puis un premier relevé d'empreinte. Les commandes ont été vérifiées avec l'aide de scw 2.62 ; elles s'exécutent avec un profil qui a les droits IAMManager et ProjectManager sur l'organisation (votre compte de propriétaire, une dernière fois, ou un membre du futur groupe iam-admins).

Créer les projets par environnement

$ ORGA=$(scw config get default-organization-id)
$ PREPROD=$(scw account project create name=signalements-preprod \
    description="Signalements : préproduction, validation par les métropoles" -o json | jq -r .id)
$ PROD=$(scw account project create name=signalements-prod \
    description="Signalements : production" -o json | jq -r .id)
$ echo "$PREPROD $PROD"

L'ancien projet signalements du cours précédent devient, selon votre situation, la préproduction (en le renommant avec scw account project update) ou un projet à vider puis supprimer. Les ressources d'un projet ne changent pas de projet d'un coup de baguette : la plupart se recréent, et c'est l'occasion de les décrire en code (cours Terraform et OpenTofu : les fondamentaux).

Ajoutez un profil scw par projet, pour ne jamais créer une ressource de production par erreur depuis un terminal resté sur la préproduction :

$ scw config profile activate default
$ scw -p sig-prod init         # même clé, projet par défaut : signalements-prod
$ scw -p sig-preprod init      # même clé, projet par défaut : signalements-preprod

scw -p <profil> init crée ou complète le profil nommé dans ~/.config/scw/config.yaml ; à la question du projet par défaut, choisissez l'identifiant correspondant. La leçon 1 du cours précédent détaille l'ordre de priorité des profils.

Créer les groupes et leurs politiques

Les groupes d'abord :

$ for g in sig-dev sig-exploitation sig-finance sig-prestataire-db iam-admins; do
    scw iam group create name="$g" description="Rôle $g" -o json | jq -r '"\(.name) \(.id)"'
  done

Puis une politique par groupe. Celle des développeurs a deux règles, une par projet :

$ DEV=$(scw iam group list name=sig-dev -o json | jq -r '.[] | select(.name == "sig-dev") | .id')
$ scw iam policy create name=sig-dev \
    description="Développeurs : tout en préproduction, lecture en production" \
    group-id="$DEV" \
    rules.0.project-ids.0="$PREPROD" \
    rules.0.permission-set-names.0=AllProductsFullAccess \
    rules.1.project-ids.0="$PROD" \
    rules.1.permission-set-names.0=AllProductsReadOnly \
    tags.0=signalements

• rules.N.project-ids.0 fixe le périmètre de la règle N ; une règle ne peut avoir qu'un type de périmètre.
• tags.0=signalements étiquette la politique : scw iam policy list tag=signalements retrouvera toutes celles de l'application. La CLI accepte au plus dix étiquettes par politique.
• Le filtre select(.name == "sig-dev") protège d'une mauvaise surprise : l'option name= des commandes list cherche souvent une sous-chaîne, et sig-dev trouverait aussi un futur sig-dev-externe.

La politique du groupe d'exploitation énumère les produits de la production, sans l'IAM ni la facturation :

$ EXPL=$(scw iam group list name=sig-exploitation -o json | jq -r '.[] | select(.name == "sig-exploitation") | .id')
$ scw iam policy create name=sig-exploitation \
    description="Exploitation : produits de la production, tout en préproduction" \
    group-id="$EXPL" \
    rules.0.project-ids.0="$PROD" \
    rules.0.permission-set-names.0=InstancesFullAccess \
    rules.0.permission-set-names.1=RelationalDatabasesFullAccess \
    rules.0.permission-set-names.2=LoadBalancersFullAccess \
    rules.0.permission-set-names.3=PrivateNetworksFullAccess \
    rules.0.permission-set-names.4=ObjectStorageFullAccess \
    rules.0.permission-set-names.5=ObservabilityFullAccess \
    rules.1.project-ids.0="$PREPROD" \
    rules.1.permission-set-names.0=AllProductsFullAccess

Avant d'écrire une liste comme celle-ci, consultez les jeux disponibles : scw iam permission-set list -o json | jq -r '.[] | [.name, .scope_type] | @tsv' les affiche avec leur portée (organisation ou projets). La liste change avec les produits, et un nom mal orthographié fait échouer la création de la politique.

La cheffe de projet n'a besoin que de la facture, qui est un objet de l'organisation :

$ FIN=$(scw iam group list name=sig-finance -o json | jq -r '.[] | select(.name == "sig-finance") | .id')
$ scw iam policy create name=sig-finance group-id="$FIN" \
    rules.0.organization-id="$ORGA" \
    rules.0.permission-set-names.0=BillingReadOnly

Le prestataire : une condition sur la requête

Le prestataire intervient sur la base, depuis les locaux de son entreprise, aux heures ouvrées. On l'exprime dans la règle :

$ PRESTA=$(scw iam group list name=sig-prestataire-db -o json \
    | jq -r '.[] | select(.name == "sig-prestataire-db") | .id')
$ scw iam policy create name=sig-prestataire-db group-id="$PRESTA" \
    description="Prestataire base de données : production, semaine, heures ouvrées, depuis ses locaux" \
    rules.0.project-ids.0="$PROD" \
    rules.0.permission-set-names.0=RelationalDatabasesFullAccess \
    rules.0.condition='request.ip == "198.51.100.20" && request.time.getDayOfWeek("Europe/Paris") >= 1 && request.time.getDayOfWeek("Europe/Paris") <= 5 && request.time.getHours("Europe/Paris") >= 8 && request.time.getHours("Europe/Paris") < 19'

L'expression se lit de gauche à droite : depuis l'adresse publique 198.51.100.20 (une adresse de documentation, à remplacer par celle du prestataire), du lundi (1) au vendredi (5), de 8 h à 18 h 59, heure de Paris. getDayOfWeek renvoie 0 pour le dimanche, selon la spécification de CEL. Indiquez toujours le fuseau horaire : sans lui, les fonctions de date travaillent en UTC, et la fenêtre se décale d'une ou deux heures selon la saison.

Trois points de vigilance, tous documentés :

• la condition ne restreint que cette règle ; si le prestataire est aussi dans un autre groupe qui donne accès à la base, il garde cet accès en dehors de la fenêtre ;
• une condition fondée sur l'heure peut mettre jusqu'à une minute à produire son effet ;
• dans la console, une condition existante ne se modifie que dans l'éditeur de code ; l'assistant visuel ne sert qu'à la création.

Pour vérifier les règles effectivement enregistrées :

$ POL=$(scw iam policy list group-ids.0="$PRESTA" -o json | jq -r '.[0].id')
$ scw iam rule list "$POL" -o json | jq '.[] | {permission_set_names, project_ids, condition}'

Régler la sécurité de l'organisation

Lisez d'abord les réglages actuels, puis fixez une durée maximale de 90 jours aux nouvelles clés et de 12 heures aux sessions de console :

$ scw iam security-settings get
$ scw iam security-settings update \
    max-api-key-expiration-duration=2160h \
    max-login-session-duration=12h \
    grace-period-duration=72h

La CLI lit ces durées avec la fonction ParseDuration du langage Go (c'est visible dans son code, internal/args/unmarshal.go) : l'unité la plus grande est l'heure, d'où 2160h pour 90 jours. Une valeur comme 90d est refusée.

Activez ensuite, dans la console, le second facteur obligatoire (section Organization Multifactor Authentication) : la documentation ne décrit pas d'option de CLI pour ce réglage au 5 octobre 2026. Prévenez l'équipe avant : chacun a trois jours, par défaut, pour activer son second facteur, faute de quoi son compte est verrouillé.

Enfin, inventoriez les clés qui ne respectent pas encore la nouvelle règle, puisqu'elle ne s'applique qu'aux nouvelles clés :

$ scw iam api-key list -o json \
    | jq -r '.[] | select(.expires_at == null) | [.access_key, (.application_id // .user_id), .description] | @tsv'

Chaque ligne est une clé sans expiration. Pour chacune : identifier son usage, créer une remplaçante avec une expiration, la déployer, puis supprimer l'ancienne (scw iam api-key delete <clé d'accès>).

Les contacts

Deux réglages de la console, souvent oubliés, comptent en production :

• les notifications de facturation (factures, alertes de budget, moyen de paiement qui expire) peuvent être envoyées à des membres de l'organisation ou à des adresses externes, qui ne pourront pas se connecter. Donnez-les à une boîte d'équipe, pas à une personne ;
• les signalements d'abus (contenu illicite, attaque partie d'une de vos instances) arrivent à l'organisation, et la documentation prévient qu'une ressource objet d'un abus non traité peut être verrouillée par Scaleway. Quelqu'un doit lire ces messages, chaque jour.

Relever l'empreinte environnementale

Les données détaillées se lisent par l'API, pour une période et des filtres donnés :

$ scw environmental-footprint data get \
    start-date=2026-09-01T00:00:00Z end-date=2026-10-01T00:00:00Z \
    project-ids.0="$PROD" -o json > empreinte-septembre.json
$ scw environmental-footprint report list start-date=2026-01-01T00:00:00Z

La première commande renvoie les données d'impact de septembre pour la production, ventilables par région, zone et catégorie de produit (regions.N, zones.N, product-categories.N les filtrent) ; la date de fin est exclusive. La seconde liste les rapports PDF mensuels et annuels disponibles, que scw environmental-footprint report get télécharge. Un relevé mensuel, versé au tableau de bord de l'application, suffit à rendre visible l'effet d'une décision comme l'arrêt de la préproduction la nuit.

Pour connaître le cycle de vie des offres que vous utilisez (bêta, disponibilité générale, fin de commercialisation), l'API Product Catalog est interrogeable sans écrire de code :

$ scw product-catalog product list product-types.0=instance zone=fr-par-1 -o json \
    | jq -r '.[] | [.product, .status] | @tsv' | head

Elle sert à vérifier, avant de choisir un type d'instance ou de base pour cinq ans, qu'il n'est pas déjà en fin de commercialisation.

Sous le capot

Comment une requête est autorisée. Pour chaque appel d'API, le service IAM part du porteur de la clé (utilisateur ou application), collecte les politiques qui le visent directement ou par ses groupes, garde les règles dont le périmètre contient la ressource visée (son projet, ou l'organisation), évalue leurs conditions, et autorise l'action si au moins une règle restante contient un jeu de permissions qui l'inclut. Il n'existe pas de règle de refus : tout ce qui n'est pas explicitement autorisé est refusé, et une autorisation ne peut pas être annulée par une autre politique. C'est le modèle le plus simple à raisonner, et le plus facile à rendre trop large.

Pourquoi une condition sur la ressource casse les listes. Une requête list ne vise aucune ressource particulière : il n'y a pas de resource.id à évaluer. La documentation l'indique : une règle avec une condition sur la ressource fait échouer les listes, sauf à ajouter || !has(resource.id) à l'expression. Ce détail révèle le fonctionnement : la condition est évaluée une fois par requête, avec les attributs disponibles à ce moment-là, et non sur chaque élément du résultat. C'est aussi pourquoi resource.name, modifiable par quiconque peut renommer la ressource, est déconseillé au profit de resource.id : renommer un secret en /signalements/... suffirait à le faire entrer dans le périmètre.

Les ressources IAM que Scaleway crée pour vous. Quand vous créez un cluster Kapsule, Scaleway crée automatiquement un groupe qui contient les nœuds, sous forme d'applications invisibles, et une politique qui leur donne des droits par défaut. Ces créations apparaissent dans les journaux IAM, attribuées à Scaleway ; la politique ne peut pas être modifiée, seulement supprimée. Un inventaire IAM qui ne connaît pas ce mécanisme trouvera des groupes « que personne n'a créés ». Le cours Kapsule : Kubernetes managé chez Scaleway y revient.

Pièges courants

Épuiser les 25 projets. Un projet par branche, par développeur ou par essai paraît propre jusqu'au jour où il n'en reste plus pour un nouveau client. Réservez les projets aux frontières de droits durables ; les essais vont dans un projet bac-a-sable vidé chaque semaine.

Une condition qui ne restreint rien. Le prestataire a la règle conditionnelle, mais il a aussi été ajouté au groupe sig-exploitation « pour dépanner ». Les politiques s'additionnent : la condition ne sert plus à rien. Vérifiez les groupes d'une personne, pas seulement la politique que vous venez d'écrire.

Une condition horaire sans fuseau. request.time.getHours() >= 8 est évalué en UTC : en été, la fenêtre s'ouvre à 10 h à Paris. Toujours getHours("Europe/Paris").

Un réglage qui verrouille l'équipe. Imposer le second facteur le vendredi soir, avec un délai de grâce de trois jours, verrouille le lundi matin tous ceux qui n'ont pas lu leurs courriels du week-end. De même, désactiver la seule méthode d'authentification d'un membre (par exemple le mot de passe, quand il n'a pas de SSO) l'enferme dehors. Annoncez, puis appliquez.

Croire que la durée maximale a réglé le problème des clés. Elle ne touche que les nouvelles clés. Les anciennes clés sans expiration restent valides indéfiniment tant que personne ne les remplace.

Une erreur de syntaxe passée inaperçue. La console et l'API valident la syntaxe d'une condition, pas sa logique. Une faute de frappe dans une adresse IP produit une règle valide qui ne s'applique jamais, et un prestataire qui appelle le support le lundi matin.

Les quotas découverts le jour de l'incident. La leçon 3 du cours précédent l'a rappelé : un plan de reprise qui suppose de recréer dix instances bute sur un quota de cinq. Lisez la page des quotas en écrivant le plan.

Sécurité

L'organisation du compte est la sécurité du compte. Quelques règles, que l'audit de la métropole aurait pu écrire :

• Moindre privilège par rôle, appliqué par groupes, revu tous les trimestres : qui est dans quel groupe, et pourquoi.
• Deux administrateurs IAM au plus, en plus du propriétaire, avec second facteur, parce que IAMManager vaut tous les droits.
• Le propriétaire n'est pas un compte de travail (leçon 7) : pas de clé d'API à son nom, une procédure de bris de glace écrite.
• Toutes les clés expirent, avec une durée maximale imposée à l'organisation ; les clés humaines sont courtes (quelques jours), les clés d'applications plus longues mais remplacées avant leur échéance.
• Les sessions de console sont courtes : douze heures obligent à se reconnecter chaque jour, ce qui limite l'usage d'un poste volé.
• Les conditions IP pour les tiers : un prestataire, un outil d'intégration externe ou une clé de sauvegarde n'ont aucune raison d'être utilisables depuis n'importe où. Rappelons la limite : seules les adresses publiques sont prises en charge, ce qui exclut de restreindre aux adresses d'un réseau privé.
• Tout ce qui précède se vérifie dans les journaux. Les modifications d'IAM apparaissent dans les journaux IAM et dans Audit Trail (leçon 15). Une création de politique non annoncée est un incident.

En production

À quoi ressemble l'organisation de Lyneko. Lyneko héberge plusieurs applications (dont celle que vous lisez) sur un cluster Kapsule partagé, lyneko-apps, avec leurs images dans le registre rg.fr-par.scw.cloud et leurs secrets dans Secret Manager, lus par External Secrets. Un cluster partagé ne se découpe pas en projets : la séparation entre applications s'y fait par les espaces de noms et les droits de Kubernetes, et le projet Scaleway porte l'infrastructure commune. Le découpage par projet décrit dans cette leçon convient aux applications qui ont leurs propres ressources cloud ; les deux modèles cohabitent souvent.

L'IAM se décrit en code. Une politique écrite à la main dans la console n'est relue par personne et ne laisse pas d'historique lisible. En production, groupes, politiques et appartenances se décrivent dans le dépôt d'infrastructure, avec le fournisseur Terraform de Scaleway, et se modifient par demande de fusion : la revue de code devient la revue des droits.

SAML et SCIM dès que l'équipe dépasse quelques personnes. Avec la fédération SAML, les personnes se connectent avec le compte de l'entreprise, et son second facteur ; avec SCIM, la création, le verrouillage et l'appartenance aux groupes suivent l'annuaire. Le départ d'une personne se règle alors dans l'annuaire, en un seul endroit. Deux limites documentées : SAML ne s'applique pas au propriétaire, et un utilisateur supprimé dans le fournisseur d'identité sans SCIM reste membre de l'organisation Scaleway jusqu'à ce qu'on le supprime à la main.

Le support se choisit avec le contrat client. Si vous promettez à une métropole un rétablissement en quatre heures, un fournisseur qui répond en huit ne vous aide pas. Le choix du plan de support fait partie de l'architecture, au même titre que la redondance.

L'empreinte entre dans les arbitrages. Une préproduction éteinte la nuit et le week-end, une instance plus récente et mieux dimensionnée, une région au mix électrique moins carboné : l'empreinte se lit avant et après chaque décision, comme la facture.

Exercices

1. Découper (niveau 200). Lyneko héberge chez Scaleway cinq applications, chacune avec une préproduction et une production, plus un projet d'outils communs (supervision, registre) et un bac à sable. Deux nouveaux clients arrivent l'an prochain, chacun avec trois applications dédiées. Le découpage « un projet par application et par environnement » tient-il ? Que proposez-vous ?

2. Écrire une condition (niveau 200). Écrivez la condition d'une règle qui donne accès aux secrets de Signalements dont le nom commence par /signalements/prod/, uniquement depuis l'adresse publique de la passerelle de production 203.0.113.40, tout en laissant l'application lister les secrets. Pour quel produit cette condition fonctionne-t-elle, et pour lequel ne fonctionnerait-elle pas ?

3. Auditer (niveau 200). Écrivez un petit script qui, pour chaque groupe de l'organisation, affiche ses politiques et, pour chaque politique, ses jeux de permissions et son périmètre (organisation ou liste de projets), et signale en tête de ligne toute règle qui contient IAMManager, OrganizationManager ou AllProductsFullAccess.

#!/usr/bin/env bash
set -euo pipefail
scw iam group list -o json | jq -r '.[] | [.id, .name] | @tsv' |
while IFS=$'\t' read -r gid gname; do
  scw iam policy list group-ids.0="$gid" -o json | jq -r '.[] | [.id, .name] | @tsv' |
  while IFS=$'\t' read -r pid pname; do
    scw iam rule list "$pid" -o json | jq -r --arg g "$gname" --arg p "$pname" '.[] |
      (if ([.permission_set_names[]?] | any(. == "IAMManager" or . == "OrganizationManager" or . == "AllProductsFullAccess"))
       then "ATTENTION " else "          " end)
      + "\($g)\t\($p)\t\(.permission_set_names | join(","))\t\(.organization_id // (.project_ids | join(",")))"'
  done
done

4. Choisir un plan de support (niveau 200). Signalements consomme 1 800 € par mois chez Scaleway. Le contrat avec une métropole prévoit une prise en charge d'incident en moins d'une heure, de jour comme de nuit. Quel plan choisissez-vous, combien coûte-t-il par mois, et ce choix suffit-il à tenir l'engagement ?

Récapitulatif

• Un projet sépare les droits, les ressources et la consommation affichée ; il ne sépare ni les quotas, ni les identités, ni la facture. Une organisation compte au plus 25 projets.
• Pour une application en production : un projet par environnement, plusieurs organisations au-delà d'une douzaine d'applications ou pour séparer des clients.
• Les droits se décrivent en rôles : des groupes, des politiques attachées aux groupes, des règles avec un périmètre (organisation ou projets) et des jeux de permissions au grain de l'action.
• IAMManager et OrganizationManager valent tous les droits.
• Les conditions CEL portent sur la requête (request.ip publique, request.time avec fuseau, request.user_agent) ou, pour IAM, Key Manager et Secret Manager, sur la ressource (resource.name, resource.id, resource.locality). Les politiques s'additionnent : une condition ne restreint que sa règle.
• scw iam security-settings règle la durée maximale des clés (nouvelles clés seulement), des sessions (sessions en cours comprises) et le délai de grâce ; les durées s'écrivent en heures (2160h).
• Quotas, plan de support, contacts de facturation et d'abus font partie de l'architecture.
• L'empreinte environnementale se lit par l'API, par projet, et sert à comparer.

Pour aller plus loin

• Les pages Request-level conditions et Resource-level conditions de la documentation IAM de Scaleway, et la définition du langage CEL pour les fonctions de date et de chaîne.
• La page Permission sets, à relire à chaque nouveau produit utilisé.
• Le référentiel méthodologique de l'ADEME pour l'évaluation environnementale des services cloud, pour comprendre ce que mesurent (et ne mesurent pas) les chiffres d'empreinte.
• La leçon suivante, qui fabrique des images et fait tourner un groupe d'instances qui suit la charge, et la leçon 15, qui audite ce que cette leçon a mis en place.