Auf dem Weg zur Verbesserung der Infrastruktur habe ich beschlossen, eine alte, mühsame Angelegenheit zu klären – ohne überflüssige Umstände den Kollegen (Entwicklern, Testern, Admins usw.) die Möglichkeit zu geben, ihre virtuellen Maschinen in oVirt selbst zu verwalten. In oVirt gibt es mehrere Komponenten, die konfiguriert werden müssen, um dieses Problem zu lösen: die Weboberfläche selbst, die noVNC-Konsole und das Hochladen von Disk-Images.
Ich habe keine „Super-Taste“ gefunden, daher zeige ich, welche Einstellungen ich vorgenommen habe, um diese Aufgabe zu lösen. Eine vollständige Anleitung findet ihr weiter unten:
HAFTUNGSAUSSCHLUSS:
Zunächst möchte ich darauf hinweisen, dass aus mir unbekannten Gründen die Infrastruktur-Domains in privaten Zonen wie lan, local usw. erstellt werden.
Was mich daran hindert, die Domain der Organisation in der öffentlichen Zone zu verwenden, ist mir nicht bekannt. Zum Beispiel könnte man anstelle der Domain Alex-GLuck-Awesome-Company.local problemlos die Domain für die Unternehmenswebsite Alex-GLuck-Awesome-Company.com nutzen.
Wenn Sie befürchten, dass Sie die Domains in Ihrer Organisation nicht im Blick behalten können und dies Probleme verursachen könnte, können Sie für bescheidene 100 Rubel pro Jahr eine separate Domain für die Infrastruktur aglac.com erwerben.
Warum es vorteilhafter ist, Domains in öffentlichen Zonen zu nutzen:
1. In Ihrer Organisation entstehen Dienste, die in den öffentlichen Raum eintreten: VPN, Dateiaustausch (Seafile, Nextcloud) und andere. Die Einrichtung der Verschlüsselung für solche Dienste sieht häufig chaotisch aus, und sich vor MitM-Angriffen zu schützen, ist kompliziert (was in Wirklichkeit nicht der Fall ist).
Oder innerhalb des Büros haben Sie eine Adresse für den Dienst, während das Internet eine andere verwendet, und diese Verbindungen müssen aufrechterhalten werden, was unsere begrenzten Ressourcen der Fachleute beansprucht. Zudem müssen die Mitarbeiter sich verschiedene Adressen merken, was unpraktisch ist.
2. Sie können kostenlose Zertifizierungsstellen verwenden, um Ihre internen Dienste zu verschlüsseln.
Ein eigenes PKI ist ein Dienst, der Wartung erfordert; 100 Euro pro Jahr für die Nutzung von PKI durch kostenlose Zertifizierungsstellen rechtfertigen die Zeit, die Mitarbeiter für andere Aufgaben aufwenden könnten.
3. Wenn Sie ein eigenes Zertifizierungszentrum verwenden, behindern Sie Ihre entfernten Mitarbeiter und Kollegen, die im Rahmen von BYOD (Bring Your Own Device — bringen ihre Laptops, Telefone, Tablets mit) arbeiten möchten, und Sie können deren Geräte nicht verwalten. Sie bringen Macs, Linux, Androids, iOS, Windows mit — es macht keinen Sinn, einen solchen Zoo zu unterstützen.
Es gibt natürlich Ausnahmen, und Banken sowie andere strenge Unternehmen mit etablierten Sicherheitsrichtlinien werden den Service für ihre Mitarbeiter nie verbessern können.
Für sie gibt es kostenpflichtige Zertifizierungsstellen, die gegen eine bestimmte Gebühr ihr CA-Zertifikat signieren können (googeln Sie "root signing service").
Es gibt auch andere Gründe, warum die Verwendung einer öffentlichen Domain vorteilhafter ist (das Wichtigste ist, dass sie Ihnen gehört), aber darum geht es in diesem Artikel nicht.
Die Essenz ist, ...
Achtung! Wenn Sie das CA-Zertifikat von Let’s Encrypt zur Liste der vertrauenswürdigen für oVirt hinzufügen, kann das die Sicherheit Ihrer Systeme beeinträchtigen!
Das erste, worauf man achten sollte, ist, dass die Schnittstellen von ovirt ins Internet zu veröffentlichen eine schlechte Praxis ist, da dies keinen praktischen Nutzen hat und zusätzliche Sicherheitsrisiken schafft.
Daher muss das Zertifikat auf einem unserer Bastion-Hosts erhalten werden, bevor das Zertifikat und der Schlüssel auf unseren Host mit ovirt-engine übertragen werden.
Wir fügen die externe Adresse unseres Bastion-Hosts im DNS mit unserem ovirt-Namen hinzu. ovirtengine.example.com, die Installation von certbot und nginx überlasse ich der Fantasie (wie das geht, wurde bereits auf Habr beschrieben).
Wir konfigurieren nginx Version >=1.15.7
/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;
# Erlauben Sie dem Server, OCSP-Antworten anzuhängen, um die Ladezeiten für Benutzer zu reduzieren
ssl_stapling on;
ssl_stapling_verify on;
add_header Strict-Transport-Security max-age=15768000;
location / {
return 444;
}
}
Dann erhalten wir unser Zertifikat und unseren Schlüssel:
certbot certonly --nginx -d ovirtengine.example.com
Wir archivieren unser Zertifikat und den Schlüssel:
tar Phczf /tmp/ovirtengine.example.com.tgz /etc/letsencrypt/live/ovirtengine.example.com
Wir laden das Archiv vom Bastion-Host herunter und übertragen es auf unseren Ovirt-Engine:
scp bastion-host:/tmp/ovirtengine.example.com.tgz /tmp/
scp /tmp/ovirtengine.example.com.tgz ovirtengine.example.com:/
Wir gehen zum Ziel
Als nächstes entpacken wir unser Archiv und erstellen Symlinks zur besseren Verständlichkeit des Dateispeichersystems:
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 die integrierte PKI in Ovirt, sodass ein Java-Zertifikatspeicher (openjdk) zur Zertifikatüberprüfung verwendet wird:
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
Wir konvertieren das CA-Zertifikat von Let’s Encrypt in das DER-Format und fügen es dem Java Trust Store der Ovirt-Engine hinzu (dies ist ein Container, der eine Liste von Zertifikaten enthält und in Java verwendet wird):
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 eine Option zur Unterstützung von Symlinks hinzu und entfernen die Option für das CA, das zur Überprüfung der Zertifikate verwendet wird (standardmäßig wird das systemeigene Set vertrauenswürdiger CAs 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
Anschließend sichern wir vorsichtshalber die Originaldateien, die automatisch über PKI von ovirt generiert wurden, und ersetzen die Symlinks durch die 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 die SElinux-Kontexte für die Dateien wieder her und starten unsere Dienste (httpd, ovirt-engine, ovirt-imageio-proxy, ovirt-websocket-proxy) neu:
restorecon -Rv /etc/pki
systemctl restart httpd ovirt-engine ovirt-imageio-proxy ovirt-websocket-proxy
httpd — Webserver mieten kann. apache
ovirt-engine — Weboberfläche von ovirt
ovirt-imageio-proxy — Daemon zum Hochladen von Disk-Images
ovirt-websocket-proxy — Dienst für die Nutzung der noVNC-Konsole
Alles, was oben aufgeführt ist, wurde auf der Version von oVirt 4.2 überprüft.
Automatische Aktualisierung von Zertifikaten auf oVirt
Laut bewährten Sicherheitspraktiken sollte keine Verbindung zwischen dem Bastion-Host und oVirt bestehen, und das Zertifikat wird nur für 3 Monate ausgestellt. Hier entsteht ein strittiger Punkt darüber, wie die Aktualisierung der Zertifikate bei mir implementiert ist.
Ich habe ein Ansible-Playbook, das täglich um 5 Uhr morgens nach Plan auf Foreman ausgeführt wird. Dieses Playbook greift auf oVirt zu, überprüft das Ablaufdatum des Zertifikats und wenn weniger als 5 Tage bis zum Ablauf verbleiben, geht es zum Bastion-Host und startet die Aktualisierung des Zertifikats.
Nach der Aktualisierung des Zertifikats archiviert es den Ordner mit den Dateien, lädt sie auf den Foreman-Host hoch und entpackt sie auf dem oVirt-Host. Danach werden die SElinux-Kontexte für die Dateien wiederhergestellt und unsere Dienste neu gestartet.
Quelle: habr.com
