En amĂ©liorant l'infrastructure, j'ai dĂ©cidĂ© de rĂ©soudre une problĂ©matique ancienne et complexe : donner Ă mes collĂšgues (dĂ©veloppeurs, testeurs, administrateurs, etc.) la possibilitĂ© de gĂ©rer eux-mĂȘmes leurs machines virtuelles dans ovirt, sans mouvements inutiles. Dans ovirt, plusieurs composants doivent ĂȘtre configurĂ©s pour rĂ©soudre ma problĂ©matique : l'interface web, la console noVNC et le tĂ©lĂ©chargement des images disque.
Je n'ai pas trouvé de boutons « Faire Génial », donc je montre quelles manettes j'ai tournées pour résoudre cette tùche. Le guide complet se trouve ci-dessous :

AVERTISSEMENT :
Avant de commencer, je voudrais rappeler qu'en raison d'une raison qui m'est inconnue, les domaines de l'infrastructure sont créés dans des zones privées telles que lan, local, etc.
Ce qui empĂȘche d'utiliser le domaine de l'organisation dans une zone publique m'est inconnu. Par exemple, au lieu du domaine Alex-GLuck-Awesome-Company.local, on peut facilement utiliser le domaine du site de l'entreprise Alex-GLuck-Awesome-Company.com.
Si vous craignez de ne pas pouvoir suivre les domaines au sein de votre organisation et que cela cause des problÚmes, pour un modeste 100 roubles par an, vous pouvez obtenir un domaine séparé pour l'infrastructure aglac.com.
Pourquoi il est avantageux d'utiliser des domaines dans des zones publiques :
1. Vous avez des services au sein de l'organisation qui sortent dans l'espace public : VPN, échange de fichiers (seafile, nextcloud) et d'autres. La configuration du chiffrement du trafic sur de tels services est généralement faite de maniÚre désordonnée, et nous ne nous protégerons pas contre les attaques MitM, car cela est compliqué (en réalité, ce n'est pas le cas).
Ou vous avez une adresse de service dans le bureau, mais une autre sur Internet, et ces connexions doivent ĂȘtre maintenues, ce qui nĂ©cessite l'utilisation de nos ressources limitĂ©es en spĂ©cialistes. De plus, les employĂ©s doivent mĂ©moriser diffĂ©rentes adresses, ce qui est peu pratique.
2. Vous pouvez utiliser des centres de certification gratuits pour le chiffrement de vos services internes.
Avoir sa propre PKI est un service qui doit ĂȘtre maintenu ; dĂ©penser 100 roubles par an pour utiliser une PKI fournie par des centres de certification gratuits compense largement le temps que les employĂ©s pourraient consacrer Ă d'autres tĂąches.
3. En utilisant votre propre centre de certification, vous compliquerez la tĂąche Ă vos employĂ©s et collĂšgues distants qui souhaitent travailler avec le BYOD (apportez vos propres ordinateurs portables, tĂ©lĂ©phones, tablettes) et vous ne pourrez pas gĂ©rer leurs appareils. Ils apportent des Macs, des Linux, des Android, des iOS, des Windows â maintenir un tel zoo nâa tout simplement aucun sens.
Il y a bien sûr des exceptions, et les banques avec d'autres entreprises d'entreprise rigoureuses qui ont des politiques de sécurité bien établies ne pourront jamais améliorer leur service pour leurs employés.
Il existe des centres de certification payants qui, contre une certaine somme, peuvent signer leur certificat CA (recherchez « service de signature root » sur Google).
Il y a aussi d'autres raisons pour lesquelles utiliser un domaine public est plus avantageux (le plus important étant qu'il vous appartient), mais ce n'est pas le sujet de cet article.
L'essentiel, c'est que...
ATTENTION ! Si vous ajoutez le certificat CA de Letâs Encrypt Ă la liste des certificats de confiance pour ovirt, cela peut affecter la sĂ©curitĂ© de vos systĂšmes !
La premiÚre chose à noter est que publier les interfaces d'ovirt sur Internet est une mauvaise pratique, car cela n'a aucun sens pratique et crée des menaces de sécurité supplémentaires.
Par conséquent, il est nécessaire d'obtenir un certificat sur l'un de nos bastions, puis de transférer le certificat et la clé sur notre hÎte avec ovirt-engine.
Ajoutons l'adresse externe de notre hÎte bastion dans le DNS avec notre nom d'ovirt. ovirtengine.example.com, l'installation de certbot et de nginx je laisserai de cÎté (comment faire cela est déjà décrit sur Habr).
Configurer nginx version >=1.15.7
/etc/nginx/conf.d/default.conf
serveur {
server_name _;
listen 80 default_server;
location /robots.txt { alias /usr/share/nginx/html/robots.txt; }
location /.well-known {
root /usr/share/nginx/html;
}
location / {
return 444;
}
}
serveur {
server_name _;
listen 443 ssl http2 default_server;
location /robots.txt { alias /usr/share/nginx/html/robots.txt; }
location /.well-known {
root /usr/share/nginx/html;
}
ssl_certificate /etc/nginx/ssl/$ssl_server_name/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/$ssl_server_name/privkey.pem;
ssl_protocols TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
# permet au serveur d'annexer les réponses OCSP, réduisant ainsi le temps de chargement des pages pour les utilisateurs
ssl_stapling on;
ssl_stapling_verify on;
add_header Strict-Transport-Security max-age=15768000;
location / {
return 444;
}
}
Ensuite, nous obtenons notre certificat et notre clé :
certbot certonly --nginx -d ovirtengine.example.com
Nous archivons notre certificat et notre clé :
tar Phczf /tmp/ovirtengine.example.com.tgz /etc/letsencrypt/live/ovirtengine.example.com
Nous téléchargeons l'archive depuis le bastion, puis la transférons sur notre oVirt Engine :
scp bastion-host:/tmp/ovirtengine.example.com.tgz /tmp/
scp /tmp/ovirtengine.example.com.tgz ovirtengine.example.com:/
Passons à l'étape suivante
Ensuite, nous extrayons notre archive et créons des liens symboliques pour simplifier la compréhension du systÚme de répartition des fichiers :
tar Pxzf /ovirtengine.example.com.tgz && rm -f ovirtengine.example.com.tgz
mkdir -p /etc/letsencrypt/live
ln -f -s /etc/letsencrypt/live /etc/pki/letsencrypt
Nous configurons le PKI intégré dans oVirt afin d'utiliser un magasin de certificats Java (openjdk) pour vérifier les certificats :
cat < /etc/ovirt-engine/engine.conf.d/99-setup-pki.conf
ENGINE_HTTPS_PKI_TRUST_STORE="/etc/pki/java/cacerts"
ENGINE_HTTPS_PKI_TRUST_STORE_PASSWORD=""
EOF
Nous convertissons le CA de Let's Encrypt en format der et l'ajoutons au magasin de certificats de confiance Java d'oVirt (c'est un conteneur qui contient une liste de certificats, ce systÚme est utilisé en Java) :
openssl x509 -outform der -in /etc/pki/letsencrypt/ovirtengine.example.com/chain.pem -out /tmp/ovirtengine.example.com.chain.der
keytool -import -alias "Let's Encrypt Authority X3" -file /tmp/ovirtengine.example.com.chain.der -keystore /etc/pki/ovirt-engine/.truststore -storepass $(grep '^ENGINE_PKI_TRUST_STORE_PASSWORD' /etc/ovirt-engine/engine.conf.d/10-setup-pki.conf | cut -f 2 -d '"')
rm -f /tmp/ovirtengine.example.com.chain.der
Nous modifions les paramÚtres SSL pour apache, en ajoutant un paramÚtre pour la prise en charge des symlinks et en supprimant le paramÚtre pour CA, qui sert à vérifier les certificats (par défaut, le systÚme utilisera l'ensemble de CA de confiance pour la vérification) :
sed -r -i 's|^(SSLCACertificateFile.*)|#1|g' /etc/httpd/conf.d/ssl.conf
sed -r -i '0,/(^#?SSLCACertificateFile.*)/ s//1nOptions FollowSymlinks/' /etc/httpd/conf.d/ssl.conf
Ensuite, nous faisons une sauvegarde des fichiers originaux, générés automatiquement via PKI ovirt, et nous les remplaçons par des symlinks pointant vers les fichiers de Let's Encrypt :
ln -f -s /etc/pki/letsencrypt/ovirtengine.example.com/fullchain.pem /etc/pki/ovirt-engine/apache-chain.pem
services=( 'apache' 'imageio-proxy' 'websocket-proxy' )
for i in "${services[@]}"; do
cp /etc/pki/ovirt-engine/certs/$i.cer{,."$( date +%F )".bak}
cp /etc/pki/ovirt-engine/keys/$i.key.nopass{,."$( date +%F )".bak}
ln -f -s /etc/pki/letsencrypt/ovirtengine.example.com/privkey.pem /etc/pki/ovirt-engine/keys/$i.key.nopass
ln -f -s /etc/pki/letsencrypt/ovirtengine.example.com/cert.pem /etc/pki/ovirt-engine/certs/{apache,imageio-proxy,websocket-proxy}.cer
done
Nous rétablissons les contextes SElinux sur les fichiers et redémarrons nos services (httpd, ovirt-engine, ovirt-imageio-proxy, ovirt-websocket-proxy) :
restorecon -Rv /etc/pki
systemctl restart httpd ovirt-engine ovirt-imageio-proxy ovirt-websocket-proxy
httpd â serveur web apache
ovirt-engine â interface web ovirt
ovirt-imageio-proxy â dĂ©mon pour le tĂ©lĂ©chargement des images de disque
ovirt-websocket-proxy â service pour l'utilisation de la console noVNC
Tout ce qui précÚde a été testé sur la version d'ovirt 4.2.
Auto-renouvellement des certificats sur ovirt
Selon les bonnes pratiques de sécurité, il ne doit pas y avoir de lien entre le bastion et ovirt, et le certificat n'est délivré que pour 3 mois. C'est là qu'apparaßt le point discutable sur la façon dont le renouvellement des certificats est implémenté chez moi.
J'ai un playbook Ansible qui s'exécute sur foreman tous les jours à 5 heures du matin selon un horaire. Ce playbook se connecte à ovirt, vérifie la date d'expiration du certificat, et si moins de 5 jours restent avant l'expiration, il se rend sur le bastion et lance le renouvellement du certificat.
AprÚs le renouvellement du certificat, il archive le dossier avec les fichiers, le télécharge sur le hÎte de foreman et le décompresse sur le hÎte d'ovirt. Ensuite, il rétablit les contextes SElinux sur les fichiers et redémarre nos services.
Source : habr.com
