Les Bonnes Pratiques
Administration de machine virtuelle hébergée par le SMV
Vous administrez une VM ou un container hébergé sur un hyperviseur géré par le SMV, bienvenue et merci de votre confiance! Afin qu’elle soit réciproque nous vous proposons les quelques arrangements suivants concernant les besoins usuels d’une telle charge.
accords et responsabilitées
Le SMV offre une solution complète d’hébergement de services informatiques mais la responsabilité des VM hébergées restent à la charge du responsable de la VM.
Le SMV lui se charge de maintenir la plateforme de virtualisation à jour et opérationnelle dans la limite de ce que nous permet notre infrastructure d’hébergement.
accès à l’interface graphique du système de virtualisation
Machines virtuelles et containers offrent un équivalent du terminal local (/dev/ttyS?) via l’interface graphique de l’outil de virtualisation. Il est possible de créer des comptes locaux à ce GUI et de leur donner des droits pour un certain nombre d’opérations sur des VM choisies.
niveaux d’exposition et filtrage réseau
Le VLAN auquel est rattaché la VM bénéficie du filtrage par le firewall de l’IPGP
connexion root
Les administrateurs du SMV souhaite conserver la possibilité de s’authentifier par clef ssh sur le compte root des machines vituelles qu’il héberge.
Un objectif primordial est d’éviter au maximum de partager cet accès. Pour ce faire il est utile de parfois réduire le niveau de privilèges nécessaire par la création de groupes pour faciliter les modifications de contenu et de partage d’accès en écriture.
Pour des tâches plus triviales comme l’extinction/redémarrage de la VM cela peut se faire par l’interface graphique, et peut par conséquent être délégué.
Nous vous demandons également de ne pas altérer le contenu de /root/.ssh/authorized_keys car autant que possible notre mode d’intervention favori sur une VM quelle qu’elle soit est d’ouvir un shell dessus.
comptes utilisateurs
Vous avez toute lattitude pour ouvrir des comptes sur votre VM. Si possible sensibilisez vos utilisateurs à l’utilisation de clés pour les connections ssh si ils ne le sont pas déjà.
Il est également possible de créer sur ces systèmes des comptes partagés entre utilisateurs afin de simplifier encore l’accès commun à certains applicatifs. Inversement il est aussi possible de leur faire utiliser les bases d’utilisateurs maintenues par le SI ou le cas échéant par votre sous-unité via des protocoles usuels comme LDAP ou NIS.
installation de packages
Nous vous demandons de ne supprimer aucun des packages présents sur votre VM même si vous n’en voyez pas l’utilité sans notre consentement préalable.
Pour le reste il n’y a pas de limitation à priori, les outils de gestion de package sont assez explicites via leur logs. A ce propos d’ailleurs…
centralisation des logs
Le SMV opère un « serveur » de logs centralisé, si votre VM est un tant soit peu ouverte sur l’extérieur il est fort probable qu’elle soit directement configurée pour y enregistrer les messages simultanément au dépot habituel dans /var/log. Ainsi en cas de compromission du serveur exposé on conserve quoi qu’il arrive ensuite une trace des circonstances y ayant mené.
Si tel n’est pas le cas pour votre VM mais que vous souhaitez quand même disposer de cette facilité il suffira de nous le signaler.
hébergement de site web avec certification
Nous proposons une méthode de certification SSL-https pour des services enregistrés dans le DNS ou alias DNS, en utilisant les certificats délivrés par letsencrypt. L’utilisation de certificats délivrés par le SI reste toujours possible.
pour conclure
Merci pour votre lecture, vos remarques concernant ce document sont les bienvenues et vos questions complémentaires également!