Sécuriser l’auto-scaling des instances éphémères

L’auto-scaling remplace des machines durables par des capacités jetables, déclenchées par la charge ou par un événement. Le gain est net : absorber une variation sans maintenir un parc dormant. Le prix l’est aussi : l’inventaire, l’identité, la journalisation et la détection doivent suivre le cycle de vie réel, pas celui d’un serveur imaginé comme éternel.

→ Lire l’explication complète de la marmotte

Le compromis de sécurité des instances éphémères

Une instance éphémère est une ressource de calcul créée pour une durée limitée, puis détruite sans conservation locale prévue. Dans Kubernetes, elle correspond souvent à un pod piloté par un Deployment, un Job ou un mécanisme de mise à l’échelle. Dans une infrastructure virtuelle, elle peut être une machine issue d’un groupe d’instances géré. Sa disparition est une propriété de conception, pas un incident à réparer.

Le compromis central est brutal : l’éphémère réduit la dérive de configuration et accélère la reprise, mais il détruit les indices locaux que les contrôles historiques utilisent. Un agent de détection installé après le démarrage, un inventaire exécuté chaque nuit ou un export de journaux toutes les dix minutes ne couvrent pas une charge de travail qui vit trois minutes. Le serveur fantôme n’a pas besoin d’être compromis longtemps s’il peut exfiltrer avant la première collecte.

La position à tenir est donc la suivante : une instance auto-scalée ne doit jamais être une unité de confiance autonome. Son identité, sa configuration, ses secrets, ses règles réseau et ses traces doivent être fournis ou collectés par la plateforme avant qu’elle traite une requête. Si cette garantie n’existe pas, désactiver l’auto-scaling pour ce périmètre sensible est souvent moins coûteux qu’une enquête impossible. Les slides promettant une élasticité infinie oublient généralement de préciser qui retrouve le conteneur mort dans les journaux. Mystère marketing, sans doute.

L’éphémère ne garantit pas l’intégrité de l’image, la légitimité de la demande de scale-out, la confidentialité des secrets ni l’exhaustivité des traces. Ces propriétés viennent respectivement de la chaîne de livraison, du contrôle des déclencheurs, de la gestion d’identités et de la télémétrie centralisée. La sécurité cloud ne se résume pas à cocher « autoscaling enabled » dans une console.

Prérequis de plateforme et identité de charge

Une architecture exploitable exige un orchestrateur supporté et maintenu, une source d’images contrôlée, une autorité d’identité et un pipeline de journaux disponibles avant le premier déploiement. Pour Kubernetes, viser une version encore maintenue par le projet, un Container Runtime Interface (CRI) supporté, un moteur de politiques réseau et un contrôleur d’admission actif. Le Horizontal Pod Autoscaler (HPA) dépend du serveur de métriques pour les ressources processeur et mémoire ; les métriques applicatives nécessitent une API de métriques externe ou personnalisée. Sans cette dépendance, le scale-out devient un vœu pieux avec des graphiques.

L’identité de la charge doit être distincte de l’identité du nœud. Un pod compromis ne doit pas hériter des droits cloud de la machine qui l’héberge. Sur Kubernetes, associer chaque charge à un ServiceAccount dédié, puis fédérer cette identité vers le fournisseur cloud avec OpenID Connect (OIDC), protocole d’identité fondé sur des jetons signés. Côté fournisseur, réduire le rôle obtenu à l’action exacte : lire un objet précis, publier sur une file précise, rien de plus.

Éviter les clés d’accès statiques dans les variables d’environnement, les ConfigMaps ou les images. Une variable d’environnement n’est pas un coffre-fort, même avec un nom commençant par SECRET_. Utiliser des jetons courts, montés à l’exécution et renouvelés par l’autorité d’identité. La gestion des identités cloud doit établir la relation entre l’identité du workload, son compte de service et ses autorisations effectives.

La configuration d’amorçage doit être immuable : image référencée par digest, manifeste versionné, paramètres injectés par un mécanisme déclaré. Interdire les accès administrateur interactifs et les correctifs manuels dans l’instance. Un correctif qui n’entre pas dans l’image disparaît au prochain redémarrage, ce qui est à la fois une défense contre la dérive et une excellente machine à reproduire des incidents.

Surface d’attaque du déclenchement d’auto-scaling

