Scaleway

01 - Foundations

☁️ 1. Les grandes familles

Besoin Produit à retenir
VM classique Instances
Serveur physique dédié Elastic Metal
GPU / IA / rendu / encodage GPU Instances
ARM / Ampere CAX
Mac Apple Silicon Apple Silicon / Mac mini
Kubernetes managé Kapsule
Conteneur serverless Serverless Containers
Fonction serverless Serverless Functions
Fichiers / objets Object Storage
Disque attaché à une VM Block Storage
Archivage froid Glacier
Base SQL Managed Databases
Cache / sessions Redis
Analytics / gros volumes ClickHouse
Répartition du trafic Load Balancer
IP publique portable Flexible IP
Monitoring / observabilité Cockpit
Identités / permissions IAM
Messages pub/sub Topics & Events
Messages point-to-point Queues
Emails transactionnels Transactional Email
IA générative par API Generative APIs
Infrastructure as Code Terraform

🖥️ 2. Instances

Development Instances

➡️ Développement / tests
➡️ vCPU partagés

General Purpose

➡️ Usage général
➡️ C'est notamment là qu'on trouve CAX, avec processeurs Ampere ARM.

GPU Instances

➡️ IA
➡️ Data processing
➡️ Rendering
➡️ Video encoding

Elastic Metal

➡️ Bare Metal
➡️ Serveur physique, pas une VM.

Apple Silicon

➡️ Mac mini Apple Silicon
➡️ Connexion notamment SSH + VNC
➡️ Attention au minimum de facturation de 24 h.

💾 3. Storage

Object Storage

Imagine :

Bucket → Objects

Un bucket peut contenir énormément d'objets, pas seulement 100.

Les objets sont privés par défaut.

Versioning

Si tu modifies un objet avec le versioning activé :

photo.jpg
   ↓ modification
photo.jpg version 1
photo.jpg version 2
photo.jpg version 3

➡️ Les anciennes versions sont conservées.
➡️ Elles consomment donc du stockage → coût supplémentaire.

Site web dans Object Storage

Pour personnaliser le domaine :

CNAME

Block Storage

Pense :

Block Storage = disque

Tu peux :

attach → attacher le volume à une Instance
detach → le détacher

Très différent d'Object Storage.

Glacier

Pense :

Glacier = archivage / stockage froid

Et surtout :

❌ Pas de Multi-AZ redundancy comme le stockage Standard Multi-AZ.

🗄️ 4. Databases

PostgreSQL / MySQL

➡️ données structurées
➡️ applications classiques

Redis

➡️ mémoire / vitesse
➡️ cache
➡️ sessions
➡️ données temporaires
➡️ API

Question typique :

"Best database for storing sessions?"

💡 Redis

ClickHouse

➡️ Analytics
➡️ Très gros volumes de données
➡️ Data science / Business Intelligence

Et :

Data Warehouse = centralized repository for large sets of structured data

☸️ 5. Kubernetes

Pour l'instant, retiens simplement :

Kapsule = Kubernetes managé par Scaleway

Le cluster est intégré à l'écosystème Scaleway.

Et surtout :

Terraform peut gérer un cluster Kapsule.

On va approfondir ça juste après avec la certification Scaleway Associate Kubernetes. 😉

⚡ 6. Serverless

Serverless Functions

➡️ Tu déploies une fonction
➡️ Scaleway gère l'infrastructure
➡️ Ça scale automatiquement.

Quand il n'y a plus d'activité :

requêtes
  ↓
instances
  ↓
0

Puis une nouvelle requête arrive.

Le temps nécessaire pour redémarrer :

🔥 Cold start

Point important

Une instance de Serverless Function ne traite pas plusieurs requêtes simultanément.

➡️ Scaleway peut créer plusieurs instances pour gérer la charge.

Serverless Containers

➡️ Tu fournis un container
➡️ Scaleway gère l'infrastructure
➡️ Possibilité d'utiliser des encrypted environment variables pour les informations sensibles.

🌐 7. Network

Load Balancer

➡️ Distribue les requêtes entre plusieurs ressources.

Il peut être :

✅ Public
✅ Private

Flexible IP

C'est une IP :

public + portable + persistante

Tu peux :

Flexible IP
     ↓
Instance A
     ↓
detach
     ↓
Instance B

Elle est indépendante de la ressource.

⚠️ Elle est liée à une Availability Zone.

