Ce qu'est le cloud

Pourquoi

L'application Signalements, que vous avez conteneurisée dans les cours précédents, tourne aujourd'hui sur un seul serveur. Imaginons son histoire, qui est celle de beaucoup d'équipes. Le serveur a été acheté il y a quatre ans, après trois semaines de devis et de validation budgétaire, puis deux semaines de livraison. Il a été dimensionné « large », pour tenir la charge prévue dans trois ans. Il est installé dans une baie louée chez un hébergeur, et une seule personne de l'équipe sait vraiment comment il a été configuré.

Trois problèmes se posent, et ils sont typiques :

• Le délai. La mairie cliente veut ouvrir Signalements à cinq autres communes le mois prochain. Il faudrait un second serveur. Le circuit d'achat prend un mois et demi : on ne peut pas tester l'idée avant de s'y engager.
• Le dimensionnement. La plupart du temps, le serveur tourne à 5 % de sa capacité : on paie pour de la puissance qui dort. Mais le lendemain d'un orage, quand des centaines d'habitants signalent des arbres tombés, il sature. Un serveur physique ne grandit pas en une heure, et ne rétrécit jamais.
• La fragilité. Si la carte mère lâche, l'application est arrêtée jusqu'à l'arrivée de la pièce. Personne n'a jamais essayé de reconstruire le serveur à partir de zéro, et personne ne sait combien de temps cela prendrait.

Le cloud répond à ces trois problèmes, mais pas par magie, et pas gratuitement. Il répond par un modèle : des ressources informatiques disponibles en quelques secondes, à la demande, par une API, facturées à l'usage. Ce cours vous apprend ce modèle en déployant Signalements sur Scaleway, brique par brique. Cette première leçon pose la définition, les mots, et l'outil avec lequel nous parlerons au fournisseur pendant tout le cours.

Les concepts

Une définition qui a résisté au temps

Le mot cloud (« nuage ») vient des schémas de réseau des années 1990, où l'on dessinait Internet comme un nuage : une zone dont on ne détaille pas l'intérieur. Le terme a ensuite été employé pour tout et n'importe quoi, au point que l'institut de normalisation américain, le NIST, a publié en septembre 2011 une définition de deux pages, la SP 800-145, rédigée par Peter Mell et Tim Grance. Elle reste la référence que citent les fournisseurs, les juristes et les appels d'offres publics, et la norme internationale ISO/IEC 17788 de 2014 en a repris l'essentiel.

En la résumant avec nos mots : l'informatique en nuage (cloud computing) est un modèle qui donne accès, par le réseau, à la demande, à un réservoir commun de ressources informatiques configurables (serveurs, stockage, réseaux, applications), que l'on peut obtenir et rendre rapidement, avec un effort de gestion minimal et sans interaction avec le fournisseur.

Le NIST décompose ce modèle en cinq caractéristiques essentielles, trois modèles de service et quatre modèles de déploiement.

Les cinq caractéristiques essentielles

C'est la partie la plus utile de la définition, parce qu'elle permet de tester une offre. Une offre qui ne coche pas les cinq cases n'est pas du cloud au sens strict, quel que soit son nom commercial.

La mutualisation (multi-tenancy, littéralement « plusieurs locataires ») mérite une attention particulière, parce qu'elle est à la fois la source de l'économie du cloud et la source de ses principaux risques. Le fournisseur achète des milliers de serveurs et les partage entre ses clients ; les pics des uns compensent les creux des autres, et la machine physique est utilisée bien plus que votre serveur à 5 %. En contrepartie, votre application cohabite, sur le même matériel, avec celles d'inconnus. L'isolation entre locataires (hyperviseur, réseau virtuel, chiffrement) devient alors la responsabilité centrale du fournisseur. La norme ISO/IEC 17788 fait d'ailleurs de la mutualisation une caractéristique à part entière, en plus des cinq du NIST.

