Quelques conseils sur le déploiement OpenVZ

Je m’appuie fortement sur OpenVZ. Dans cet article, j’aimerais partager certaines de mes expériences personnelles dans le déploiement d’OpenVZ. Je suppose que les lecteurs savent déjà comment installer OpenVZ et connaissent les bases d’OpenVZ. Cet article décrit quelques conseils sur l’utilisation d’OpenVZ via la ligne de commande. Si vous préférez l’interface graphique à la ligne de commande, veuillez vous référer à comment installer WebVZ.

La configuration décrite ici suit ces directives :

le serveur réel a un minimum de logiciels installés (j’utilise debian Etch avec une installation minimale) comme point de départ. Des applications supplémentaires sont installées au fur et à mesure du déploiement.
le serveur réel doit être aussi sécurisé que possible. D’un autre côté, je veux le garder simple et facile à configurer/maintenir. J’ai donc choisi un compromis : je m’appuie uniquement sur ce qui peut être facilement déployé avec debian et je ne vais pas chercher des choses de sécurité supplémentaires comme openwall, selinux, grsecurity, etc.
chaque service nécessaire est déployé dans un conteneur séparé, afin qu’ils interfèrent le moins possible entre eux.
La détection d’intrusion pour le serveur réel ainsi que pour les conteneurs est déployée sur le serveur réel en utilisant OSSEC.
le pare-feu (iptables) est configuré sur le serveur réel ; les conteneurs n’exécutent que les services.
Je m’appuie sur ssh comme seul moyen d’accéder et de maintenir le serveur réel et les conteneurs.

Sécurité de base

Avant de déployer des conteneurs ovz, je fais quelques modifications à la configuration du serveur réel pour le rendre plus sécurisé :

désactiver le mot de passe root
ajouter un utilisateur admin-user qui peut sudo tout ; cet utilisateur a un mot de passe simple
ajouter un utilisateur ssh-user qui peut ssh au serveur réel ; après avoir téléchargé la clé ssh pour cet utilisateur, je change la ligne dans .ssh/authorized_keys pour lire : command="/bin/su - admin-user" ssh-rsa AAAA... et change /etc/pam.d/su pour permettre uniquement à cet utilisateur de su : auth required pam_wheel.so group=ssh-user
pour copier des fichiers depuis/vers le serveur réel, je crée un autre utilisateur sftp-user et installe MySecureShell
changer sshd_config de sorte que : - seuls ssh-user et sftp-user sont autorisés à se connecter
l’authentification par mot de passe est désactivée (après avoir téléchargé les clés ssh pour ssh-user et sftp-user)
sshd fonctionne sur un port non standard

Le schéma ci-dessus fonctionne comme suit : pour se connecter au serveur réel, nous nous connectons en tant que ssh-user. Ensuite, nous devons taper le mot de passe pour admin-user. Si quelqu’un obtient la clé ssh pour ssh-user, il doit quand même connaître le mot de passe pour admin-user afin d’accéder au serveur (l’échec de /bin/su - admin générera immédiatement une alerte par e-mail par OSSEC).

Pour copier des fichiers depuis/vers le serveur, nous utilisons sftp avec le compte sftp-user. Si quelqu’un obtient la clé ssh pour cet utilisateur, ce n’est pas un si gros problème, car il ne peut accéder qu’aux fichiers sous son $HOME.

Création de conteneurs OpenVZ

Je trouve plus confortable de créer un modèle pour tous les conteneurs, afin que lorsque j’ai besoin d’un nouveau conteneur, je fasse simplement un clone à partir du modèle. J’utilise uniquement debian stable pour le serveur réel ainsi que pour les conteneurs. Donc, la première étape consiste à créer un modèle et à l’ajuster à mon goût :

créer un nouveau conteneur : vzctl create 2002 --ostemplate debian-4.0-amd64-minimal
définir quelques paramètres de base : vzctl set 2002 --ipadd 192.168.100.2 --nameserver 1.2.3.4 --hostname host2 --save
démarrer le conteneur : vzctl start 2002
entrer dans le conteneur : vzctl enter 2002
Je préfère garder tout au minimum, et ajouter des éléments au besoin. Étant donné que l’installation d’un paquet avec debian est si facile, il faut très peu d’efforts pour installer n’importe quel paquet dont nous avons besoin. Donc, je fais les changements suivants pour le modèle : - exécuter aptitude et décocher Options/Handling des dépendances/Installer automatiquement les paquets recommandés
supprimer certains paquets que je ne veux pas dans le modèle : bsdmainutils ed groff-base info iptables libconsole libgdbm3 man-db manpages nano netcat openssh-client openssh-server quota ssh traceroute
éditer /etc/apt/sources.list pour l’ajuster à mes préférences
puis j’arrête le modèle : vzctl stop 2002

Ensuite, chaque fois que j’ai besoin d’un nouveau conteneur, j’utilise un script vz-clone comme suit :

#!/bin/bash

# script pour cloner un openvz VE

set -e

if [ -z "$2" ]; then
    echo "Usage: $0  "
    exit 1
fi

cfg="/etc/vz/conf/$1.conf"
newcfg="/etc/vz/conf/$2.conf"

if [ ! -e $cfg ]; then 
    echo $cfg not found!
    exit 1
fi

VEID=$1
. $cfg
veprivate="$VE_PRIVATE"

VEID=$2
. $cfg
newveprivate="$VE_PRIVATE"

if [ -e $newcfg ]; then 
    echo $newcfg already exists!
    exit 1
fi

if [ -e $newveprivate ]; then 
    echo $newveprivate already exists!
    exit 1
fi

if vzlist | fgrep -w -q $1
then
    vzctl stop $1
fi

echo "Cloning $cfg to $newcfg"
cp -a $cfg $newcfg