🔐 8. IAM

IAM =

Identity and Access Management

Il sert à gérer :

qui → peut faire quoi → sur quelles ressources

Organization

L'Organization regroupe les utilisateurs et ressources.

Owner

➡️ propriétaire de l'Organization.

Members / Users

➡️ utilisateurs auxquels on attribue des permissions.

Policies

➡️ définissent les permissions.

API Keys

Point à retenir :

API keys inherit the permissions of their bearer.

Donc une API key n'est pas magiquement plus puissante que l'utilisateur auquel elle appartient.

MFA

➡️ authentification multi-facteurs.

📊 9. Cockpit

Cockpit =

Observability

Il permet de centraliser :

Et surtout :

✅ pré-built dashboards pour les produits compatibles.

Cockpit n'est pas limité aux produits Scaleway : il peut aussi recevoir des données externes.

💰 Facturation Cockpit

À retenir pour le QCM :

❌ consultation d'un dashboard → pas facturée
❌ création d'une alerte → pas facturée
⚠️ rétention au-delà de la limite → facturée

📨 10. Messaging

Deux concepts à ne surtout pas mélanger :

Topics & Events

📢 Publish / Subscribe

Publisher
    ↓
 Topic
 ↙   ↓   ↘
A    B    C

Plusieurs consommateurs peuvent recevoir le message.

Queues

📬 Point-to-point

Producer
   ↓
 Queue
   ↓
Consumer

➡️ Un message est destiné à être traité par un consommateur.

💡 Mémo :

Topics = broadcast
Queues = file d'attente

📧 11. Transactional Email

Workflow :

1. Create account
       ↓
2. SPF / DKIM / DMARC
       ↓
3. Integrate SMTP / API
       ↓
4. Send
       ↓
5. Monitor

Donc :

Create → Authenticate → Integrate → Send → Monitor

🤖 12. AI

GPU Instances

➡️ GPU à la demande.

AI Supercomputers

➡️ infrastructures GPU massives pour l'IA.

Generative APIs

➡️ accès aux modèles génératifs via API.

Facturation :

Pay-as-you-go / tokens

Donc :

plus de tokens → plus de consommation

🏗️ 13. Terraform

Terraform = Infrastructure as Code

Au lieu de :

Console
→ clic
→ clic
→ clic

tu décris :

Terraform
→ configuration
→ plan
→ apply

Bonne pratique importante

Évite de mélanger :

création manuelle dans Console + gestion Terraform

Si une ressource existe déjà :

➡️ import dans Terraform state
➡️ puis gestion par Terraform.

🌍 14. Region vs Availability Zone

Très important pour les QCM :

Region

➡️ zone géographique.

Exemple :

Paris

Availability Zone

➡️ zone d'infrastructure isolée au sein d'une région.

Et attention à la phrase :

"Each Region is composed of two Availability Zones."

❌ False

Il ne faut surtout pas mémoriser "1 région = 2 AZ".

💰 15. Billing

À retenir :

Facturation mensuelle

La consommation des services est généralement regroupée dans une facture mensuelle.

Mais certains éléments peuvent avoir des modalités particulières.

Exemple :

Domain names et certains Elastic Metal setup fees peuvent être facturés lors de la commande.

🧩 16. Les associations à connaître PAR CŒUR

Si tu ne devais retenir que ça :

Kubernetes       → Kapsule
Sessions         → Redis
Analytics        → ClickHouse
Structured data  → Managed Database
Objects          → Bucket
Disk             → Block Storage
Archive          → Glacier
GPU / AI         → GPU Instances
ARM / Ampere     → CAX
Bare Metal       → Elastic Metal
Monitoring       → Cockpit
Permissions      → IAM
Public IP        → Flexible IP
Traffic          → Load Balancer
Pub/Sub          → Topics & Events
Point-to-point   → Queues
IaC              → Terraform
Email            → Transactional Email
LLM API          → Generative APIs

Et surtout :

Bucket = Object Storage
Volume = Block Storage
Database = données structurées
Redis = vitesse / sessions
Kapsule = Kubernetes

02 - Kubernetes

☸️ 1. Les fondamentaux Kubernetes

Pod

👉 Pod → conteneur(s) → Node

Node

❌ « Nodes are only virtual machines » → False

Namespace

Permet de séparer/organiser les ressources à l'intérieur d'un cluster.

