Kā salāgot Ovirt un Let’s Encrypt

I decided to tackle the long-standing and painful issue of providing 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 set up to address my issue: the web interface itself, the noVNC console, and the uploading of disk images.

I couldn't find the 'Make Amazing' button, so I'm showing what I've been tinkering with to solve this task. A complete guide is below:

DISCLAIMER:

Before starting, I would like to point out 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 remains unknown to me. For example, instead of the domain Alex-GLuck-Awesome-Company.local, you can confidently use the domain for the company's website Alex-GLuck-Awesome-Company.com.

If you are afraid that you won't be able to keep track of the domains in your organization, and that this might break something, you can get a separate domain for the infrastructure aglac.com for a modest 100 rubles a year.

Why it's better to use domains in public zones:

1. You have services within your organization that go into the public space: VPN, file sharing (Seafile, Nextcloud), and others. Setting up traffic encryption on such services usually looks slapdash, and we won't protect against MitM because it's complicated (actually, it's not).

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

2. You can use free Certificate Authorities to encrypt your internal services.

Having your own PKI is a service that needs support; spending 100 rubles a year for the ability to use PKI from free Certificate Authorities more than pays off the time employees could spend on other tasks.

3. Izmantojot savu sertifikācijas centru, jūs liksiet saviem attālinātajiem darbiniekiem un kolēģiem saskarties ar grūtībām, ja viņi vēlas strādāt ar BYOD (nesa savu portatīvo datoru, telefonu, planšetdatoru), un jūs nevarat pārvaldīt viņu ierīces. Viņi nes savu Mac, Linux, Android, iOS, Windows — atbalstīt šādu zoodārzu nav nekādas jēgas.

Protams, viss ir ar izņēmumiem, un bankas kopā ar citiem stingrajiem uzņēmumiem, kuriem ir izstrādātas drošības politikas, nekad nevarēs uzlabot pakalpojumus saviem darbiniekiem.

Viņiem ir maksas sertifikācijas centri, kuri par noteiktu samaksu var parakstīt viņu CA sertifikātu (meklējiet "root signing service").

Ir arī citas piedāvājuma priekšrocības, kādēļ publiskais domēns ir izdevīgāks (galvenais, lai tas piederētu jums), bet raksts nav par to.

Mēs nonākam pie būtības…

UZMANĪBU! Ja jūs pievienosiet Let’s Encrypt CA sertifikātu uzticamo sarakstam ovirt, tas var ietekmēt jūsu sistēmu drošību!

Pirmais, uz ko jāpievērš uzmanība — ovirt saskarnes izveidošana internetā ir slikta prakse, jo tam nav nekādas praktiskas jēgas, bet ir papildu drošības apdraudējumi.

Tādējādi sertifikātu nepieciešams iegūt uz kāda mūsu bastiona hostinga, pēc tam pārsūtīt sertifikātu un atslēgu uz mūsu hostingu ar ovirt-engine.

Pievienojam mūsu bastiona hosta ārējo adresi DNS ar mūsu ovirt nosaukumu ovirtengine.example.com, certbot un nginx instalēšanu atstāšu aiz kadra (kā to izdarīt jau aprakstīts).

Konfigurējam nginx versijas >=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;

    ssl_stapling on;
    ssl_stapling_verify on;
    add_header Strict-Transport-Security max-age=15768000;

    location / {
        return 444;
    }
}

Pēc tam iegūstam mūsu sertifikātu un atslēgu:

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

Iepakojam mūsu sertifikātu un atslēgu:

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

Lejupielādējam arhīvu no bastiona hosta un augšupielādējam to mūsu ovirt ierīcē:

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

Pārejam pie mērķa

Tālāk izsaiņojam mūsu arhīvu un izveidojam simboliskos saites, lai atvieglotu sistēmas failu struktūras izpratni:

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

Konfigurējam iebūvēto pki ovirt, lai sertifikātu pārbaudei tiktu izmantota Java (openjdk) sertifikātu krātuve:

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

Konvertējam CA no let’s encrypt uz der formātu un pievienojam to ovirt Java trust store sertifikātu krātuvei:

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

Rediģējam SSL iestatījumus apache, pievienojam parametru, lai atbalstītu simboliskos linkus, un noņemam parametru, lai CA pārbaudītu sertifikātus (pēc noklusējuma tiks izmantots sistēmas uzticamo CA kopums pārbaudei):

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

Pēc tam drošības pēc beidzot izveidojam oriģinālo failu dublējumu, ko automātiski ģenerējusi PKI ovirt un aizvietojam to ar simboliskajiem linkiem uz Let’s Encrypt failiem:

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

Atjaunojam SElinux kontekstu failiem un restartējam mūsu pakalpojumus (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 — web serverus apache
ovirt-engine — ovirt tīmekļa interfeiss
ovirt-imageio-proxy — aģents disku attēlu ielādēšanai
ovirt-websocket-proxy — pakalpojums noVNC konsoles darbībai

Viss iepriekš minētais tika pārbaudīts ar ovirt versiju 4.2.

Automātiska sertifikātu atjaunināšana ovirt

Saskaņā ar labajām drošības praksēm savienojuma starp bastion host un ovirt nedrīkst būt, un sertifikāts tiek izsniegts tikai uz 3 mēnešiem. Šeit parādās apšaubāms jautājums par to, kā man ir izveidots sertifikātu atjauninājums.

Man ir Ansible spēļu grāmata, kas tiek izpildīta uz foreman katru dienu plkst. 5 no rīta saskaņā ar grafiku. Šī spēļu grāmata ieiet ovirt, pārbauda sertifikāta derīguma termiņu, un, ja līdz derīguma beigām atlikušas mazāk nekā 5 dienas, dodas uz bastion host un uzsāk sertifikāta atjaunināšanu.

Pēc sertifikāta atjaunināšanas tā arhivē failu mapi, lejupielādē to uz foreman host un izsaiņo to ovirt hostā. Pēc tam atjaunojam SElinux kontekstus failiem un restartējam mūsu pakalpojumus.

Avots: habr.com