ProHoster > Blog > Administration > Hvordan man forbinder Ovirt og Let's Encrypt

Hvordan man forbinder Ovirt og Let's Encrypt

I am taking steps to improve the infrastructure, and I decided to tackle the long-standing and painful issue — to provide my colleagues (developers, testers, admins, etc.) with the ability to manage their virtual machines in ovirt without unnecessary movements. In ovirt, there are several components that need to be configured to address my issue: the web interface itself, the noVNC console, and the uploading of disk images.

I did not find the 'Make Awesome' buttons, so I will show what knobs I turned to solve this task. The complete guide is below:

SĂ„dan forbinder du Ovirt og Let's Encrypt

DISCLAIMER:

Before I begin, I would like to draw attention to the fact that for some unknown reason, the infrastructure domains are created in private zones like lan, local, and so on.

What prevents the use of the organization’s domain in the public zone is unknown to me. For example, instead of the domain Alex-GLuck-Awesome-Company.local, you can safely use the domain for the company’s website Alex-GLuck-Awesome-Company.com.

If you are worried that you cannot keep track of the domains in your organization and that this might break something, you can for a modest 100 rubles a year get a separate domain for the infrastructure aglac.com.

Why is it better to use domains in public zones:

1. You have internal services that go out into the public space: VPN, file sharing (seafile, nextcloud), and others. Setting up traffic encryption on such services usually looks haphazard, and we won’t be protected against MitM attacks because it is difficult (but actually it isn’t).

Or you have one service address inside the office and another from the internet, and these connections need to be maintained, which wastes our limited specialist resources. Plus, employees have to remember different addresses, which is inconvenient.

2. You can use free certification centers to encrypt your internal services.

Having your own PKI is a service that needs to be maintained. 100 rubles a year for the ability to use PKI from free certification centers pays off well for the time spent by employees who could be using it for other tasks.

3. NĂ„r du bruger dit eget certifikatcenter, vil du sĂŠtte hindringer for dine fjernmedarbejdere og kolleger, der Ăžnsker at arbejde med BYOD (bring your own device - bringer deres egne bĂŠrbare computere, telefoner, tablets), og du kan ikke styre deres enheder. De bruger Mac, Linux, Android, iOS, Windows — det giver ikke mening at understĂžtte sĂ„dan en dyrepark.

Der er selvfĂžlgelig undtagelser, og banker samt andre store virksomheder med etablerede sikkerhedspolitikker vil aldrig kunne forbedre servicen for deres medarbejdere.

Der findes betalte certifikatcentre, som mod et bestemt belÞb kan signere deres CA-certifikat (sÞge efter «root signing service»).

Der er ogsÄ andre grunde til, at det er mere fordelagtigt at bruge et offentligt domÊne (det vigtigste er, at det tilhÞrer dig), men artiklen handler ikke om dette.

Essensen og sagen er...

ADVARSEL! Hvis du tilfĂžjer CA-certifikatet fra Let’s Encrypt til listen over betroede certifikater for ovirt, kan dette pĂ„virke sikkerheden for dine systemer!

Det fÞrste, du skal vÊre opmÊrksom pÄ, er, at det er en dÄrlig praksis at eksponere ovirt-grÊnsefladerne til internettet, da der ikke er nogen praktisk mening i dette, og det skaber yderligere sikkerhedstrusler.

Derfor skal certifikatet fÄs pÄ en af vores bastion-vÊrter, hvorefter certifikatet og nÞglen flyttes til vores vÊrt med ovirt-engine.

Vi tilfÞjer den eksterne adresse til vores bastion-vÊrt i DNS med vores ovirt-navn. ovirtengine.example.com, installationen af certbot og nginx lader jeg stÄ uden for rammerne (hvordan det gÞres er allerede beskrevet pÄ Habr).

Vi konfigurerer 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;

    #ć…èźžæœćŠĄć™šé™„ćŠ OCSP操ćș”ïŒŒä»„æ­€ć‡ć°ç”šæˆ·çœ‘éĄ”ćŠ èœœæ—¶é—Ž
    ssl_stapling on;
    ssl_stapling_verify on;
    add_header Strict-Transport-Security max-age=15768000;

    location / {
        return 444;
    }
}

Here we get 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 for easier 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 trust store for certificate verification:

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 Let's Encrypt CA to DER format and add it to the Java trust store in oVirt:

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 redigerer SSL-indstillingerne for apache, tilfĂžjer en parameter til at understĂžtte symlinks og fjerner parameteret til CA, der skal bruges til at kontrollere certifikater (som standard vil systemet bruge det systemmĂŠssige sĂŠt af betroede CA'er til kontrollen):

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

Derefter laver vi en sikkerhedskopi af de originale filer, der blev genereret gennem PKI ovirt automatisk, og erstatter symlinks med 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 genskaber SElinux-konteksterne pÄ filerne og genstarter vores tjenester (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 — webgrénsefladen til ovirt
ovirt-imageio-proxy — démonen til at indlése diskbilleder
ovirt-websocket-proxy — tjenesten til at arbejde med noVNC-konsollen

Alt det ovenfor nÊvnte er blevet testet pÄ version 4.2 af ovirt.

Automatisk opdatering af certifikater pÄ ovirt

I henhold til gode sikkerhedspraksisser bÞr der ikke vÊre nogen forbindelse mellem bastion-host og ovirt, og certifikatet udstedes kun i 3 mÄneder. Her opstÄr det kontroversielle spÞrgsmÄl om, hvordan certifikatopdateringen er implementeret hos mig.

Jeg har et ansible-playbook, der kÞrer pÄ foreman dagligt kl. 5 om morgenen efter tidsplanen. Dette playbook logger ind pÄ ovirt, kontrollerer certifikatets udlÞbsdato, og hvis der er mindre end 5 dage tilbage, logger det ind pÄ bastion-host og starter opdateringen af certifikatet.

Efter certifikatopdateringen arkiverer det mappen med filerne, downloader den til foreman-host og udpakkes pÄ ovirt-host. Derefter genskaber det SElinux-konteksterne pÄ filerne og genstarter vores tjenester.

Kilde: habr.com

KĂžb pĂ„lidelig webhosting med DDoS-beskyttelse, VPS VDS-servere đŸ”„ KĂžb pĂ„lidelig webhosting med DDoS-beskyttelse, VPS VDS-servere | ProHoster