✅ Namespace → séparation logique des ressources

Labels

Permettent notamment de sélectionner des objets Kubernetes.

kubectl get pods -l app=odoo

✅ True

🧩 2. Les principaux objets Kubernetes

Objet À retenir
Pod Plus petite unité déployable
Deployment Applications généralement stateless
ReplicaSet Maintient un nombre donné de Pods
StatefulSet Applications stateful
DaemonSet Pods sur chaque Node sélectionné
Job Tâche qui se termine
CronJob Job planifié

ReplicaSet

Son rôle est de garantir qu'un nombre défini de réplicas de Pods fonctionne.

👉 replicas: 3 → Kubernetes essaie de maintenir 3 Pods.

StatefulSet

❌ StatefulSet = stateless apps → False

👉 StatefulSet → stateful
👉 Deployment → stateless

🏗️ 3. Kapsule

Kapsule = ?

✅ Managed Kubernetes

Scaleway gère notamment le Control Plane.

❌ Kapsule = unmanaged Kubernetes → False

Qui fait quoi ?

Scaleway :

Utilisateur :

👉 Kapsule = Control Plane managé, workload utilisateur.

🎛️ 4. Control Plane

Le Control Plane :

Stockage de l'état du cluster

👉 etcd

etcd = base de données clé-valeur qui conserve l'état/configuration du cluster.

Application Pods ?

❌ Le Control Plane est responsable de faire tourner les Application Pods → False

👉 Les Pods tournent sur les Worker Nodes.

🔧 5. Worker Node

Les 3 composants demandés dans ton quiz :

  1. kubelet
  2. CNI
  3. Pods

À retenir :

kubelet → gère les conteneurs
CNI → réseau
Pods → unités qui encapsulent les conteneurs

🖥️ 6. kubectl vs Scaleway CLI

kubectl

Outil Kubernetes permettant d'interagir avec le cluster :

kubectl get pods
kubectl get deployments
kubectl apply -f app.yaml

👉 Kubernetes cluster → kubectl

Scaleway CLI (scw)

Outil permettant de gérer les ressources Scaleway depuis le terminal.

👉 Scaleway infrastructure → scw

Le CLI peut notamment servir à créer :

🔐 7. Authentification Kapsule

Pour se connecter au cluster :

✅ kubeconfig

Puis :

kubectl ...

👉 Kapsule → kubeconfig → kubectl

📦 8. Helm

Helm est le package manager de Kubernetes.

Kapsule supporte :

✅ Helm charts
✅ manifests YAML personnalisés

❌ « Helm is not supported » → False

🌐 9. Réseau Kapsule

Private Networking

Kapsule supporte les Private Networks.

✅ Yes, via VPCs

Configuration réseau par défaut

Pour ton quiz :

✅ Private Network with a /22 IP subnet

Et la question suivante confirmait :

✅ /22

👉 Kapsule → Private Network → /22

🔄 10. Autohealing

⚠️ Très important : le quiz t'a corrigé sur cette question.

Quand Autohealing est activé :

✅ Unresponsive nodes are restarted or replaced after 15 minutes.

✅ Failed pods are automatically rescheduled on healthy nodes.

❌ Upgrade automatique de Kubernetes
❌ Reboot quotidien du Control Plane

À retenir

Node malade → Autohealing → 15 min → restart / replacement

Et :

Pod défaillant → rescheduling sur un Node sain

Attention

Cette affirmation est :

"Autohealing can detect and replace nodes with excessive resource usage."

❌ False

Charge CPU/RAM élevée ≠ Node défaillant.

📈 11. Autoscaling

Le Cluster Autoscaling ajuste le nombre de Nodes selon les besoins.

Il peut :

✅ augmenter le nombre de Nodes lorsque la charge augmente
✅ réduire le nombre de Nodes lorsque la demande diminue
✅ contribuer à réduire les coûts

⚠️ Le quiz considère également comme bénéfice :

✅ Ensures high availability by distributing pods across nodes

Mais :

❌ Autoscaling ≠ upgrade Kubernetes

Activation

👉 Via the Console or API

⬆️ 12. Kubernetes upgrades

Pour Kapsule :

✅ Upgrade via Console / API / CLI
✅ Control Plane upgraded before Worker Nodes
✅ Les upgrades in-place minimisent les interruptions

❌ Downgrade vers une ancienne version

Politique de versions

