Hur man förenar Ovirt och Let's Encrypt

Genom att förbättra infrastrukturen har jag beslutat att ta itu med den gamla och plågsamma frågan — utan onödiga rörelser ge kollegor (utvecklare, testare, administratörer, etc.) möjlighet att själva hantera sina virtuella maskiner i ovirt. I ovirt finns det flera komponenter som måste konfigureras för att lösa mitt problem: själva webbgränssnittet, noVNC-konsolen och uppladdning av diskavbilder.

Jag hittade inga knappar för "Gör det fantastiskt", så jag visar vilka knoppar jag har vridit på för att lösa denna uppgift. Fullständig instruktion nedan:

DISKLAMATION:

Innan jag börjar vill jag påpeka att av någon okänd anledning skapas infrastruktdomäner i privata zoner som lan, local, och så vidare.

Vad som hindrar mig från att använda organisationens domän i den offentliga zonen är okänt. Till exempel, istället för domänen Alex-GLuck-Awesome-Company.local, kan man utan problem använda domänen för företagets webbplats Alex-GLuck-Awesome-Company.com.

Om du är rädd för att du inte kommer att kunna hålla reda på domänerna i din organisation, och att detta kommer att förstöra något, kan du för blygsamma 100 rubel om året skaffa en separat domän för infrastrukturen aglac.com.

Varför det är mer fördelaktigt att använda domäner i offentliga zoner:

1. Inom din organisation får du tjänster som går ut i det offentliga rummet: vpn, fildelning (seafile, nextcloud) och andra. Att konfigurera kryptering av trafiken på sådana tjänster ser vanligtvis slarvigt ut, och att skydda sig mot MitM är svårt (men det är egentligen inte så svårt).

Eller inom kontoret har du en adress för tjänsten, medan den från internet är en annan, och dessa kopplingar måste upprätthållas, vilket kostar våra begränsade resurser av specialister. Dessutom måste anställda komma ihåg olika adresser, vilket är otrevligt.

2. Du kan använda gratis certifieringscentra för att kryptera dina interna tjänster.

Ett eget PKI — är en tjänst som måste stödjas, 100 rubel per år för möjligheten att använda PKI från gratis certifieringscentra betalar sig mer än väl för den tid som anställda kunde ha ägnat åt andra uppgifter.

3. När du använder din egen certifikatutfärdare kommer du att sätta käppar i hjulet för dina distansanställda och kolleger som vill jobba med BYOD (ta med sina egna bärbara datorer, telefoner, surfplattor) och du kan inte hantera deras enheter. De kommer med Mac-datorer, Linux, Android, iOS, Windows — att stödja en sådan djungel är totalt meningslöst.

Självklart finns det undantag, och banker med andra strikta företag som har etablerade säkerhetspolicys kommer aldrig kunna förbättra servicen för sina anställda.

För dem finns det betalade certifikatcenter som för en viss summa kan signera deras CA-certifikat (googla "root signing service").

Det finns också andra anledningar till varför det är mer fördelaktigt att använda en offentlig domän (det viktigaste är att den tillhör dig), men artikeln handlar inte om det.

Essensen, ja själva grejen…

VARNING! Om du lägger till ett CA-certifikat från Let’s Encrypt i listan över betrodda för ovirt, kan detta påverka säkerheten för dina system!

Det första att tänka på — att ställa in ovirt-gränssnitten på internet är dålig praxis eftersom det inte finns något praktiskt syfte och dessutom skapar ytterligare säkerhetshot.

Därför är det nödvändigt att få certifikatet på någon av våra bastionservrar, och sedan överföra certifikatet och nyckeln till vår server med ovirt-engine.

Lägg till den externa adressen för vår bastion-server i DNS med vårt ovirt-namn. ovirtengine.example.com, installation av certbot och nginx lämnar jag utanför (hur man gör detta har redan beskrivits på Habré).

Konfigurera 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;

    # möjliggör för servern att bifoga OCSP-svar, vilket minskar laddningstiden för användare
    ssl_stapling on;
    ssl_stapling_verify on;
    add_header Strict-Transport-Security max-age=15768000;

    location / {
        return 444;
    }
}

Sedan får vi vårt certifikat och nyckel:

certbot certonly --nginx -d ovirtengine.example.com

Vi packar vårt certifikat och nyckel:

tar Phczf /tmp/ovirtengine.example.com.tgz /etc/letsencrypt/live/ovirtengine.example.com

Vi laddar ner arkivet från bastionvärden och laddar upp det till vår oVirt-motor:

scp bastion-host:/tmp/ovirtengine.example.com.tgz /tmp/
scp /tmp/ovirtengine.example.com.tgz ovirtengine.example.com:/

Vi går vidare till målet

Därefter packar vi upp vårt arkiv och skapar symboliska länkar för att förenkla systemförståelsen:

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

Vi konfigurerar den inbyggda PKI i oVirt så att Java (openjdk) certifikatlager används för certifikatverifiering:

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

Vi konverterar CA-certifikatet från Let’s Encrypt till DER-format och lägger till det i Java trust store i oVirt (detta är en behållare som innehåller listan över certifikat, vilket är ett system som används i 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

Vi redigerar SSL-inställningarna för Apache, lägger till en parameter för att stödja symlänkar och tar bort parametern för CA som används för att verifiera certifikat (standardinställningen kommer att använda systemets uppsättning betrodda CA för verifiering):

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

Därefter säkerhetskopierar vi de ursprungliga filer som har genererats via PKI ovirt automatiskt, och byter ut symlänkarna mot filer från 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

Vi återställer SElinux-kontakterna på filerna och startar om våra tjänster (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 — webbserver apache
ovirt-engine — webbgränssnitt för ovirt
ovirt-imageio-proxy — daemon för uppladdning av diskbilder
ovirt-websocket-proxy — tjänst för att arbeta med noVNC-konsolen

Allt ovanstående har verifierats på ovirt version 4.2.

Automatisk uppdatering av certifikat på ovirt

Enligt god säkerhetspraxis bör det inte finnas någon direkt koppling mellan bastion-hosten och ovirt, och certifikatet utfärdas endast för 3 månader. Här uppstår en tvetydig fråga om hur certifikatens uppdateringar har implementerats hos mig.

Jag har en Ansible-playbook som körs på Foreman dagligen klockan 5 på morgonen enligt schema. Denna playbook loggar in på ovirt, kontrollerar certifikatets giltighetstid och om det är mindre än 5 dagar kvar till utgång går den till bastion-hosten och initierar certifikatets uppdatering.

Efter certifikatets uppdatering arkiverar den mappen med filer, laddar ner den till Foreman-värden och packar upp den på ovirt-värden. Därefter återställer den SElinux-kontakterna på filerna och startar om våra tjänster.

Källa: habr.com