En marchant sur le chemin de l'amélioration de l'infrastructure, j'ai décidé de terminer la question ancienne et douloureuse - donner aux collègues (développeurs, testeurs, administrateurs, etc.) la possibilité de gérer indépendamment leurs machines virtuelles en ovirt sans aucun geste supplémentaire. Il y a plusieurs composants dans ovirt que je dois configurer pour résoudre ma question: l'interface Web elle-même, la console noVNC et le remplissage des images disque.
Je n'ai pas trouvé les boutons "Faire scintiller", donc je montre quels stylos j'ai tourné pour résoudre ce problème. Instructions complètes sous la coupe:
AVIS DE NON-RESPONSABILITÉ:
Avant de commencer, je voudrais attirer l'attention sur le fait que, pour une raison que je ne connais pas, les domaines d'infrastructure sont créés dans des zones privées lan, locales, etc.
Ce qui m'empêche d'utiliser le domaine de l'organisation dans la zone publique m'est inconnu. Par exemple, au lieu du domaine Alex-GLuck-Awesome-Company.local, vous pouvez utiliser en toute sécurité le domaine pour le site de la société Alex-GLuck-Awesome-Company.com.
Si vous avez peur de ne pas pouvoir suivre les domaines de votre organisation, et cela cassera quelque chose, alors pour un modeste 100 roubles par an, vous pouvez prendre un domaine séparé pour l'infrastructure aglac.com.
Pourquoi il est plus rentable d'utiliser des domaines dans les zones publiques:
1. Services apparaissant dans votre espace public au sein de votre organisation: VPN, partage de fichiers (seafile, nextcloud) et autres. La configuration du chiffrement du trafic sur de tels services ressemble généralement à un bêtisier, et nous ne nous protégerons pas de MitM, car c'est difficile (en fait non).
Ou à l'intérieur du bureau, vous avez une adresse de service et une autre à partir d'Internet, et ces communications doivent être maintenues, sur lesquelles nos ressources spécialisées limitées sont dépensées. Eh bien, les employés doivent se souvenir de différentes adresses, ce qui n'est pas pratique.
2. Vous pouvez utiliser des autorités de certification gratuites pour crypter vos services internes.
Own PKI est un service qui doit être pris en charge, 100 roubles par an pour avoir la possibilité d'utiliser PKI auprès des autorités de certification gratuites plus que de payer le temps des employés qui pourraient le consacrer à d'autres tâches.
3. Lorsque vous utilisez votre propre autorité de certification, vous mettrez des bâtons dans les roues de vos employés et collègues distants qui souhaitent travailler avec BYOD (apportez leurs ordinateurs portables, téléphones, tablettes) et vous ne pouvez pas contrôler leurs appareils. Ils apportent des coquelicots, Linux, androïdes, iOS, Windows - il est inutile de soutenir un tel zoo.
En tout, bien sûr, il y a des exceptions, et les banques avec d'autres entreprises difficiles qui ont établi des politiques de sécurité ne pourront jamais améliorer le service pour leurs employés.
Il existe pour eux des autorités de certification payantes qui, pour un certain montant, peuvent signer leur certificat CA (google «root signature service»).
Il existe d'autres raisons pour lesquelles il est plus rentable d'utiliser un domaine public (la chose la plus importante est qu'il vous appartient), mais l'article ne traite pas de cela.
L'essentiel, mais le point ...
ATTENTION! Si vous ajoutez un certificat d'autorité de certification de Let's Encrypt à la liste de confiance d'Ovirt, cela peut affecter la sécurité de vos systèmes!La première chose à laquelle vous devez faire attention est que mettre l'interface Internet 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, vous devez obtenir un certificat sur certains de nos hôtes bastions, puis transférer le certificat et la clé sur notre hôte avec ovirt-engine.
Nous ajoutons l'adresse externe de notre hôte bastion dans le DNS avec notre nom ovirtengine.example.com
ovirt , je laisserai l'installation de certbot et nginx dans les coulisses (comment faire cela sur le hub a déjà été décrit).
Configuration de la version Nginx> = 1.15.7
/etc/nginx/conf.d/default.confserver { 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; } } server { 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; # OCSP-, 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
Téléchargez l'archive de l'hôte bastion, téléchargez-la sur notre ovirt-enzhin:
scp bastion-host:/tmp/ovirtengine.example.com.tgz /tmp/ scp /tmp/ovirtengine.example.com.tgz ovirtengine.example.com:/
Aller à l'objectif
Ensuite, nous décompressons notre archive et créons des liens symboliques pour simplifier la compréhension du système de localisation de 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 l'ovirt pour utiliser le magasin de certificats java (openjdk) pour la vérification des certificats:
cat << EOF > /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 l'autorité de certification de Let's Encrypt au format der et ajoutons un ovirt au magasin de certificats du magasin de confiance Java (c'est un tel conteneur où se trouve la liste des certificats, un tel 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, ajoutons le paramètre pour prendre en charge les liens symboliques et supprimons le paramètre pour CA, qui vérifiera les certificats (par défaut, le système utilisera le jeu de CA de confiance pour vérification):
sed -r -i 's|^(SSLCACertificateFile.*)|#\1|g' /etc/httpd/conf.d/ssl.conf sed -r -i '0,/(^#?SSLCACertificateFile.*)/ s//\1\nOptions FollowSymlinks/' /etc/httpd/conf.d/ssl.conf
Après cela, juste au cas où, nous sauvegarderons automatiquement les fichiers originaux générés via PKI ovirt'a et remplacerons les liens symboliques par des 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 restaurons 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 chargement d'images disque
ovirt-websocket-proxy - service pour exécuter la console noVNC
Tout ce qui précède a été testé sur la version 4.2 de l'ovirt.
Renouvellement automatique des certificats pour ovirt
Conformément aux bonnes pratiques de sécurité, il ne doit pas y avoir de connexion entre l'hôte bastion et l'ovirt, et le certificat n'est délivré que pour 3 mois. C'est là qu'un point controversé apparaît sur la façon dont j'ai mis en œuvre le renouvellement des certificats.
J'ai un livre de jeu d'ensemble qui fonctionne sur le contremaître tous les jours à 5 heures du matin selon un horaire. Ce playbook entre dans l'ovirt, vérifie la période de validité du certificat et s'il reste moins de 5 jours avant l'expiration, il va à l'hôte bastion et commence le renouvellement du certificat.
Après avoir mis à jour le certificat, il archive le dossier avec les fichiers, télécharge le formulaire sur l'hôte et décompresse l'hôte ovirt. Ensuite, il restaure les contextes SElinux sur les fichiers et redémarre nos services.