Le quiz attend :

✅ Supports at least the latest patch versions of the last three minor releases

👉 3 dernières versions mineures → dernières versions patch

💰 13. Facturation Kapsule

Réponse du quiz :

✅ Based on the resources allocated to nodes, with no cost for the mutualized control plane

Donc :

Control Plane mutualisé → gratuit

Tu paies notamment les ressources utilisées :

💾 14. Block Storage

Block Storage sert notamment à fournir du stockage persistant aux applications.

👉 Très utile pour Kubernetes lorsqu'un Pod doit conserver ses données.

Snapshot

Un snapshot est une copie à un instant donné d'un volume Block Storage.

Il peut servir notamment à :

🗄️ 15. Odoo

Pour le TP Odoo de ta formation :

Vérifier le Deployment

kubectl get deployments odoo

Credentials PostgreSQL

Le quiz indique :

✅ Odoo récupère les credentials PostgreSQL via des environment variables provenant d'un Kubernetes Secret.

Et pour le backend Node.js :

✅ Même principe : credentials DB via Kubernetes Secret → environment variables.

PVC Odoo

La StorageClass attendue dans le cours :

✅ scw-bssd

⚠️ Il existe des évolutions dans les StorageClasses Scaleway, mais pour ce TP/quiz, retiens scw-bssd.

🔗 16. Kapsule + services Scaleway

Kapsule est intégré à l'écosystème Scaleway.

Compatible notamment avec :

✅ Load Balancers
✅ Block Storage
✅ Private Networks / VPC
✅ autres services Scaleway

👉 Kapsule n'est pas isolé du reste de l'écosystème.

🌍 17. Kapsule / Kosmos

Kosmos

Kosmos permet notamment d'intégrer des Nodes provenant de :

✅ AWS
✅ GCP

👉 Kosmos = Kubernetes multi-cloud

Kapsule → Kosmos

❌ On ne peut pas simplement transformer un cluster Kapsule existant en Kosmos avec SetClusterType.

👉 Kapsule et Kosmos = types de clusters distincts.

🛡️ 18. NAT

Le Dynamic NAT peut masquer les adresses IP privées internes lorsqu'elles communiquent avec Internet.

✅ Peut contribuer à réduire la surface d'attaque.

👉 Dynamic NAT → private IP → public IP

🌐 19. VPC

Création/configuration VPC — ordre exact du quiz

⚠️ Celui-ci nous a piégés deux fois 😄

L'ordre validé par le quiz est :

  1. Choose the region
  2. Enter a name and optional tags
  3. Create Private Networks inside the VPC
  4. Attach the previously created Resources – Kubernetes clusters and other resources
  5. Select the Routing type within your VPC

👉 Region → Name → Private Networks → Resources → Routing

🏗️ 20. Création d'un cluster Kapsule standard

Autre ordre à connaître par cœur :

  1. Choose the cluster type
  2. Choose the region
  3. Choose a control plane offer
  4. Configure a Private Network
  5. Review configuration and click "Create cluster"

👉 Cluster type → Region → Control Plane → Private Network → Create

🔄 21. Suppression d'un cluster

Avec :

with-additional-resources=true

La suppression du cluster peut également supprimer les ressources associées, notamment les Load Balancers concernés.

✅ True

📊 22. Monitoring Kapsule

Les réponses correctes du quiz :

✅ Kubernetes Dashboard
✅ Prometheus and Grafana (deployed by the user)
✅ Scaleway Cockpit

❌ Scaleway Load Balancer metrics comme outil de monitoring du cluster

👉 Dashboard + Prometheus/Grafana + Cockpit

🎯 23. Dedicated Control Plane

Le Dedicated Control Plane est destiné notamment aux :

✅ heavy workloads and business-critical applications

👉 Dedicated Control Plane = isolation / exigences élevées / workloads critiques

⚠️ 24. La question piège "ContainerSet"

Tu as eu cette question :

Which of the following is a valid Kubernetes object?

Le quiz a considéré :

✅ ContainerSet

et a marqué :

❌ DaemonSet

⚠️ Attention : c'est très probablement spécifique au contenu/quiz de cette formation ou une anomalie, car DaemonSet est bien un objet Kubernetes natif.

Donc pour ce questionnaire précis, si la même question revient :

👉 réponds comme le quiz l'attend : ContainerSet.

Mais pour ta connaissance Kubernetes réelle :

