Hvordan kombinere Ovirt og Let's Encrypt

Når jeg gikk veien mot å forbedre infrastrukturen, bestemte jeg meg for å løse et gammelt og plagsomt problem – uten unødvendige bevegelser gi kollegene (utviklere, testere, administratorer, etc.) muligheten til å administrere sine virtuelle maskiner selv i ovirt. I ovirt er det flere komponenter som må konfigureres for å løse mitt problem: selve webgrensesnittet, noVNC-konsollen og opplasting av diskbilder.

Jeg fant ikke knappen "Gjør det fett", så jeg viser hvilke håndtak jeg snurte for å løse oppgaven. Full instruksjon under kat:

FRASKRIVELSE:

Før jeg begynner, vil jeg påpeke at, av en eller annen ukjent grunn, opprettes domenene i infrastrukturen i private soner som lan, local, osv.

Hva som hindrer bruk av organisasjonens domene i offentlig sone er meg ukjent. For eksempel, i stedet for domenet Alex-GLuck-Awesome-Company.local, kan du trygt bruke domenet for selskapets nettside Alex-GLuck-Awesome-Company.com.

Hvis du er redd for at du ikke vil kunne holde styr på domenene i organisasjonen din, og at dette kan ødelegge noe, kan du for den beskjedne summen av 100 rubler per år få et eget domene for infrastrukturen aglac.com.

Hvorfor det er mer fordelaktig å bruke domener i offentlige soner:

1. Du får tjenester inne i organisasjonen som går ut i det offentlige rom: vpn, filutveksling (seafile, nextcloud) og andre. Å konfigurere trafikk-kryptering på slike tjenester ser vanligvis ut som halvhjertet arbeid, og vi vil ikke beskytte oss mot MitM, fordi det er vanskelig (egentlig ikke).

Eller har du én adresse for tjenesten på kontoret, og en annen fra internett, og disse må opprettholdes, noe som koster våre begrensede spesialistressurser. Og ansatte må huske forskjellige adresser, noe som er upassende.

2. Du kan bruke gratis sertifiseringssentre for å kryptere dine interne tjenester.

Egen PKI — det er en tjeneste som må vedlikeholdes, 100 rubler per år for muligheten til å bruke PKI fra gratis sertifiseringssentre vil mer enn dekke tiden til ansatte som kunne ha brukt den på andre oppgaver.

3. Når du bruker din egen sertifiseringssentral, vil du sette kjepper i hjulene for dine remote ansatte og kollegaer som ønsker å jobbe med BYOD (Bring Your Own Device), og du kan ikke administrere enhetene deres. De bringer Mac-er, Linux, Android, iOS, Windows – å støtte et slikt dyrepark er ikke meningsfullt.

Det finnes selvsagt unntak, og banker med andre strenge foretak som har etablerte sikkerhetspolicyer, vil aldri være i stand til å forbedre servicen for sine ansatte.

For dem finnes det betalte sertifiseringssentraler som for en viss sum kan signere deres CA-sertifikat (google "root signing service").

Det finnes også andre grunner til at det er mer fordelaktig å bruke et offentlig domene (det viktigste er at det tilhører deg), men artikkelen handler ikke om det.

Essensen er...

MERK! Hvis du legger til et CA-sertifikat fra Let’s Encrypt i listen over betrodde sertifikater for ovirt, kan dette påvirke sikkerheten til systemene dine!

Det første du må merke deg er at det er dårlig praksis å eksponere ovirt-grensesnittene på internett, da det ikke har noe praktisk formål og skaper ytterligere sikkerhetstrusler.

Derfor må du få sertifikatet på en av våre bastion-hostene, før du flytter sertifikatet og nøkkelen til vår vert med ovirt-engine.

Legg til den eksterne adressen til vår bastion-host i DNS med navnet vårt for ovirt. ovirtengine.example.com, installasjonen av certbot og nginx vil jeg la være i bakgrunnen (hvordan man gjør dette er allerede beskrevet på Habr).

Vi konfigurerer nginx versjon >=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;

    # allow the server to attach OCSP responses, thereby reducing page load times for users
    ssl_stapling on;
    ssl_stapling_verify on;
    add_header Strict-Transport-Security max-age=15768000;

    location / {
        return 444;
    }
}

Then we obtain our certificate and key:

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

We archive our certificate and key:

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

We download the archive from the bastion host and upload it to our oVirt engine:

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

We move to the target

Next, we unpack our archive and create symlinks to simplify understanding of the file system layout:

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

We configure the built-in PKI in oVirt to use the Java certificate storage (openjdk) for certificate validation:

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

We convert the CA from Let's Encrypt to DER format and add it to the oVirt Java trust store (a container that contains a list of certificates, such a system is used in 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

Redigerer SSL-innstillinger for Apache, legger til parameter for støtte av symboliske lenker og fjerner parameter for CA som brukes til å verifisere sertifikater (standard vil bruke systemets sett med pålitelige CA-er for verifisering):

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

Deretter tar vi sikkerhetskopi av de originale filene, generert via PKI ovirt automatisk, og bytter ut med symboliske lenker til filer fra 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 gjenoppretter SElinux-kontekster på filene og starter våre tjenester på nytt (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 — webgrensesnitt for ovirt
ovirt-imageio-proxy — daemon for opplasting av diskbilder
ovirt-websocket-proxy — tjeneste for å bruke noVNC-konsollen

Alt ovenfor er testet på ovirt versjon 4.2.

Automatisk oppdatering av sertifikater på ovirt

I henhold til gode sikkerhetspraksiser skal det ikke være forbindelse mellom bastion-host og ovirt, og sertifikatet utstedes kun for 3 måneder. Her oppstår det et omdiskutert punkt om hvordan sertifikatoppdateringen er implementert.

Jeg har en Ansible playbook som kjøres på Foreman daglig kl. 05.00 etter timeplan. Denne playbooken logger inn på ovirt, sjekker utløpsdatoen for sertifikatet, og hvis det er mindre enn 5 dager igjen, går den til bastion-host og utfører sertifikatoppdateringen.

Etter oppdatering av sertifikatet arkiverer den mappen med filer, laster dem ned til Foreman-host og pakker dem ut på ovirt-host. Deretter gjenoppretter den SElinux-kontekster på filene og starter våre tjenester på nytt.

Kilde: habr.com