Security musings

Catégories

Tags

🔍 Licence d'Utilisation 🔍

Sauf mention contraire, le contenu de ce blog est sous licence CC BY-NC-ND 4.0.

© 2025 à 2042 Sébastien Gioria. Tous droits réservés.

⏱️
Temps de lecture estimé
~1 minute

Scheduler — Placement des Pods

Description & Rôle

Le Scheduler est responsable de l’attribution des pods aux nodes. Il évalue les contraintes (resources, labels, taints/tolerations, affinités) et décide sur quel node placer un pod. C’est un composant critique pour l’optimisation et la sécurité.

CVEs Connus

Analyse STRIDE

Risque Description
S — Spoofing Manipulation de labels pour placer un pod sur un node non autorisé
T — Tampering Modification des décisions du scheduler via affinity rules malveillantes
R — Repudiation Pas d’audit des décisions de placement
I — Information Disclosure Accès aux métadonnées des nodes via le scheduler
D — Denial of Service Placement inefficace des pods consommant trop de ressources
E — Elevation of Privilege Placement sur des nodes avec privilèges supérieurs

Best-Practices Minimales

  • Utiliser les taints et tolerations pour isoler les charges critiques ou sensibles
  • Implémenter les NodeAffinity pour placer les pods sensibles sur des nodes sécurisés
  • Appliquer ResourceRequests et ResourceLimits pour chaque pod
  • Utiliser PodDisruptionBudget pour la haute disponibilité
  • Monitorer les échecs de scheduling (kubectl describe node)
  • Appliquer le RBAC strict au ServiceAccount du Scheduler
  • Utiliser des NetworkPolicy combinées avec le placement pour isoler le trafic
  • Valider les affinity rules avant la production