DaemonSet est bel et bien un objet Kubernetes valide.

🧠 LA CARTE MENTALE À APPRENDRE

Si tu ne dois retenir qu'une seule page :

                    KUBERNETES
                         │
             ┌───────────┴───────────┐
             │                       │
         CONTROL PLANE            WORKER NODE
             │                       │
       ┌─────┼─────┐          ┌──────┼──────┐
       │     │     │          │      │      │
      API  etcd scheduler   kubelet  CNI   Pods
                                             │
                                      containers

Kapsule
  ↓
Managed Kubernetes
  ↓
Scaleway manages Control Plane
  ↓
User manages workloads / worker nodes

Pod       → smallest deployable unit
Deployment → stateless
StatefulSet → stateful
ReplicaSet → maintains Pod replicas
DaemonSet → Pod on selected nodes
Namespace → separates resources
Labels → select objects
Helm → package manager
kubectl → Kubernetes CLI
scw → Scaleway CLI
kubeconfig → cluster authentication

Kapsule networking
        ↓
Private Network
        ↓
/22

Autohealing
   ↓
unresponsive Node
   ↓
15 minutes
   ↓
restart / replace

failed Pod
   ↓
rescheduled on healthy Node

Autoscaling
   ↓
increase Nodes when needed
decrease Nodes when demand drops
   ↓
cost optimization

Kapsule upgrades
   ↓
Console / API / CLI
   ↓
Control Plane first
   ↓
Workers
   ↓
NO downgrade
   ↓
3 latest minor releases

⭐ Les 15 choses que je mémoriserais en priorité

  1. Kapsule = Managed Kubernetes
  2. Control Plane = Scaleway
  3. Pods = Worker Nodes
  4. Pod = smallest deployable unit
  5. Pod peut contenir plusieurs containers
  6. Deployment = stateless
  7. StatefulSet = stateful
  8. ReplicaSet = nombre de replicas
  9. kubectl = Kubernetes
  10. scw = Scaleway
  11. kubeconfig = authentification cluster
  12. Kapsule Private Network = /22
  13. Autohealing = 15 min + failed Pods rescheduled
  14. Autoscaling = ajuste les Nodes
  15. Upgrade = Control Plane → Workers, jamais downgrade

03 - IAM, sécurité, stockage et observabilité

Objectif : comprendre les mécanismes essentiels de sécurité et d'administration Scaleway, savoir configurer les accès, protéger les secrets, gérer les quotas et superviser les ressources.

Périmètre : IAM, API keys, Organizations, Projects, quotas, Object Storage, KMS, Secret Manager, Cockpit, Audit Trail et alertes de facturation.

1. Organisation, Projects et ressources

1.1 Organization

L'Organization est le périmètre principal qui regroupe les membres, les applications IAM, les policies, les Projects et les ressources associées au compte.

1.2 Projects

Un Project sert à organiser les ressources et à séparer les environnements, les applications ou les équipes. Un Project peut regrouper des ressources situées dans plusieurs régions et Availability Zones.

Exemple d'organisation : deux environnements, chacun avec deux équipes produit, peuvent être séparés en quatre Projects :

Calcul : 2 environnements × 2 équipes = 4 Projects.

1.3 Ajouter une ressource depuis la console

  1. Sélectionner le Project dans lequel créer la ressource.
  2. Choisir la région ou l'Availability Zone si le service le demande.
  3. Configurer les paramètres de la ressource.
  4. Vérifier les paramètres et lancer la création.

Attention : les possibilités de déplacement d'une ressource vers un autre Project dépendent du service. Ne pas supposer que toutes les ressources peuvent être transférées directement : vérifier la procédure officielle du produit concerné.

2. IAM : identités et permissions

2.1 Les concepts fondamentaux

Concept Rôle
User Identité humaine appartenant à une Organization.
Application Identité non humaine utilisée notamment pour l'automatisation.
API key Identifiant et secret utilisés pour authentifier les requêtes API.
Policy Définit les permissions accordées à un principal dans un périmètre donné.
Group Regroupe des utilisateurs et des applications pour partager des policies.
Principal Identité ou groupe auquel une policy est associée.

Une policy définit notamment :

Le scope peut notamment être défini au niveau de l'Organization ou d'un Project, selon la configuration souhaitée.

2.2 Groupes et retrait d'un membre

