Labels pour le scheduling basé sur le risque

Références externes :

• https://kubernetes.io/docs/reference/labels-annotations-taints/ labels standards kubernetes

Contexte et description de la problématique

Problèmes rencontrés

• Besoin d’intégrer plus de noeuds hébergés avec plus de diversité sur le cluster
• Gestion du risque difficile à appréhender pour les individus, parce peu de clarté sur le risque global
• Charte peu claire, demandant au membre d’accepter pleinement tous les risques

Alternatives considérées

• Tagger les déploiements par un filtrage basée sur un rôle, en employant typiquement node-role.kubernetes.io comme c’est déjà le cas pour Garage et labelliser les noeuds en conséquence
• Tagger les déploiements par niveau de risque, sur une échelle faible/moyen/élevé et labelliser les noeuds en conséquence
• Tagger les déploiements par classes de risque, indiquant par exemple la présence de données sensibles, la possibilité pour un tiers d’exécuter du code, et labelliser les noeuds en conséquence

Eléments moteurs de la décision

• Tagger les déploiements est complexe à l’échelle :
  • Cela fonctionne assez bien pour gérer du DaemonSet sur une partie du parc, donnant des rôles techniques à des noeuds, tout particulièrement sur les services d’infrastructure
  • Toutefois cela empêche le déploiement d’un nouveau service sans intervention des administrateurs des noeuds pour déclarer le service sur leurs noeuds
• Tagger des risques dans l’absolu est trop subjectif :
  • Deux membres hébergeant des noeuds peuvent ne pas être d’accord sur le niveau d’un même risque, parce qu’ils ne sont pas impactés de la même manière, par exemple le risque que leur noeud serve à exécuter du code malveillant n’est pas le même selon qu’on vit seul, qu’on est le seul responsable de son accès Internet, etc.
  • Le risque est susceptible d’évoluer dans le temps, et même très rapidement, par exemple lors de vagues de spam, etc.
  • En résultat un risque qualifié élevé a très peu de chances d’être hébergé tout court, hors ce cas de figure existe (typiquement la CI)
• Tagger des classes de risque complète le tagging des déploiements par rôle :
  • Les classes de risque doivent être peu nombreuses pour pouvoir être taggées sur les noeuds à l’avance et changer peu en exploitation
  • Chacun est libre de faire évoluer les classes de risques pris sur ses noeuds, chez soi, sur son wan, etc.
  • Tout nouveau déploiement doit spécifier la ou les classes de risques associées
  • Les rôles de noeud restent intéressants en complément pour le pilotage des fonctions d’infrastructure (quel noeud fait du stockage, quel noeud fait de l’ingress, etc.)

Conclusion

• ✅ Conservation des rôles par noeud basés sur node-role.kubernetes.io en remplacement progressif de node-role.acides.org, non standard
• ✅ Ajout de labels par noeud de type risk.acides.org, prenant l’une des valeurs suivants (liste évolutive) :
  • risk.acides.org/personal-data, le noeud peut héberger de la donnée personnelle soumise à la réglementation, et dont le vol, même physique, constituerait une infraction
  • risk.acides.org/illegal-data, le noeud peut héberger de la donnée illégale, qui bien que pas mise à disposition directement par le noeud, pourrait justifier la saisie du matériel en cas d’enquête
  • risk.acides.org/public-ip, le noeud peut être identifié comme une adresse publique des services de l’association, l’exposant plus directement en cas d’enquête sur un contenu servi par l’association ou d’attaque sur l’association
  • risk.acides.org/federated-data, le noeud fédère de la donnée en émettant des requêtes vers des pairs (Fédivers par exemple), et la donnée peut être illégale ou susciter des réponses de tiers (dénonciation, rétaliation, etc.)
  • risk.acides.org/arbitrary-code, le noeud exécute des traitements non maîtrisés par les membres de l’association (ce qui exclut les déploiements, y-compris personnels des membres, mais inclut typiquement la CI), qui peuvent générer toute sorte de trafic illégal, y-compris d’attaque à travers ou à l’encontre du réseau local de l’hébergeur
  • risk.acides.org/spof, le noeud constitue un point unique de défaillance (Single Point of Failure), et sa défaillance pourrait entraîner une interruption significative des services ou de l’infrastructure
• ✅ Ajout de nodeSelector en conséquence sur les workloads

Conséquences

• 👍 Matérialisation plus fine et prise de conscience collective du risque lié à l’hébergement
• 👍 Ouverture à l’hébergement de nouveaux noeuds, y-compris sur des zones jusqu’ici difficiles
• 👎 Effort de prime abord pour modifier le déploiement de la majorité des workloads