L'élasticité est la caractéristique qui change le plus la façon de travailler. Le rapport de Berkeley de 2009, Above the Clouds, qui a beaucoup contribué à faire comprendre le cloud aux ingénieurs, insiste sur trois nouveautés : l'illusion de ressources infinies disponibles à la demande, la disparition de l'engagement initial (on n'achète plus de matériel avant de savoir si on en aura besoin), et la possibilité de payer des ressources pour une courte durée, puis de les rendre. Ses auteurs en tirent une observation restée célèbre : mille serveurs pendant une heure ne coûtent pas plus cher qu'un serveur pendant mille heures. C'est exactement ce qui manquait à l'équipe de Signalements le lendemain de l'orage.

Trois modèles de service

Le NIST distingue trois façons de consommer le cloud, selon ce que le fournisseur gère pour vous :

• l'IaaS (Infrastructure as a Service) : vous obtenez des machines, du stockage et des réseaux, et vous y installez ce que vous voulez, système d'exploitation compris ;
• le PaaS (Platform as a Service) : vous déployez votre application sur une plateforme qui gère le système, l'environnement d'exécution et souvent la mise à l'échelle ;
• le SaaS (Software as a Service) : vous utilisez une application complète, comme une messagerie en ligne.

Ces modèles, leurs variantes plus récentes (conteneurs managés, serverless) et ce que chacun laisse à votre charge sont le sujet de la leçon 2.

Quatre modèles de déploiement

La définition distingue aussi qui peut utiliser l'infrastructure :

• Le cloud public est ouvert à tous : n'importe quelle entreprise ou particulier peut ouvrir un compte. Il est exploité dans les locaux du fournisseur. Scaleway, OVHcloud, AWS, Azure et Google Cloud vendent du cloud public.
• Le cloud privé est réservé à une seule organisation, qui peut l'exploiter elle-même ou le faire exploiter par un tiers, dans ses locaux ou ailleurs. Une grande banque qui fait tourner OpenStack dans ses propres centres de données a un cloud privé, à condition que ses équipes internes y obtiennent des ressources en libre-service, par API. Une salle de serveurs gérée par tickets n'est pas un cloud privé, même virtualisée.
• Le cloud communautaire est partagé par un groupe d'organisations qui ont les mêmes exigences (mission, sécurité, conformité). Les offres réservées aux administrations, ou aux établissements de santé, en relèvent.
• Le cloud hybride combine plusieurs de ces infrastructures, qui restent distinctes mais sont reliées par une technologie qui permet de déplacer données et applications de l'une à l'autre.

