Sécurité de la plateforme

Serveurs (LinuxAid)

• Vulnérabilités connues. Le portail liste les CVE ouvertes de chaque serveur, avec leur sévérité et la prochaine fenêtre de mise à jour.
• Fin de vie. Une alerte se déclenche 75 jours avant que la version du système d'exploitation ne reçoive plus de mises à jour de sécurité gratuites. Si la version bénéficie d'un support étendu payant, l'alerte continue de se déclencher jusqu'à la fin de celui-ci.
• Pare-feu. Chaque serveur remonte sous forme de métriques le nombre de paquets par règle de son pare-feu, mais aucune alerte ne se déclenche sur le trafic rejeté.
• Durcissement. SSH n'autorise que des échanges de clés, des chiffrements et des MAC robustes, sauf sur RHEL 6. auditd peut être activé serveur par serveur, et SELinux sur les serveurs de la famille RHEL.
• Snapshots de dépôts. Lorsque votre configuration épingle une date de snapshot, les paquets proviennent de ce snapshot. La veille de chaque cycle de mise à jour, nous poussons une branche qui avance cette date : une fois fusionnée, chaque serveur du cycle reçoit les mêmes mises à jour.

Kubernetes (KubeAid)

• Sécurité de la chaîne d'approvisionnement.
  • Analyse des images. Trivy analyse les images de conteneurs que vous exploitez et conserve les vulnérabilités critiques et élevées qui disposent d'un correctif. Sur les clusters qui remontent à Obmondo, le portail les affiche.
  • Miroir de registre. Harbor peut mettre ces images en miroir et les analyser également.
• Pare-feu. Les politiques réseau Cilium peuvent filtrer le trafic entrant et sortant. Cilium exporte chaque paquet rejeté sous forme de métrique Hubble, mais aucune alerte ne se déclenche lorsque le trafic refusé reste élevé.
• Sécurité à l'exécution. Tetragon enregistre l'exécution des processus, le chargement des modules noyau et les changements de privilèges, et ne suit les accès réseau et fichiers qu'une fois une politique ajoutée pour cela. KubeArmor peut bloquer ce que vos politiques interdisent.
• Politiques d'admission. Kyverno ou Gatekeeper peuvent arrêter, avant leur démarrage, les charges de travail qui enfreignent vos règles.

Les politiques réseau, l'analyse des images, la détection à l'exécution et les politiques d'admission sont des options que vous activez cluster par cluster.

Les correctifs sont déployés pendant les fenêtres de service que vous choisissez. Lorsqu'un correctif nécessite une modification du dépôt de configuration, comme une nouvelle version de KubeAid ou une nouvelle date de snapshot, il arrive d'abord sous forme de branche à fusionner.