Les groupes permettent d'appliquer une même policy à plusieurs identités.

Lorsqu'un utilisateur est retiré d'un groupe, il perd les permissions héritées de ce groupe. Il peut toutefois conserver les permissions qui lui sont accordées directement ou par d'autres groupes.

Le retrait d'un groupe ne signifie donc pas nécessairement que l'utilisateur perd tout accès à l'Organization.

2.3 Les API keys

Une API key Scaleway est composée de deux éléments :

Une API key hérite des permissions de son bearer, c'est-à-dire l'utilisateur ou l'application auquel elle est associée.

Une API key est rattachée à une seule Organization. Si plusieurs Organizations doivent être utilisées, une clé distincte est nécessaire pour chacune.

2.4 Utilisateur ou application comme bearer ?

Pour une automatisation ou un service de production utilisant une clé sur le long terme, privilégier une application IAM.

Les applications ne sont pas des comptes humains et ne sont pas liées à un utilisateur particulier.

2.5 Exemple : configuration Terraform avec une API key

Exemple de configuration du provider Scaleway. La clé doit être fournie par un mécanisme sécurisé, et non inscrite en clair dans un dépôt Git.

terraform {
  required_providers {
    scaleway = {
      source = "scaleway/scaleway"
    }
  }
}

provider "scaleway" {
  # Fournir les identifiants par variables d'environnement
  # ou par un mécanisme sécurisé adapté.
  region = "fr-par"
  zone   = "fr-par-1"
}

Exemple d'utilisation de variables d'environnement dans un shell :

export SCW_ACCESS_KEY="VOTRE_ACCESS_KEY"
export SCW_SECRET_KEY="VOTRE_SECRET_KEY"
export SCW_DEFAULT_PROJECT_ID="VOTRE_PROJECT_ID"

terraform init
terraform plan

Sécurité : ne pas committer les secrets, limiter les permissions au strict nécessaire et protéger le fichier d'état Terraform, qui peut contenir des données sensibles.

2.6 IAM et facturation

IAM est un service gratuit. Cela ne signifie pas que les ressources créées ou utilisées grâce à IAM sont gratuites.

IAM fonctionne avec les produits Scaleway compatibles. Pour vérifier la compatibilité exacte d'un service ou d'une action, consulter la documentation IAM du produit concerné.

3. Quotas et limites de l'Organization

3.1 Comprendre les quotas

Les quotas limitent le nombre ou la capacité des ressources utilisables. Ils sont associés à l'Organization et peuvent varier selon le produit, le type de ressource, la région et le niveau du compte.

Les quotas ne sont généralement pas des limites personnelles appliquées séparément à chaque utilisateur. Plusieurs utilisateurs d'une même Organization peuvent donc consommer le quota partagé du produit concerné.

3.2 Augmenter les quotas

Les deux actions principales permettant d'augmenter le niveau de compte sont :

  1. Valider le moyen de paiement.
  2. Vérifier son identité.

Si les quotas restent insuffisants après ces vérifications, contacter le support Scaleway pour demander une augmentation supplémentaire.

La console permet de consulter les quotas, leur utilisation et les limites applicables. Le bouton d'augmentation éventuellement proposé dépend du produit et du quota concerné.

Important : les limites par défaut peuvent évoluer. Vérifier la documentation officielle avant de mémoriser une valeur numérique telle que le nombre maximal de Projects.

4. Control plane et Data plane

4.1 Control plane

Le Control plane correspond à la couche de gestion et d'orchestration des ressources. Elle permet notamment de créer, configurer et administrer les ressources au moyen de la console ou des API.

Exemples :

4.2 Data plane

Le Data plane correspond à la couche opérationnelle où les ressources sont utilisées et exécutent leur travail.

Exemples :

Mémo : Control plane = gérer et orchestrer ; Data plane = utiliser et exécuter.

5. Secret Manager et secrets éphémères

5.1 À quoi sert Secret Manager ?

Secret Manager sert à stocker et gérer des données sensibles telles que des mots de passe, des tokens, des clés API et des identifiants d'applications.

Un secret peut posséder plusieurs versions. Les versions peuvent être activées ou désactivées pour contrôler leur accessibilité.

La taille maximale documentée d'un secret est de 64 kB.

5.2 Accorder un accès à une application