echo "Cloning $veprivate to $newveprivate"
mkdir -p $newveprivate
cd $veprivate
tar cf - . | (cd $newveprivate && tar xf -)

echo "Do not forget to edit $newcfg (you need to edit at least HOSTNAME and IP_ADDRESS)"
echo "Also do not forget to make an alias"

Utilisation :

sudo sh vz-clone 2002 2010

Cloning /etc/vz/conf/2002.conf to /etc/vz/conf/2010.conf  
Cloning /vz/private/2002 to /vz/private/2010  
Do not forget to edit /etc/vz/conf/2010.conf (you need to edit at least HOSTNAME and IP_ADDRESS)  
Also do not forget to make an alias

Selon votre /etc/vz/vz.conf, les chemins ci-dessus peuvent être différents. J’utilise les paramètres suivants :

VE_ROOT=/vz/root/$VEID
VE_PRIVATE=/vz/private/$VEID

Ensuite, nous devons éditer /etc/vz/conf/2010.conf, changer par exemple HOSTNAME en host10, IP_ADDRESS en 192.168.100.10 et nous sommes prêts à partir avec le nouveau conteneur. Nous allons également créer un alias pour le nouveau conteneur, qui sera décrit dans la section suivante.

Travailler avec des conteneurs OpenVZ

Les conteneurs ovz sont identifiés par un numéro. Je trouve plus facile de les référencer par nom/alias, afin que je n’aie pas à me souvenir par exemple que 2010 est l’identifiant du conteneur exécutant le service dns. En dehors de cela, je veux également me libérer de la mémoire des différentes commandes vzctl, vzlist, vzquota, etc. et de leurs paramètres. Donc, je crée quelques scripts simples pour m’aider.

D’abord, je crée une liste d’alias /etc/vz-aliases : # alias pour les VE openvz 2001 test 2002 template 2010 dns 2020 ldap 2030 mail 2040 web ...
Pour traduire entre les ID et les alias, je crée un script /usr/local/bin/vz-get-alias comme ci-dessous et fais de vz-get-veid un lien symbolique vers vz-get-alias : #!/bin/sh vz_alias_file="/etc/vz-aliases" case $0 in *vz-get-alias) cat $vz_alias_file | egrep "^[[:space:]]*$1[[:space:]]" | awk '{print $2}' ;; *vz-get-veid) cat $vz_alias_file | egrep "[[:space:]]$1[[:space:]]*$" | awk '{print $1}' ;; esac
Ensuite, je mets des commandes fréquentes pour manipuler les conteneurs ovz dans un script appelé /usr/local/bin/vz-cmd-generic : #!/bin/sh set -e ## gérer vz-list d'abord, car cela ne nécessite pas d'ID/alias case $0 in *vz-list) sedfile=`mktemp` cat /etc/vz-aliases | egrep '^[0-9]' | \ sed 's/$[0-9]*$ *$[a-zA-Z0-9-]*$/s,\1 .*,\&\2,/' > $sedfile sudo vzlist "$@" | sed 's/ $//' | \ sed -f $sedfile | \ sed '1s/$/ALIAS/' exit ;; esac ## les autres commandes nécessitent un ID ou un alias if [ -z "$1" ]; then echo "Usage: $0 | []" exit 1 fi veid=`/root/bin/vz-get-veid $1` if [ -z "$veid" ]; then veid=$1 fi shift case $0 in *vz-start) sudo vzctl start $veid ;; *vz-restart) sudo vzctl restart $veid ;; *vz-stop) sudo vzctl stop $veid ;; *vz-enter) sudo vzctl enter $veid ;; *vz-exec) sudo vzctl exec $veid "$@" ;; *vz-edit) sudo vi /etc/vz/conf/$veid.conf ;; *vz-quota-ls) sudo vzquota stat $veid ;; *vz-ubc) sudo head -2 /proc/user_beancounters sudo cat /proc/user_beancounters | egrep -A23 "^[[:space:]]+${veid}:" ;; esac Et fais de toutes les commandes vz-start, vz-stop, vz-exec, etc. des liens symboliques vers ce script vz-cmd-generic.

L’utilisation est alors simple :

pour lister tous les conteneurs en cours d’exécution : vz-list VEID NPROC STATUS IP_ADDR HOSTNAME ALIAS 2010 15 running 192.168.100.10 host10 dns 2020 8 running 192.168.100.20 host20 ldap 2030 23 running 192.168.100.30 host30 mail 2040 11 running 192.168.100.40 host40 web
pour lister tous les conteneurs (y compris ceux qui ne fonctionnent pas) : vz-list -a VEID NPROC STATUS IP_ADDR HOSTNAME ALIAS 2002 - stopped 192.168.100.2 host2 template 2010 15 running 192.168.100.10 host10 dns 2020 8 running 192.168.100.20 host20 ldap 2030 23 running 192.168.100.30 host30 mail 2040 11 running 192.168.100.40 host40 web
pour démarrer/arrêter/redémarrer un conteneur : - vz-start dns
```
vz-stop dns
```
```
vz-restart dns
```
pour exécuter une commande à l’intérieur d’un conteneur : vz-exec dns aptitude update
pour vérifier UBC d’un conteneur : vz-ubc dns
pour vérifier le quota d’un conteneur : vz-quota-ls dns
il est également possible d’utiliser un ID au lieu d’un alias : vz-ubc 2010

Il est également bon de garder l’alias unique entre différents serveurs réels, afin que nous puissions partager /etc/vz-aliases entre eux sans conflits.

Cet article est déjà assez long, donc arrêtons-nous ici. Nous continuerons dans la prochaine partie, où nous discuterons de questions telles que comment déployer la détection d’intrusion avec OSSEC, comment surveiller et définir les paramètres UBC pour les conteneurs, etc.