Le déclencheur de mise à l’échelle est une frontière de sécurité. Une métrique manipulable peut provoquer un déni de service économique, saturer un quota ou multiplier les cibles disponibles pour une compromission. Un compteur de requêtes exposé à Internet, sans filtrage, permet à un attaquant de faire scaler l’application en envoyant du trafic inutile. Le budget partira en fumée avec une discipline presque admirable.

Plafonner le nombre de réplicas, définir des quotas par espace de noms et alerter sur toute création inhabituelle sont des contrôles obligatoires. Un maximum de réplicas n’est pas une optimisation de coût, c’est une limite de blast radius. Fixer aussi une capacité minimale lorsque le temps de démarrage excède la latence acceptable, car un service qui scale après saturation ne protège rien, il constate le décès avec ponctualité.

Les métriques utilisées pour le scale-out doivent provenir d’une source authentifiée et être séparées des métriques exposées au public. Une file de messages est un meilleur signal qu’un compteur HTTP brut lorsque le traitement est asynchrone, à condition que les producteurs soient authentifiés et que la profondeur de file ne puisse pas être gonflée gratuitement. Pour une métrique métier, imposer une validation côté serveur et détecter les variations incompatibles avec la capacité habituelle.

Le plan de contrôle de l’orchestrateur mérite la même rigueur que l’application. Restreindre les droits de création de pods, de modification de HPA et de lecture des Secrets avec Role-Based Access Control (RBAC), le contrôle d’accès par rôles. Une identité capable de modifier à la fois le déploiement et son mécanisme de scale-out peut déployer une image hostile à grande échelle. Ce n’est plus une élasticité, c’est un lance-flammes avec interface web.

Journalisation, inventaire et détection sans état local

L’inventaire doit être événementiel. Enregistrer la création, le placement, l’image par digest, le compte de service, les règles réseau applicables, l’adresse IP attribuée et la destruction. Ces événements doivent rejoindre un stockage central avant la fin possible de l’instance. L’inventaire quotidien reste utile pour les actifs persistants, mais il est structurellement insuffisant pour les charges éphémères.

Collecter les journaux applicatifs sur la sortie standard et les journaux d’erreur sur la sortie d’erreur, puis les expédier par l’agent du nœud ou par une collecte de plateforme. Ajouter à chaque événement l’identifiant de workload, le namespace, le digest de l’image, l’identité de déploiement et un identifiant de corrélation de requête. L’adresse IP seule ne suffit pas : elle est recyclable, donc elle ment avec une innocence parfaite.

Les traces d’audit du plan de contrôle doivent capturer les créations, suppressions, exec interactifs, montages de volumes et modifications de rôles. Une détection d’intrusion qui ne surveille que le système de fichiers local manque les attaques par API, pourtant dominantes dans les environnements orchestrés. Conserver les événements bruts dans un stockage à rétention verrouillée, puis indexer une copie de travail pour les recherches. La suppression d’un pod ne doit jamais supprimer son dossier d’enquête.

Les agents de sécurité installés dans chaque conteneur posent un problème de course : l’application peut accepter du trafic avant la fin de l’initialisation de l’agent. Préférer la détection au niveau nœud, les événements du runtime et les contrôles d’admission. Lorsqu’un agent dans le workload reste indispensable, bloquer la disponibilité du pod tant que son état déclaré n’est pas sain. Sinon, la fenêtre aveugle devient une fonctionnalité, mais personne ne l’assume dans la brochure.

Exemple Kubernetes : identité, limites et scale-out borné

L’exemple suivant suppose Kubernetes avec Metrics Server opérationnel, un contrôleur de politiques réseau et une fédération OIDC déjà configurée. Il crée une identité dédiée, borne les ressources et interdit une croissance sans plafond.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: api-lecture
  namespace: production
  annotations:
    # Remplacer par le rôle fédéré du fournisseur cloud.
    # Le pod reçoit un jeton court, pas une clé statique.
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/api-lecture

---
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: production
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      serviceAccountName: api-lecture
      automountServiceAccountToken: true
      containers:
        - name: api
          # Digest immuable : ne pas utiliser une étiquette mutable comme latest.
          image: registry.example.invalid/api@sha256:REMPPLACER_PAR_DIGEST
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "1"
              memory: "512Mi"
          securityContext:
            runAsNonRoot: true
            readOnlyRootFilesystem: true
            allowPrivilegeEscalation: false

