Editions ENI Livres | Vidéos | e-Formations
Aller plus loin
Introduction
Bien que notre objectif soit atteint, nous souhaitons vous donner le plus d’informations possible sur les étapes suivantes, tant organisationnelles que techniques, et les possibilités d’évolution qui s’offrent pour améliorer le fonctionnement de notre plateforme, la faire évoluer et assurer une meilleure sécurité.
Plan de reprise d’activité
1. Quand le désastre arrive
Figure 1 : Quand le pire arrive
Quand on parle de haute disponibilité, on parle souvent, en parallèle, de reprise d’activité, d’où l’expression HA-DR (High Availability-Disaster Recovery).
Si le but de la haute disponibilité est de garantir la disponibilité des applications dans le plus grand nombre de cas de figure possible, il faut aussi prévoir ce qui semble parfois improbable : une panne majeure qui conduit à l’indisponibilité partielle ou totale du service, voire à sa destruction totale.
C’est souvent une leçon apprise trop tard : il ne faut jamais pécher par excès de confiance. Rappelons la loi de Murphy : tout ce qui est susceptible d’aller mal ira mal. Et le corollaire de Finagle : tout ce qui peut aller mal le fera au pire moment. Rappelons aussi qu’il existe deux sortes d’ingénieurs système : ceux qui ont fait une énorme bêtise et ceux qui vont la faire.
Les auteurs ont eu l’occasion d’expérimenter en production réelle divers cas de figure. Les métiers liés à la production informatique mettent parfois les nerfs à rude épreuve. Comment réagir lorsqu’on perd l’interconnexion entre deux centres de données ? Comment réagir lorsque quelqu’un éteint tous les répartiteurs de charge en même temps, coupant ainsi intégralement les accès à l’ensemble des serveurs ?
Tout système créé par un être humain est forcément imparfait. La plupart des incidents et accidents sont d’ailleurs le fait d’interventions humaines, involontaires ou non.
Quand tout va mal, que tout est perdu, il faut alors penser au plan B, voire au plan C. Comment redémarrer ? En ayant anticipé la catastrophe et mis en place un plan de redémarrage des services.
L’incendie d’un centre de données d’OVH en mars 2021 est un rappel de l’importance du plan de reprise d’activité et une leçon durement apprise par ceux qui croyaient à la magie du cloud, qui pensaient qu’un développeur fullstack pouvait remplacer un Ops ou un architecte...
Sauvegardes
1. Redondance vs sauvegarde
Un RAID, un cluster, toute solution redondante ne sont pas des sauvegardes. Une copie locale archivée sur un disque dur, du même serveur ou d’un serveur dans la même zone, n’est pas une sauvegarde. Ne confiez pas vos données à un informaticien vous disant le contraire.
Il est très important de souligner cette évidence. Les événements de mars 2021 qui ont conduit à la perte définitive de milliers de sites web et de services, voire à la perte de l’ensemble des données de certaines entreprises, sont un nouveau rappel à l’ordre.
Figure 3 : Pas de sauvegarde... Le désespoir suite à la perte d’un centre de données
Que ce soit sur le cloud ou dans un datacenter qui vous appartient, les sauvegardes sont nécessaires et vitales. Dans un monde devenu numérique, la donnée est le composant vital de toute organisation, mais pas seulement. Combien de drames sont liés à la perte des photos de famille suite au crash d’une application, à la défaillance d’une clé USB, d’une carte mémoire, d’un disque dur ?
Les sauvegardes doivent être externalisées : elles ne doivent pas se situer sur le même centre de données que les serveurs. Si possible, elles doivent être disponibles en double exemplaire. Sur un cloud, on peut utiliser des volumes particuliers dupliqués entre plusieurs zones et régions pour garantir leur disponibilité. Sous AWS par exemple, des buckets S3 peuvent être répliqués entre plusieurs régions, et même entre buckets.
Un compartiment (bucket) s3 est un mode de stockage objet proposé par le fournisseur de cloud Amazon. Ce stockage est accessible via le protocole HTTP.
Les sauvegardes doivent être testées : on s’assure...
Sécurité
1. Container et root
a. Exemple d’exploit
Depuis le début, nous avons déployé l’application eni-todo sans nous soucier de ses droits, aussi bien lors de la construction de l’image que lors de son exécution. Or, notre application tourne avec l’UID 0, en tant que root.
La plupart des images disponibles publiquement, que ce soit sur Docker Hub ou dans des dépôts Git, ne tiennent pas compte de la gestion des utilisateurs : au sein du container, tout ou presque tourne en tant que root.
Or, on applique normalement le principe du moindre privilège : on ne devrait faire tourner un produit qu’avec les droits qui lui sont strictement nécessaires.
Prenons l’exemple de la simple image Nginx de test utilisée dans le chapitre Mise en place d’un cluster Kubernetes, et voyons ce qu’il est possible de faire avec.
$ docker run --name some-nginx -d nginx Si vous ouvrez un shell interactif au sein de ce container, vous voyez que vous êtes root.
$ docker exec -ti 87335d0ba8d7 bash
root@87335d0ba8d7:/# id
uid=0(root) gid=0(root) groups=0(root) Cela ne signifie pas forcément que nous pouvons aussi obtenir les droits root sur l’hôte : le container s’exécute dans son propre namespace. Notre container Nginx est ici limité et le risque est faible. Mais par défaut, les containers et l’hôte se partagent UID et GID. Si, par une faille de sécurité ou via un démarrage de container construit d’une certaine manière, le container a accès aux composants de l’hôte, alors cela devient dangereux. Voici un exemple simple avec les volumes en montant le répertoire /etc de l’hôte au sein du container :
seb@infra01:~$ docker run --name some-nginx -v /etc:/mnt/etc -d
nginx
128d2f6e22a75ae40be9e03bfe8321adac76e849e8cc26144a661730cf09a6ff
$ docker exec -ti 128d2f6e22a7 bash
root@128d2f6e22a7:/# echo "seb ALL=(ALL) NOPASSWD: ALL" >
mnt/etc/sudoers.d/seb
root@128d2f6e22a7:/# exit
seb@infra01:~$ sudo -l
User seb may run the following commands on infra01:
(ALL) NOPASSWD: ALL L’utilisateur seb, sans pouvoirs particuliers, a lancé un container qui lui a permis de modifier ses droits...
Surveillance
1. Métriques
Les métriques sont essentiellement la collecte d’informations sur les processeurs, la mémoire, les disques et le réseau afin d’en vérifier les performances. Grâce à ces valeurs et à leur suivi, il devient possible d’analyser les consommations des différentes ressources et d’agir en conséquence :
-
Créer de nouveaux serveurs
-
Étendre l’espace disque
-
Ajouter de la mémoire
-
Mieux répartir les services
La surveillance des métriques se fait souvent avec des outils de monitoring et des sondes comme Nagios et Centreon, qui sont libres, et des protocoles comme SNMP. Des outils système en ligne de commande comme sar, iostat, mpstat, etc. permettent d’obtenir des informations utiles.
Kubernetes propose une API dédiée aux métriques, qui nécessite l’utilisation d’un contrôleur annexe et optionnel. Cette API donne accès à de nouvelles fonctions, comme l’autoscaling (ajout et suppression dynamique de pods en fonction d’une charge).
Pour tester cette fonctionnalité, il faut installer un pipeline de collecte de métriques. Il en existe de deux sortes selon qu’ils sont basés sur la collecte des métriques liées uniquement au cluster, par exemple metrics-server, ou sur la collecte des métriques liées à l’environnement complet, comme Prometheus.
Metrics-server est disponible ici : https://github.com/kubernetes-sigs/metrics-server
Prometheus, plus complet mais aussi plus complexe, est disponible ici : https://prometheus.io/
Vous pouvez installer rapidement metrics-server comme ceci :
$ kubectl apply -f https://github.com/kubernetes-sigs/
metrics-server/releases/latest/download/components.yaml
serviceaccount/metrics-server created
clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-
reader created
clusterrole.rbac.authorization.k8s.io/system:metrics-server created
rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created ...Stockage
Au chapitre Déploiement avec Kubernetes, nous avons évoqué l’existence de plusieurs projets permettant la mise en place d’une infrastructure de stockage qui repose sur une infrastructure Kubernetes.
MinIO offre un ersatz de S3 dans un cluster Kubernetes.
Des projets comme OpenEBS ou GlusterFS déploient des pods avec des droits élevés pour monter les disques ou accéder au LVM sous-jacent afin d’utiliser ces nodes Kubernetes comme éléments du cluster de données. Il est alors possible d’ajouter des nodes pour répondre à la croissance des besoins de des applications.
Rook est également un projet d’infrastructure de stockage cloud-native ayant pour but de fournir les opérateurs Kubernetes permettant la mise en place de serveur Ceph, Cassandra ou NFS dans un cluster.
Bien que les opérateurs s’améliorent en permanence et fournissent des mécanismes de réparation, d’ajustement et de mise à jour de plus en plus automatisés, ces types d’outils restent extrêmement gourmands en ressources CPU, RAM, réseau et bien entendu en ressources liées aux accès en lecture et en écriture sur les disques hébergeant la solution.
Il est donc très important de bien cadrer les besoins et les objectifs avant de vouloir mettre un CephFS (Ceph File System) sur un cluster...
PaaS
Figure 5 : Système d’information classique vs solutions IaaS, PaaS ou SaaS
Kubernetes offre de très nombreux services et facilite grandement la difficile tâche de mettre en place une infrastructure haute disponibilité.
Les choix sont nombreux... Quel moteur de réseau utiliser, quel contrôleur ingress, quel moteur OCI (moteur de containerisation) ? Comment sécuriser son cluster et assurer le patch management de ses images ? Comment vérifier la cohérence de tous ces composants ?
Comme nous l’avons évoqué au chapitre Orchestration, c’est le rôle des distributions de gérer tout cela. La distribution que les auteurs ont le plus largement expérimentée est celle de Red Hat : OpenShift.
OpenShift est la première distribution à pousser une sécurité par défaut en interdisant notamment les pods en root par défaut, en imposant l’utilisation de SELinux et en fournissant un registry Docker sécurisé et segmenté.
OpenShift apporte également une intégration avec ses outils de monitoring et d’alerte orientés PaaS. La sécurité apportée par l’isolation des namespaces, dont la portée a été étendue aux projets (projects), est poussée à l’extrême directement dans ses composants d’infrastructure. Par exemple, un utilisateur ayant accès au projet A et pas au projet B n’a pas accès aux traces du projet B dans le service Kibana du cluster.
Les auteurs ayant passé de nombreuses heures à mettre en place ce type d’isolation avec des composants de diverses provenances peuvent attester que le gain apporté par une distribution comme OpenShift est appréciable.
Enfin, et c’est sans doute sa grande force, OpenShift est avant tout une solution PaaS destinée à faire du source to delivery. OpenShift intègre l’ensemble des mécanismes d’écoute de dépôts de code source, de construction d’images (build s2i), de déploiement, de suivi des images de base, de supervision. Tous sont présents, intégrés et apportent une fluidité dans le processus de développement et de maintenance qui ne se retrouve...
