Wie man Ovirt und Let’s Encrypt miteinander verbindet

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:

Wie man oVirt und Let's Encrypt miteinander verbindet

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

ZuverlĂ€ssiges Webhosting mit DDoS-Schutz, VPS- und VDS-Server kaufen đŸ”„ ZuverlĂ€ssiges Webhosting mit DDoS-Schutz, VPS- und VDS-Server kaufen | ProHoster