---
# hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 2
  maxReplicas: 12 # Limite de coût et de surface d'attaque.
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Le digest doit être produit par la chaîne de livraison après analyse de vulnérabilités et signature de l’image. Un contrôleur d’admission doit refuser les images non signées, les conteneurs privilégiés, les privilèges Linux inutiles et les références par tag mutable. Le pipeline de livraison et la gestion des secrets portent cette garantie ; l’orchestrateur ne devine pas l’intention de sécurité.

Rotation, reprise et arrêt contrôlé

La rotation des secrets doit tolérer la coexistence temporaire de deux versions. Une charge qui ne sait lire qu’un secret au démarrage impose un redémarrage progressif après rotation ; elle ne reçoit pas une immunité magique parce qu’elle porte un conteneur. Préférer les jetons à durée de vie courte et les mécanismes qui renouvellent sans réécrire l’image.

La terminaison doit arrêter l’acceptation de nouvelles requêtes, drainer les connexions en cours, publier les derniers journaux, puis quitter avant l’expiration du délai imposé. Prévoir un délai de grâce cohérent avec le temps maximal de transaction. Une connexion interrompue pendant une opération non idempotente peut produire un double traitement, même si l’instance est impeccablement chiffrée et très fière d’elle.

Sauvegarder hors du cluster les données d’état, les configurations de déploiement, les politiques, les journaux d’audit et les métadonnées d’inventaire. Tester la restauration dans un environnement isolé : restaurer les volumes sans restaurer les identités, les politiques réseau et les clés de chiffrement ne reconstitue pas un service, seulement un tas de données qui attend une erreur humaine.

🐝 Ce qui arrive si on s’en passe

Sans ces garde-fous, chaque scale-out devient un point d’exécution que personne n’a validé. Avec une image référencée par étiquette mutable, un accès en écriture au registre suffit : la prochaine montée en charge tire la version modifiée sur de nouveaux réplicas, sans aucune modification du cluster ni trace de déploiement. Deux réplicas d’un même Deployment peuvent alors exécuter des codes différents. Une clé statique intégrée à l’image reste lisible dans les couches archivées du registre et dans chaque copie de l’image ; la révoquer impose de reconstruire et de redéployer tous les réplicas. Sans identité propre au workload, un pod compromis qui interroge le service de métadonnées du nœud obtient les droits cloud du nœud. Ces droits couvrent tous les pods hébergés. Enfin, un plafond de réplicas absent consomme le quota partagé du compte : d’autres services légitimes ne peuvent plus scaler.

🦫 Explication de la marmotte 🍫

La mise à l’échelle automatique crée davantage de programmes quand la demande augmente, puis en retire quand elle baisse. Chaque programme doit recevoir dès son démarrage une identité propre, des droits limités et une version connue du logiciel. Il ne doit pas contenir de mot de passe permanent, car une copie oubliée peut être récupérée puis utilisée longtemps après sa disparition.

Le système surveille une mesure, par exemple le nombre de demandes à traiter ou la quantité de travail en attente. Cette mesure déclenche la création de nouveaux programmes jusqu’à une limite fixée. Cette limite empêche une personne malveillante de provoquer une multiplication coûteuse en envoyant artificiellement beaucoup de demandes.

Comme ces programmes peuvent disparaître rapidement, leurs informations ne doivent pas rester seulement sur leur machine. Les événements de création, les actions réalisées, les erreurs et la destruction sont envoyés vers un lieu central avant ou pendant leur disparition. Sans cela, une enquête ne peut pas déterminer quel programme a traité une action suspecte.

Quand un programme s’arrête, il doit d’abord finir ce qui est déjà commencé et refuser les nouvelles demandes. Les données qui doivent survivre sont enregistrées ailleurs. Si la surveillance, l’identité ou l’envoi des journaux échouent, le programme ne doit pas recevoir de travail sensible : continuer aveuglément revient à accepter une zone sans trace ni contrôle.

Pages voisines

La citent

Sécuriser l’auto-scaling des instances éphémères

Elle cite

: les deux pages se citent l’une l’autre.

Sécuriser l’auto-scaling des instances éphémères

Sécuriser l’auto-scaling des instances éphémères

Le compromis de sécurité des instances éphémères

Prérequis de plateforme et identité de charge

Surface d’attaque du déclenchement d’auto-scaling

Journalisation, inventaire et détection sans état local

Exemple Kubernetes : identité, limites et scale-out borné

Rotation, reprise et arrêt contrôlé

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines