Auf dem Weg zur Verbesserung der Infrastruktur beschloss ich, die alte und schmerzhafte Frage zu beantworten - Kollegen (Entwicklern, Testern, Administratoren usw.) die Möglichkeit zu geben, ihre virtuellen Maschinen in ovirt ohne zusätzliche Gesten unabhängig zu verwalten. Es gibt mehrere Komponenten in ovirt, die ich konfigurieren muss, um meine Frage zu lösen: die Weboberfläche selbst, die noVNC-Konsole und das Ausfüllen von Disk-Images.
Ich habe die Schaltflächen "Make Flicker" nicht gefunden und zeige daher, welche Griffe ich gedreht habe, um dieses Problem zu lösen. Vollständige Anleitung unter dem Schnitt:
HAFTUNGSAUSSCHLUSS:
Bevor ich anfange, möchte ich darauf hinweisen, dass Infrastrukturdomänen aus einem mir unbekannten Grund in privaten Zonen lan, lokal usw. erstellt werden.
Was mich daran hindert, die Domain der Organisation in der öffentlichen Zone zu verwenden, ist mir unbekannt. Beispielsweise können Sie anstelle der Domain Alex-GLuck-Awesome-Company.local die Domain sicher für die Site der Firma Alex-GLuck-Awesome-Company.com verwenden.
Wenn Sie befürchten, dass Sie nicht in der Lage sind, die Domänen in Ihrer Organisation im Auge zu behalten, und dies etwas kaputt macht, können Sie für bescheidene 100 Rubel pro Jahr eine separate Domäne für die aglac.com-Infrastruktur verwenden.
Warum es rentabler ist, Domains in öffentlichen Zonen zu verwenden:
1. Dienste, die in Ihrem öffentlichen Bereich innerhalb Ihrer Organisation angezeigt werden: VPN, Dateifreigabe (Seafile, Nextcloud) und andere. Das Konfigurieren der Verkehrsverschlüsselung für solche Dienste sieht normalerweise wie ein Blooper aus, und wir werden uns nicht vor MitM schützen, da dies schwierig ist (eigentlich nicht).
Oder Sie haben im Büro eine Serviceadresse und eine andere aus dem Internet, und diese Kommunikation muss aufrechterhalten werden, wofür unsere begrenzten Fachressourcen aufgewendet werden. Nun, Mitarbeiter müssen sich unterschiedliche Adressen merken, was unpraktisch ist.
2. Sie können kostenlose Zertifizierungsstellen verwenden, um Ihre internen Dienste zu verschlüsseln.
Die eigene PKI ist ein Dienst, der unterstützt werden muss, 100 Rubel pro Jahr, damit die Möglichkeit besteht, die PKI von kostenlosen Zertifizierungsstellen mehr zu nutzen, als die Zeit der Mitarbeiter zu bezahlen, die sie für andere Aufgaben ausgeben könnten.
3. Wenn Sie Ihre eigene Zertifizierungsstelle verwenden, stecken Sie Stöcke in die Räder Ihrer Remote-Mitarbeiter und Kollegen, die mit BYOD arbeiten möchten (bringen Sie ihre Laptops, Telefone, Tablets mit), und Sie können ihre Geräte nicht steuern. Sie bringen Mohn, Linux, Androiden, iOS, Windows - es macht keinen Sinn, einen solchen Zoo zu unterstützen.
Insgesamt gibt es natürlich Ausnahmen, und Banken mit anderen harten Unternehmen, die Sicherheitsrichtlinien festgelegt haben, werden den Service für ihre Mitarbeiter niemals verbessern können.
Für sie gibt es bezahlte Zertifizierungsstellen, die für einen bestimmten Betrag ihr CA-Zertifikat signieren können (Google „Root Signing Service“).
Es gibt andere Gründe, warum es rentabler ist, eine Public Domain zu verwenden (das Wichtigste ist, dass sie Ihnen gehört), aber in dem Artikel geht es nicht darum.
Das Endergebnis, aber der Punkt ...
ACHTUNG! Wenn Sie der vertrauenswürdigen Liste des Ovirt ein CA-Zertifikat von Let's Encrypt hinzufügen, kann dies die Sicherheit Ihrer Systeme beeinträchtigen!Das erste, worauf Sie achten müssen, ist, dass es eine schlechte Praxis ist, die Schnittstellen des Internets ins Internet zu stellen, weil Dies macht praktisch keinen Sinn und schafft zusätzliche Sicherheitsbedrohungen.
Daher müssen Sie ein Zertifikat für einige unserer Bastion-Hosts erhalten und dann das Zertifikat und den Schlüssel mit ovirt-engine an unseren Host übertragen.
Wir fügen die externe Adresse unseres Bastion-Hosts im DNS mit unserem Namen ovirtengine.example.com
hinzu . Ich werde die Installation von certbot und nginx hinter den Kulissen belassen (wie dies auf dem Hub gemacht wird, wurde bereits beschrieben).
Konfigurieren der Nginx-Version> = 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; } }
Dann bekommen wir unser Zertifikat und Schlüssel:
certbot certonly --nginx -d ovirtengine.example.com
Wir archivieren unser Zertifikat und unseren Schlüssel:
tar Phczf /tmp/ovirtengine.example.com.tgz /etc/letsencrypt/live/ovirtengine.example.com
Laden Sie das Archiv vom Bastion-Host herunter und laden Sie es auf unsere ovirt-Engine hoch:
scp bastion-host:/tmp/ovirtengine.example.com.tgz /tmp/ scp /tmp/ovirtengine.example.com.tgz ovirtengine.example.com:/
Gehe zum Ziel
Als nächstes entpacken wir unser Archiv und erstellen Symlinks, um das Verständnis des Dateispeicherortes zu vereinfachen:
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
Wir konfigurieren das im ovirt integrierte pki so, dass der Java-Zertifikatspeicher (openjdk) zur Zertifikatüberprüfung verwendet wird:
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
Wir konvertieren die Zertifizierungsstelle von Let's Encrypt in das Format und fügen dem Java Trust Store-Zertifikatspeicher ein Ovirt hinzu (dies ist ein solcher Container, in dem sich die Liste der Zertifikate befindet, ein solches System wird in Java verwendet):
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
Wir bearbeiten die SSL-Einstellungen für Apache, fügen den Parameter zur Unterstützung von Symlinks hinzu und entfernen den Parameter für CA, der Zertifikate überprüft (standardmäßig verwendet das System den vertrauenswürdigen CA-Satz zur Überprüfung):
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
Danach sichern wir für alle Fälle die über PKI ovirt generierten Originaldateien automatisch und ersetzen die Symlinks durch Dateien von 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
Wir stellen SElinux-Kontexte in Dateien wieder her und starten unsere Dienste neu (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 - Apache-Webserver
ovirt-engine - ovirt-Webschnittstelle
ovirt-imageio-proxy - Daemon zum Laden von Disk-Images
ovirt-websocket-proxy - Dienst zum Ausführen der noVNC-Konsole
Alle oben genannten Funktionen wurden in Version 4.2 des Ovirt getestet.
Zertifikate zur automatischen Verlängerung für ovirt
Gemäß den guten Sicherheitspraktiken sollte keine Verbindung zwischen dem Bastionswirt und dem Ovirt bestehen, und das Zertifikat wird nur für 3 Monate ausgestellt. Hier erscheint ein kontroverser Punkt darüber, wie ich die Zertifikatserneuerung implementiert habe.
Ich habe ein Ensemble-Spielbuch, das täglich um 5 Uhr morgens nach einem Zeitplan auf Vorarbeiter läuft. Dieses Playbook geht in den Ovirt, überprüft die Gültigkeitsdauer des Zertifikats und wenn weniger als 5 Tage vor dem Ablauf verbleiben, geht es zum Bastion-Host und startet die Zertifikatserneuerung.
Nach dem Aktualisieren des Zertifikats wird der Ordner mit den Dateien archiviert, der Forman-Host heruntergeladen und der Ovirt-Host auf den Host entpackt. Anschließend werden die SElinux-Kontexte in den Dateien wiederhergestellt und unsere Dienste neu gestartet.