Dans la pratique française, s'ajoute une distinction qui n'est pas dans le NIST mais pèse lourd dans les choix : le droit auquel est soumis le fournisseur et le niveau de qualification de son offre (SecNumCloud, délivré par l'ANSSI). C'est le sujet du cours Cloud souverain : choisir et justifier.

Ce que le cloud n'est pas

Trois confusions reviennent souvent.

« Un serveur loué au mois, c'est du cloud. » Pas nécessairement. Un serveur dédié commandé par formulaire, livré en quelques heures ou jours, facturé au mois avec engagement, et dont on ne peut changer la taille qu'en en commandant un autre, coche peut-être l'accès réseau, mais ni le libre-service immédiat, ni l'élasticité, ni le service mesuré. C'est de l'hébergement, ce qui n'a rien de honteux : c'est souvent moins cher pour une charge stable. Beaucoup de fournisseurs, dont Scaleway (avec ses serveurs Dedibox) et OVHcloud, vendent à la fois de l'hébergement dédié et du cloud ; ce sont deux produits différents.

« L'hébergement mutualisé, c'est du cloud. » L'hébergement web mutualisé classique (un espace sur un serveur partagé, avec PHP et une base de données) mutualise bien les ressources, mais n'offre ni élasticité ni libre-service sur l'infrastructure. Il s'apparente à un SaaS très limité.

« Le cloud, c'est l'ordinateur de quelqu'un d'autre. » Cette formule, populaire sur les autocollants, est vraie sur un point essentiel : vos données sont sur des machines que vous ne contrôlez pas physiquement, chez un tiers soumis à son propre droit, et votre sécurité dépend en partie de la sienne. Elle est fausse sur ce qui fait la valeur du cloud : l'ordinateur de quelqu'un d'autre ne se commande pas en une seconde par une API, ne grandit pas à la demande, ne se facture pas à la minute, et n'est pas doublé dans trois centres de données. Gardez les deux moitiés en tête : la première vous rendra prudent, la seconde vous dira pourquoi on y va quand même.

Une brève histoire

Ce qui a peu changé depuis 2006, c'est le modèle de base : une API, des ressources à la demande, une facture à l'usage. C'est ce modèle que nous allons manipuler.

Tout est une API

Voici l'idée la plus importante de la leçon. Quand vous cliquez sur « Créer une instance » dans la console web d'un fournisseur, la console envoie une requête HTTP à son API. La ligne de commande (scw chez Scaleway, aws, az, gcloud, ou openstack pour les clouds OpenStack comme celui d'OVHcloud), les fournisseurs Terraform et les bibliothèques (SDK) font exactement la même chose. La console n'est qu'un client parmi d'autres.

Cela a trois conséquences pratiques :

1. Tout ce que vous faites à la main peut être automatisé, puisque c'est un appel d'API. C'est le fondement de l'infrastructure as code.
2. Tout est authentifié par une clé d'API. Qui possède la clé peut faire, par script et en quelques secondes, tout ce que la console permet : créer cent machines, ou tout supprimer.
3. Tout est journalisable. Chaque création, modification ou suppression est une requête identifiable, attribuable à une identité.

On distingue deux « plans » dans un service cloud, une distinction qui reviendra dans tout le cours :

• Le plan de contrôle (control plane) est la machinerie qui modifie le système : créer, modifier, supprimer des ressources. C'est l'API, et tout ce qu'il y a derrière.
• Le plan de données (data plane) est ce qui fait fonctionner les ressources une fois créées : la machine virtuelle qui exécute votre code, le réseau qui achemine les paquets, le disque qui lit et écrit.

Les deux sont conçus pour tomber en panne indépendamment. AWS explique dans sa Builders' Library que le plan de données d'EC2 est conçu pour être statiquement stable : si l'API devient indisponible, les machines déjà lancées continuent de tourner et de router leur trafic ; on ne peut simplement plus rien changer. C'est un principe que l'on retrouve chez tous les fournisseurs, et qui a une conséquence directe pour vous : une architecture qui a besoin de créer des ressources pour survivre à une panne (par exemple, lancer des serveurs de secours au moment de l'incident) dépend du plan de contrôle, souvent le premier à saturer pendant un incident d'ampleur. La leçon 3 y revient.

Les mots de Scaleway, et leurs équivalents

Pour suivre le cours, quelques termes de Scaleway, avec leurs équivalents ailleurs :

Les correspondances ne sont pas exactes (un compte AWS est une frontière plus forte qu'un projet Scaleway, par exemple), mais elles suffisent pour s'orienter. Régions et zones sont détaillées à la leçon 3, organisations et projets à la leçon 7.

En pratique

Nous allons installer la ligne de commande de Scaleway, la configurer, créer le projet signalements qui accueillera toutes les ressources du cours, puis regarder ce qu'il y a sous une commande. Cette leçon ne crée aucune ressource payante : un projet est gratuit.

Installer la CLI

La CLI scw est un binaire unique écrit en Go, publié sur GitHub. Son README propose plusieurs méthodes :

$ brew install scw                       # macOS et Linux avec Homebrew
$ curl -s https://raw.githubusercontent.com/scaleway/scaleway-cli/master/scripts/get.sh | sh
$ docker run -i --rm scaleway/cli:latest version   # sans rien installer

La deuxième ligne télécharge un script et l'exécute directement : c'est pratique, mais vous exécutez sans le lire un script venu d'Internet. Préférez télécharger le binaire de la version voulue depuis la page des releases du dépôt scaleway/scaleway-cli, vérifier sa somme de contrôle avec le fichier publié à côté, puis le placer dans votre PATH. Vérifiez ensuite :

$ scw version

La commande affiche la version (2.62.0 pour ce cours), la date de construction et la version de Go utilisée.

Obtenir une clé d'API et initialiser la configuration

La CLI s'authentifie avec une clé d'API, composée de deux parties :

• la clé d'accès (access key), un identifiant qui commence par SCW ; elle n'est pas secrète, c'est le nom de la clé ;
• la clé secrète (secret key), au format UUID ; c'est elle qui authentifie chaque requête, et elle ne doit jamais être divulguée.

Deux façons de l'obtenir :

1. Depuis la console, rubrique IAM, puis API keys : vous générez une clé, vous choisissez son expiration, et la console vous montre la clé secrète une seule fois.
2. Avec scw login, qui ouvre une page web, vous fait vous connecter, puis crée une clé et configure la CLI. L'argument expires-at fixe l'expiration de la clé, en date ISO 8601 ou en durée relative :

$ scw login expires-at=+30d

Pour ce cours, une clé qui expire dans trente jours suffit. Une clé sans expiration est une clé qui finira oubliée dans un fichier ; la leçon 7 revient sur ce point.

Si vous avez créé la clé dans la console, lancez l'initialisation, qui pose ses questions une à une :

$ scw init

scw init accepte aussi tous ses paramètres en arguments clé=valeur, ce qui est la forme générale de la CLI : scw <produit> <ressource> <verbe> argument=valeur.... Les plus utiles :

• access-key et secret-key : la clé d'API. Ne les passez pas en argument dans un terminal interactif : elles finiraient dans l'historique du shell. Laissez scw init vous les demander.
• region=fr-par et zone=fr-par-1 : la région et la zone utilisées quand une commande n'en précise pas. Paris est le bon choix pour ce cours.
• with-ssh-key=true (valeur par défaut) : téléverse votre clé SSH publique (par exemple ~/.ssh/id_ed25519.pub) dans l'IAM de Scaleway, pour qu'elle soit installée sur les instances que vous créerez à la leçon 4.
• send-telemetry : l'envoi de statistiques d'usage à Scaleway ; choisissez en connaissance de cause.
• install-autocomplete : installe la complétion pour votre shell, très utile avec une CLI qui compte des centaines de commandes.

Lire la configuration

La configuration est écrite dans un fichier YAML. Son emplacement suit un ordre de priorité, affiché par scw init --help : $SCW_CONFIG_PATH s'il est défini, sinon $XDG_CONFIG_HOME/scw/config.yaml, sinon ~/.config/scw/config.yaml.

$ scw config info
$ ls -l ~/.config/scw/config.yaml
$ stat -c '%a' ~/.config/scw/config.yaml

scw config info affiche les valeurs du profil courant. Le fichier, lui, ressemble à ceci (identifiants remplacés) :

access_key: SCWXXXXXXXXXXXXXXXXX
secret_key: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
default_organization_id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
default_project_id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
default_region: fr-par
default_zone: fr-par-1

La clé secrète est en clair dans ce fichier. Le SDK Go de Scaleway, sur lequel repose la CLI, le crée avec les droits 600 (lecture et écriture pour vous seul) et son répertoire avec les droits 700 : la commande stat doit afficher 600. Si ce n'est pas le cas (fichier copié à la main, par exemple), corrigez avec chmod 600.

Ce fichier n'est pas propre à la CLI : le SDK Go et le fournisseur Terraform de Scaleway le lisent aussi. Le configurer une fois sert donc pour la suite du parcours.

Les variables d'environnement et les profils

Chaque valeur du fichier a son équivalent en variable d'environnement : SCW_ACCESS_KEY, SCW_SECRET_KEY, SCW_DEFAULT_ORGANIZATION_ID, SCW_DEFAULT_PROJECT_ID, SCW_DEFAULT_REGION, SCW_DEFAULT_ZONE. Dans la CLI, les variables d'environnement l'emportent sur le fichier (scw config --help le précise). C'est le mécanisme qu'utilisera un pipeline de CI, qui reçoit sa clé par des secrets injectés en variables, sans fichier.

Le fichier peut aussi contenir plusieurs profils, chacun avec ses propres clés et valeurs par défaut :

access_key: SCWXXXXXXXXXXXXXXXXX            # profil par défaut
secret_key: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
default_region: fr-par
active_profile: formation
profiles:
  formation:
    access_key: SCWYYYYYYYYYYYYYYYYY
    secret_key: yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy
    default_project_id: zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz
    default_zone: fr-par-1

Le profil utilisé se choisit, du plus prioritaire au moins prioritaire : par l'option -p (ou --profile) d'une commande, par la variable SCW_PROFILE, puis par la clé active_profile du fichier ; à défaut, ce sont les valeurs à la racine du fichier. scw config profile list liste les profils, scw config profile activate <nom> change le profil actif.

Créer le projet du cours

Une organisation Scaleway (votre compte) contient des projets, qui regroupent des ressources. Chaque organisation a un projet nommé default, qui ne peut pas être supprimé. Nous allons créer un projet dédié, pour que toutes les ressources du cours y soient regroupées, facturées ensemble et faciles à retrouver :

$ scw account project create name=signalements \
    description="Formation : Signalements sur Scaleway" -o json | jq -r .id

• scw account project create appelle l'API Account de Scaleway, qui gère les projets.
• name et description sont les seuls paramètres utiles ; l'organisation par défaut de la configuration est utilisée.
• -o json demande une sortie JSON plutôt que le tableau lisible par défaut, et jq -r .id en extrait le champ id sans guillemets.

La commande affiche l'identifiant du projet, un UUID. Faites-en le projet par défaut de la CLI :

$ scw config set default-project-id=<identifiant affiché>
$ scw account project list

La seconde commande liste les projets de l'organisation : vous devez y voir default et signalements. Désormais, toute ressource créée sans project-id explicite atterrira dans signalements.

Regarder sous une commande

Toutes les commandes acceptent l'option globale -D (ou --debug). Relancez la liste des projets avec :

$ scw account project list -D

La CLI affiche alors, en plus du résultat, ses messages de débogage, dont le contenu complet de chaque requête HTTP envoyée et de chaque réponse reçue, encadrés par des lignes Scaleway SDK REQUEST et Scaleway SDK RESPONSE. Vous y lisez :

• la méthode et le chemin : GET /account/v3/projects?organization_id=... ;
• l'hôte : api.scaleway.com ;
• l'en-tête X-Auth-Token, qui porte la clé secrète, masqué dans le journal (le SDK anonymise les en-têtes d'authentification avant de les écrire, puis restaure l'original pour l'envoi) ;
• la réponse : un code 200 OK et un corps JSON avec un champ projects.

Puisqu'il ne s'agit que de HTTP, on peut se passer de la CLI. Récupérez vos identifiants dans des variables, sans les afficher :

$ SCW_SECRET_KEY=$(scw config get secret-key)
$ ORG=$(scw config get default-organization-id)
$ curl -s -H "X-Auth-Token: $SCW_SECRET_KEY" \
    "https://api.scaleway.com/account/v3/projects?organization_id=$ORG" \
    | jq '.projects[] | {name, id}'

Vous obtenez la même liste que la CLI : un objet par projet, avec son nom et son identifiant. La documentation de Scaleway montre la forme de cette réponse : un champ total_count et un tableau projects dont chaque élément porte id, name, organization_id, created_at, updated_at et description (celle du projet default vaut cannot_be_deleted).

La console web, la CLI, Terraform et ce curl sont quatre clients d'une même API. Retenez la forme de ses chemins, que la documentation de Scaleway décrit :

La portée dans le chemin dit où vit la ressource : une instance appartient à une zone, un cluster Kubernetes à une région, un projet à toute l'organisation. La leçon 3 en tire les conséquences pour la résistance aux pannes. Notez aussi la version dans le chemin : v1 désigne une API stable, v1beta1 une API en préversion, v1alpha1 une API expérimentale.

Supprimez la variable qui contient la clé secrète quand vous avez fini :

$ unset SCW_SECRET_KEY

Sous le capot

Ce qui se passe quand on demande une machine

Prenons la commande que vous lancerez à la leçon 4, scw instance server create. Côté client, la CLI v2.62 enchaîne en réalité deux appels : la création du serveur (POST /instance/v1/zones/fr-par-1/servers), puis, sauf si vous passez stopped=true, une action de démarrage (poweron) sur ce serveur. Côté fournisseur, la requête traverse plusieurs étapes, que tous les clouds IaaS partagent dans les grandes lignes :

    flowchart LR
  c["Client<br/>(console, scw, Terraform)"] -->|"HTTPS + X-Auth-Token"| api["API<br/>(plan de contrôle)"]
  api --> iam["Authentification<br/>et autorisation (IAM)"]
  api --> q["Quotas et<br/>facturation"]
  api --> s["Ordonnanceur"]
  s --> h["Hyperviseur d'un<br/>serveur physique"]
  h --> vm["Machine virtuelle<br/>(plan de données)"]
  

1. Authentification et autorisation. L'API retrouve la clé à partir de l'en-tête X-Auth-Token, l'identité qui la porte (utilisateur ou application), et vérifie que ses politiques l'autorisent à créer un serveur dans ce projet. Sinon : 403.
2. Quotas. L'API vérifie que l'organisation n'a pas atteint sa limite pour ce type de ressource. Chez Scaleway, les quotas s'appliquent par organisation, et leurs valeurs dépendent de l'état du compte : plus bas avec un moyen de paiement seul, plus hauts une fois l'identité vérifiée, au-delà sur demande au support. Ils protègent le fournisseur (capacité) et vous (un script en boucle qui créerait mille machines).
3. Ordonnancement. Un ordonnanceur (scheduler) choisit, dans la zone demandée, un serveur physique qui a assez de processeurs, de mémoire et de disque libres pour le type d'instance demandé. C'est ici que se joue la mutualisation : votre machine virtuelle partage ce serveur avec d'autres.
4. Provisionnement. L'hyperviseur de ce serveur crée la machine virtuelle, son disque est préparé à partir de l'image choisie, ses interfaces réseau sont branchées, une adresse IP est attribuée.
5. Démarrage. Le système démarre, récupère sa configuration initiale (leçon 4), et la machine devient joignable.

Pourquoi tout est asynchrone

Ces étapes prennent de quelques secondes à quelques minutes. L'API ne vous fait pas attendre : elle accepte la demande, crée l'objet dans un état transitoire, et répond immédiatement. La ressource vit ensuite sa vie, et son champ state (ou status) change au fil du temps. Pour une instance Scaleway, les états possibles sont starting, running, stopping, stopped, stopped in place et locked ; pour une base de données managée, provisioning, initializing, configuring, ready, et quelques autres.

Conséquence pratique : une commande qui réussit ne veut pas dire que la ressource est prête. Si votre script crée un serveur puis tente immédiatement de s'y connecter, il échouera. Deux façons d'attendre :

• l'option -w (ou --wait) des commandes de création et d'action, qui fait interroger l'API par la CLI jusqu'à ce que la ressource atteigne un état stable ;
• les commandes wait dédiées, comme scw instance server wait <id>, pour attendre une ressource créée ailleurs.

C'est une forme de cohérence à terme (eventual consistency) : pendant un court moment, deux lectures de la même ressource peuvent donner des réponses différentes, ou une ressource tout juste créée peut ne pas encore apparaître dans une liste. Les outils d'infrastructure as code passent une bonne partie de leur code à attendre et à réessayer pour cette raison.

Pièges courants

Travailler dans le projet default. Toutes les ressources finissent mélangées, les droits ne peuvent pas être séparés, et il devient impossible de savoir ce qui appartient à quoi, ni de tout supprimer proprement. Créez un projet par application et par environnement dès le départ.

Se tromper de profil ou de projet. Une commande lancée avec le mauvais profil actif crée la ressource dans le mauvais projet, ou en supprime une dans le mauvais. scw config info affiche les valeurs effectivement utilisées. Méfiez-vous en particulier d'une variable SCW_DEFAULT_PROJECT_ID restée exportée dans un terminal : elle l'emporte sur le fichier.

Oublier la zone. Une ressource zonale créée sans zone= l'est dans la zone par défaut de la configuration. Une commande list sans zone= ne montre que cette zone : la machine « disparue » est souvent simplement dans fr-par-2. Beaucoup de commandes list acceptent zone=all (ou region=all pour les produits régionaux) pour parcourir toutes les localisations : scw instance server list zone=all. L'aide de chaque commande indique si cette valeur est acceptée.

Croire qu'une commande terminée a fini son travail. Voir Pourquoi tout est asynchrone. Utilisez --wait dans les scripts.

Une clé d'API expirée. Les erreurs d'authentification (401, ou un message indiquant que l'authentification a échoué) après quelques semaines viennent souvent d'une clé arrivée à expiration. C'est le comportement voulu : créez-en une nouvelle.

Chercher une commande au hasard. scw --help, puis scw <produit> --help, puis scw <produit> <ressource> <verbe> --help : l'aide de chaque commande liste tous ses arguments, leurs valeurs par défaut et des exemples. Elle fait foi pour la version installée, mieux qu'un article trouvé en ligne écrit pour une version plus ancienne.

Sécurité

La clé d'API, ce sont les clés du centre de données. Une clé secrète qui fuit permet à n'importe qui, depuis n'importe où, de créer des ressources à vos frais (le minage de cryptomonnaie sur des instances à processeur graphique est le scénario le plus courant), de lire vos données, ou de tout détruire. Le cloud a transformé une intrusion physique, difficile, en une fuite de chaîne de caractères, facile. Quelques règles :

• Jamais dans un dépôt Git. Les robots qui parcourent les dépôts publics à la recherche de clés trouvent une clé publiée en quelques minutes. Si une clé a été poussée, même une seconde, même dans une branche supprimée, considérez-la compromise : révoquez-la dans la console, puis cherchez ce qu'elle a fait. Un outil de détection de secrets exécuté avant chaque commit ou dans la CI (le cours Gestion des secrets en présente) attrape la plupart de ces erreurs avant qu'elles ne partent.
• Jamais en argument de commande. Ni scw init secret-key=..., ni curl -H "X-Auth-Token: ..." tapé en clair : l'historique du shell la conserve, et la liste des processus l'expose aux autres utilisateurs de la machine pendant l'exécution. Passez par un fichier aux droits 600 ou par une variable lue sans affichage.
• Une expiration courte, et une clé par usage : une pour votre poste, une par pipeline. Une clé de pipeline compromise se révoque sans couper les autres.
• Le moindre privilège. Une clé hérite des droits de l'identité qui la porte. La clé de votre compte de propriétaire de l'organisation peut tout faire ; la leçon 7 crée des identités aux droits limités.
• Le fichier config.yaml est un secret. Excluez ~/.config/scw/ des sauvegardes non chiffrées et des dépôts de dotfiles que vous publiez.

Le plan de contrôle est la surface d'attaque principale. Un attaquant n'a plus besoin de pénétrer vos serveurs : s'il obtient une clé d'API, il pilote l'infrastructure. C'est pourquoi la journalisation des appels d'API (Scaleway propose pour cela le service Audit Trail), l'authentification à facteurs multiples sur la console et le cloisonnement par projet sont des mesures de base, détaillées à la leçon 7.

En production

• Un projet par application et par environnement (signalements-preprod, signalements-prod) : les droits, la facture et le nettoyage suivent ce découpage. La leçon 7 montre comment donner à chaque équipe et à chaque pipeline des droits limités à ses projets.
• Des profils nommés sur les postes des administrateurs, un par organisation ou par niveau de droit, et l'habitude de vérifier le profil actif avant toute commande destructrice. Certaines équipes affichent le profil scw actif dans l'invite de leur shell.
• Les quotas se prévoient. Une montée en charge, ou un plan de reprise qui suppose de recréer cinquante machines dans une autre zone, peut buter sur un quota. Consultez-les dans la console et demandez une augmentation avant d'en avoir besoin.
• On ne travaille pas à la main. Cette leçon et les suivantes utilisent la CLI pour rendre chaque étape visible. En production, l'infrastructure est décrite dans du code versionné et relu (cours Terraform et OpenTofu : les fondamentaux), et les clés des humains servent surtout à lire et à diagnostiquer.
• Chez Lyneko, les applications tournent sur un cluster Kapsule, le Kubernetes managé de Scaleway, et leurs images sont publiées dans le registre de conteneurs de Scaleway (rg.fr-par.scw.cloud) : deux services qui, eux aussi, ne sont que des API que la CLI, Terraform et le pipeline de déploiement appellent.

Exercices

1. Est-ce du cloud ? (niveau 100). Pour chacune des offres suivantes, dites lesquelles des cinq caractéristiques du NIST elle remplit, et concluez. (a) Un serveur dédié commandé sur un formulaire, livré sous 24 heures, facturé au mois avec un engagement d'un an. (b) Un service où l'on crée par API, en quelques secondes, une base de données PostgreSQL facturée à l'heure. (c) Une plateforme interne de virtualisation où l'on obtient une machine virtuelle en ouvrant un ticket, traité sous trois jours par l'équipe système. (d) La même plateforme, avec un portail en libre-service et une API, et une refacturation mensuelle aux équipes selon leur consommation mesurée.

2. Lire une requête (niveau 100). Lancez scw account project list -D et, dans la sortie de débogage, repérez : la méthode HTTP, le chemin complet, la portée de l'API (zonale, régionale ou globale), l'en-tête d'authentification et ce qui y figure, le code de réponse. Pourquoi la clé n'apparaît-elle pas en clair ?

3. Deux profils (niveau 100). Ajoutez à votre fichier de configuration un profil lecture qui utilise une autre clé d'API (créez-la dans la console avec une expiration de sept jours), et dont la zone par défaut est fr-par-2. Sans modifier active_profile, montrez trois façons de lancer scw config info avec ce profil, puis expliquez laquelle l'emporte si elles se contredisent.

4. Plan de contrôle, plan de données (niveau 100). Pour chaque situation, dites quel plan est touché et quel est l'effet sur Signalements, déjà en production sur deux instances : (a) l'API de Scaleway répond par des erreurs pendant une heure ; (b) un équipement réseau d'une zone tombe en panne ; (c) l'équipe voulait, pendant cette heure-là, ajouter une troisième instance pour absorber un pic.

Récapitulatif

• Le cloud est un modèle, défini par cinq caractéristiques : libre-service à la demande, accès par le réseau, mutualisation des ressources, élasticité rapide, service mesuré. Une offre qui n'en remplit pas les cinq est de l'hébergement, ce qui peut être un bon choix, mais pas le même.
• Trois modèles de service (IaaS, PaaS, SaaS, leçon 2) et quatre modèles de déploiement (public, privé, communautaire, hybride).
• « L'ordinateur de quelqu'un d'autre » : vrai pour le contrôle et le droit applicable, faux pour la souplesse et la résilience.
• Tout est une API. La console, la CLI scw, Terraform et curl en sont des clients ; chaque requête est authentifiée par l'en-tête X-Auth-Token, qui porte la clé secrète.
• La configuration de scw vit dans ~/.config/scw/config.yaml (droits 600), avec des profils ; les variables SCW_* l'emportent sur le fichier.
• On travaille dans un projet dédié, jamais dans default.
• Le plan de contrôle modifie le système, le plan de données le fait fonctionner ; le second est conçu pour survivre aux pannes du premier.
• Les opérations sont asynchrones : une ressource passe par des états transitoires ; on attend avec --wait.

Pour aller plus loin

• La définition du NIST elle-même : trois pages, qui se lisent en dix minutes et servent dans toute discussion contractuelle.
• Above the Clouds: A Berkeley View of Cloud Computing (2009), pour comprendre l'économie du cloud telle que l'ont vue ceux qui l'ont expliquée en premier.
• L'article Static stability using Availability Zones de l'AWS Builders' Library, pour la distinction entre plan de contrôle et plan de données appliquée à la conception.
• La documentation des commandes de la CLI dans le dépôt scaleway/scaleway-cli (répertoire docs/commands), une page par produit.
• La leçon suivante, qui compare l'IaaS, le PaaS et le serverless sur l'exemple de Signalements, et crée sa base de données.