Pour autoriser une application à lire un secret :

  1. Identifier l'application IAM qui doit accéder au secret.
  2. Créer ou configurer une policy IAM adaptée.
  3. Accorder uniquement les permissions nécessaires à l'application et au périmètre concerné.
  4. Tester l'accès avec l'application.

Ne jamais partager des secrets en clair avec tous les membres d'une Organization simplement pour faciliter l'accès.

5.3 Politiques éphémères

Une politique éphémère définit la durée de vie ou les conditions d'expiration des versions d'un secret.

Politique Fonctionnement
Single access La version du secret expire après un accès unique.
Time to Live (TTL) La version reste valide et accessible pendant une durée définie.

La durée maximale documentée pour une politique TTL est d'un an.

Point important : la politique éphémère doit être configurée lors de la création du secret. Elle ne peut pas être ajoutée après coup à un secret existant et ne peut pas être retirée une fois appliquée.

5.4 Exemple de stockage sécurisé

Exemple de variables d'environnement utilisées par une application. Les valeurs sont fictives et ne doivent pas être remplacées par de vrais secrets dans un fichier versionné.

DATABASE_HOST="db.example.internal"
DATABASE_NAME="application"
DATABASE_USER="app_user"
DATABASE_PASSWORD="A_INJECTER_DEPUIS_SECRET_MANAGER"

En production, récupérer le mot de passe depuis Secret Manager ou par un mécanisme d'injection sécurisé adapté à l'environnement d'exécution.

6. KMS et chiffrement

6.1 Rôle de KMS

KMS (Key Management Service) sert à créer et gérer des clés cryptographiques. Il ne remplace pas Secret Manager pour le stockage de mots de passe, de tokens ou de secrets applicatifs.

6.2 Chiffrer de grands volumes de données

Pour chiffrer de grands volumes de données, on utilise généralement le chiffrement par enveloppe :

  1. Une clé de données (DEK, Data Encryption Key) chiffre les données.
  2. Une clé gérée ou protégée par KMS protège la DEK.
  3. La DEK protégée est stockée avec les métadonnées nécessaires au déchiffrement.
  4. Lors du déchiffrement, la DEK est récupérée de façon sécurisée puis utilisée pour déchiffrer les données.

Cette approche évite de demander à KMS de chiffrer directement chaque bloc d'un grand jeu de données.

6.3 Perte d'une clé

Si la clé nécessaire au déchiffrement est perdue et qu'aucune sauvegarde ou procédure de récupération n'existe, les données peuvent devenir irrécupérables.

Il faut prévoir une stratégie de sauvegarde, de contrôle d'accès et de récupération des clés avant de mettre en production un système de chiffrement.

7. Object Storage et chiffrement SSE

7.1 Quand utiliser Object Storage ?

Object Storage stocke des objets dans des buckets. Il est adapté notamment aux fichiers, images, archives, sauvegardes, journaux et données applicatives non structurées.

Il peut être utilisé par des applications et des solutions de calcul pour lire ou écrire des objets. Il ne remplace pas une base de données relationnelle lorsqu'il faut exécuter des requêtes SQL sur des données structurées.

7.2 Les méthodes SSE

Méthode Principe
SSE-S3 Chiffrement côté serveur avec des clés gérées par le service de stockage.
SSE-C Chiffrement côté serveur avec une clé fournie par le client.
SSE-KMS Terme générique désignant un chiffrement reposant sur un service de gestion de clés ; vérifier les méthodes effectivement prises en charge par le service.

Pour SSE-C, le serveur effectue le chiffrement, mais le client fournit la clé. La clé doit être protégée et conservée de manière fiable, car sa perte peut empêcher le déchiffrement.

7.3 Sécuriser l'accès aux buckets

La sécurité d'un bucket peut impliquer plusieurs mécanismes :

Les bucket policies ne doivent pas être considérées comme l'unique mécanisme de sécurité. La configuration exacte dépend du type d'accès recherché et des fonctionnalités du service.

En cas de refus d'accès, examiner l'ensemble des règles applicables, notamment les permissions IAM, les bucket policies et les paramètres de visibilité. Ne pas supposer qu'une autorisation présente dans une policy suffit à neutraliser un refus provenant d'un autre mécanisme.

8. Cockpit : métriques, logs et supervision

8.1 Rôle de Cockpit

Scaleway Cockpit fournit des fonctions d'observabilité permettant de collecter, stocker et analyser des données de supervision. Il peut recevoir des métriques et des logs provenant de ressources Scaleway et de systèmes compatibles externes.

