Auf dem Weg zur Verbesserung der Infrastruktur beschloss ich, eine alte und schmerzhafte Frage zu klären: Bieten Sie Kollegen (Entwicklern, Testern, Administratoren usw.) ohne unnötige Gesten die Möglichkeit, ihre virtuellen Maschinen in ovirt unabhängig zu verwalten. Ovirt verfügt über mehrere Komponenten, die konfiguriert werden müssen, um mein Problem zu lösen: die Weboberfläche selbst, die noVNC-Konsole und das Hochladen von Disk-Images.
Ich habe den „Make It Bad“-Button nicht gefunden, deshalb zeige ich Ihnen, an welchen Knöpfen ich gedreht habe, um dieses Problem zu lösen. Vollständige Anleitung unter dem Schnitt:
HAFTUNGSAUSSCHLUSS:
Bevor ich anfange, möchte ich Sie darauf aufmerksam machen, dass Infrastrukturdomänen aus mir unbekannten Gründen in privaten LAN-, lokalen Zonen usw. erstellt werden.
Ich weiß nicht, was mich daran hindert, die Domäne einer Organisation in einer öffentlichen Zone zu verwenden. Anstelle der Domäne Alex-GLuck-Awesome-Company.local können Sie beispielsweise bedenkenlos die Domäne für die Unternehmenswebsite Alex-GLuck-Awesome-Company.com verwenden.
Wenn Sie befürchten, dass Sie den Überblick über die Domänen in Ihrer Organisation nicht behalten können und dadurch etwas kaputt geht, können Sie für bescheidene 100 Rubel pro Jahr eine separate Domäne für die aglac.com-Infrastruktur kaufen.
Warum ist es rentabler, Domains in öffentlichen Zonen zu nutzen:
1. Ihre Organisation bietet öffentlich zugängliche Dienstleistungen an: VPNDateiaustauschdienste (Seafile, Nextcloud) und andere. Die Einrichtung der Datenverschlüsselung bei solchen Diensten ist meist etwas nachlässig, und wir werden uns nicht gegen Man-in-the-Middle-Angriffe verteidigen, weil es schwierig ist (nicht wirklich).
Oder Sie haben eine Serviceadresse im Büro und eine andere im Internet und diese Verbindungen müssen aufrechterhalten werden, was unsere begrenzten Fachressourcen verschwendet. Nun, Mitarbeiter müssen sich verschiedene Adressen merken, was unpraktisch ist.
2. Sie können kostenlose Zertifizierungsstellen nutzen, um Ihre internen Dienste zu verschlüsseln.
Ihre eigene PKI ist ein Dienst, der unterstützt werden muss; 100 Rubel pro Jahr für die Möglichkeit, PKI von kostenlosen Zertifizierungsstellen zu nutzen, zahlen mehr als die Zeit der Mitarbeiter, die sie für andere Aufgaben aufwenden könnten.
3. Wenn Sie Ihre eigene Zertifizierungsstelle verwenden, machen Sie Ihren Remote-Mitarbeitern und Kollegen, die mit BYOD arbeiten möchten (bringen Sie ihre eigenen Laptops, Telefone, Tablets mit) einen Strich durch die Rechnung und können deren Geräte nicht verwalten. Sie bringen Macs, Linux, Androids, iOS, Windows mit – es hat keinen Sinn, einen solchen Zoo zu unterstützen.
Natürlich gibt es in allem Ausnahmen, und Banken mit anderen strengen Unternehmen, die Sicherheitsrichtlinien festgelegt haben, werden niemals in der Lage sein, den Service für ihre Mitarbeiter zu verbessern.
Für sie gibt es kostenpflichtige Zertifizierungsstellen, die ihr CA-Zertifikat für einen bestimmten Betrag signieren können (Google „Root Signing Service“).
Es gibt andere Gründe, warum es rentabler ist, eine öffentliche Domain zu nutzen (das Wichtigste ist, dass sie Ihnen gehört), aber darum geht es in diesem Artikel nicht.
Der Punkt ist...
AUFMERKSAMKEIT! Wenn Sie ein Let's Encrypt CA-Zertifikat zur vertrauenswürdigen Liste von ovirt hinzufügen, kann dies Auswirkungen auf die Sicherheit Ihrer Systeme haben!
Das erste, worauf Sie achten müssen, ist, dass es eine schlechte Praxis ist, Ovirt-Schnittstellen dem Internet zugänglich zu machen Dies macht praktisch keinen Sinn und schafft zusätzliche Sicherheitsbedrohungen.
Daher müssen Sie ein Zertifikat auf einem unserer Bastion-Hosts erhalten und dann das Zertifikat und den Schlüssel mit ovirt-engine auf unseren Host übertragen.
Wir fügen die externe Adresse unseres Bastion-Hosts mit unserem Ovirt-Namen zum DNS hinzu ovirtengine.example.comIch werde die Installation von Certbot und Nginx hinter den Kulissen lassen (wie das geht, ist bereits auf Habré beschrieben).
Njinx-Version >=1.15.7 einrichten
/etc/nginx/conf.d/default.conf
server {
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 unseren Schlüssel:
certbot certonly --nginx -d ovirtengine.example.com
Archivieren Sie 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:/
Kommen wir zum Ziel
Als nächstes entpacken wir unser Archiv und erstellen Symlinks, um das Verständnis des Dateispeicherortsystems 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 integrierte PKI in Ovirt so, dass der Java-Zertifikatspeicher (openjdk) zur Überprüfung von Zertifikaten 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 CA von Let's Encrypt in das Format und fügen sie dem Zertifikatspeicher von ovirt Java Trust Store hinzu (dies ist ein Container, der eine Liste von Zertifikaten enthält, 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 einen Parameter zur Unterstützung von Symlinks hinzu und entfernen den Parameter für die Zertifizierungsstelle, mit der Zertifikate überprüft werden (standardmäßig wird der Systemsatz vertrauenswürdiger Zertifizierungsstellen zur Überprüfung verwendet):
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
Dann sichern wir für alle Fälle die Originaldateien, die durch die automatische PKI von ovirt generiert wurden, und ersetzen sie durch symbolische Links mit 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 den 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 — Webserver Apache
ovirt-engine – ovirt-Webschnittstelle
ovirt-imageio-proxy – Daemon zum Herunterladen von Disk-Images
ovirt-websocket-proxy – Dienst zum Ausführen der noVNC-Konsole
Alle oben genannten Punkte wurden auf Ovirt Version 4.2 getestet.
Automatische Erneuerung von Zertifikaten auf ovirt
Gemäß guten Sicherheitspraktiken sollte keine Verbindung zwischen dem Bastion Host und dem Ovirt bestehen und das Zertifikat wird nur für 3 Monate ausgestellt. Hier entsteht eine kontroverse Frage darüber, wie ich die Erneuerung von Zertifikaten umgesetzt habe.
Ich habe ein Ansible-Playbook, das jeden Tag um 5 Uhr morgens nach einem Zeitplan auf Forman läuft. Dieses Playbook geht an den Ovirt, prüft die Gültigkeitsdauer des Zertifikats und wenn bis zum Ablauf weniger als 5 Tage verbleiben, geht es an den Bastion Host und beginnt mit der Aktualisierung des Zertifikats.
Nach der Aktualisierung des Zertifikats wird der Ordner mit den Dateien archiviert, auf den Forman-Host heruntergeladen und auf den Ovirt-Host entpackt. Anschließend stellt SElinux die Kontexte der Dateien wieder her und startet unsere Dienste neu.
Source: habr.com