8.2 Métriques, logs et traces

Type Utilité Exemple
Metrics Mesures numériques dans le temps. CPU, mémoire, réseau, latence.
Logs Événements et messages détaillés. Erreur d'application, échec de démarrage, message système.
Traces Parcours d'une requête à travers les services. Identifier l'étape qui ralentit une requête distribuée.

Les logs sont souvent les plus utiles pour rechercher les erreurs et les événements intervenus pendant le cycle de vie d'une ressource.

8.3 Surveiller une Instance ou un serveur Elastic Metal

Les métriques disponibles peuvent inclure l'utilisation du CPU, de la mémoire, du disque et du réseau. Leur disponibilité exacte dépend du service, de la configuration et des agents utilisés.

Pour les Instances Scaleway, Cockpit est l'outil intégré à privilégier pour consulter les métriques de supervision disponibles.

8.4 Envoyer des métriques avec Prometheus

Prometheus peut envoyer des métriques vers Cockpit grâce à l'interface Prometheus Remote Write.

Exemple de configuration indicative :

global:
  scrape_interval: 60s

remote_write:
  - url: https://metrics.cockpit.fr-par.scw.cloud/api/v1/push
    headers:
      X-Token: <VOTRE_TOKEN_COCKPIT>

Remplacer l'URL par le point de terminaison correspondant à la région Cockpit utilisée et injecter le token de manière sécurisée. Cet exemple illustre le principe ; il doit être adapté à la configuration réelle.

8.5 Périmètre des données Cockpit

Les données Cockpit sont associées à un périmètre de supervision lié au Project dans le contexte présenté par le cours. Il faut donc vérifier le Project sélectionné lorsqu'une métrique semble absente.

Pour diagnostiquer une métrique manquante, contrôler :

  1. Le Project et la région sélectionnés.
  2. La configuration de l'agent ou de Prometheus.
  3. Le point de terminaison Remote Write.
  4. Le token et les permissions nécessaires.
  5. La présence de données dans la période consultée.

9. Alertes et facturation

9.1 Alert Manager

Le service d'alertes doit être activé et configuré. Ne pas supposer que l'activation entraîne automatiquement l'activation de toutes les alertes préconfigurées dans toutes les régions.

Après activation, vérifier les alertes disponibles, leur état, leur périmètre et les conditions de déclenchement.

9.2 Alertes de facturation

Pour être averti lorsque la consommation et les coûts augmentent, configurer les alertes de facturation dans la section Billing de la console.

Les alertes CPU dans Cockpit ou Grafana servent à surveiller les performances techniques. Elles ne remplacent pas les alertes de facturation.

9.3 Audit Trail

Audit Trail conserve des événements permettant de savoir qui a effectué une action, quand elle a eu lieu et si la requête a réussi ou échoué.

Les événements sont stockés dans la région où l'activité s'est produite. Les événements liés aux produits globaux, comme IAM, sont stockés dans la région de Paris selon la documentation du service.

Pour rechercher un événement, filtrer notamment par région, période, Project, produit, méthode API et statut de la requête.

Audit Trail sert à l'audit et au dépannage. Il ne remplace pas les logs applicatifs ou les métriques de performance.

10. Comprendre les accès et les refus

10.1 Principe du moindre privilège

Accorder à chaque utilisateur ou application uniquement les permissions nécessaires à ses tâches.

Exemple :

10.2 Méthode de dépannage

  1. Identifier le principal qui effectue la requête.
  2. Identifier le bearer de l'API key et les permissions qui lui sont attribuées.
  3. Vérifier les policies attachées directement et via les groupes.
  4. Contrôler le scope de chaque policy.
  5. Vérifier les règles spécifiques du service, comme les bucket policies.
  6. Consulter Audit Trail et les logs pour obtenir des indices sur le refus.

11. Pièges du QCM à retenir

12. Liens officiels utiles

Conclusion

Pour sécuriser une infrastructure Scaleway, il faut combiner des identités bien définies, des policies IAM limitées au besoin, des API keys protégées, une gestion appropriée des secrets et des clés, ainsi qu'une supervision adaptée.

Les valeurs numériques et les fonctionnalités propres à un produit peuvent évoluer. En cas de doute, utiliser la documentation officielle du service plutôt que de généraliser une règle observée sur un autre produit.