Korak po korak, pri izboljševanju infrastrukture, sem se odločil rešiti staro in mučno vprašanje — brez dodatnih korakov omogočiti kolegom (razvijalcem, testerjem, skrbnikom itd.) samostojno upravljanje njihovih virtualnih okolij v ovirt-u. V ovirt-u je več komponent, ki jih je treba nastaviti za rešitev mojega vprašanja: sama spletna aplikacija, noVNC konzola in nalaganje slik diskov.
Gumbov »Uredi za odlično« nisem našel, zato prikazujem, katere ročne nastavitve sem izvedel, da rešim to nalogo. Polna navodila so pod ta povezavo:
ODPOVED:
Pred začetkom bi želel opozoriti, da se iz nekega neznanega razloga domene infrastrukture ustvarjajo v zasebnih conah lan, local itd.
Kaj mi preprečuje, da bi uporabil domeno podjetja v javni coni, mi ni znano. Na primer, namesto domene Alex-GLuck-Awesome-Company.local, lahko brez težav uporabite domeno za spletno mesto podjetja Alex-GLuck-Awesome-Company.com.
Če se bojite, da ne boste mogli obvladovati domen v svoji organizaciji in da bo to karkoli pokvarilo, lahko za skromnih 100 rubljev na leto pridobite ločeno domeno za infrastrukturo aglac.com.
Zakaj je bolj smiselno uporabljati domene v javnih conah:
1. V vaši organizaciji se pojavljajo storitve, ki gredo na javni prostor: vpn, izmenjava datotek (seafile, nextcloud) in druge. Nastavljanje šifriranja prometa na takih storitvah običajno izgleda kot nepremišljeno, in zaščita pred MitM ne bo izvedena, ker je to zapleteno (v resnici ni).
Ali imate znotraj pisarne en naslov storitve, iz interneta pa drugega, in te povezave je treba vzdrževati, kar porablja naše omejene vire strokovnjakov. Zaposleni si morajo zapomniti različne naslove, kar je neprijetno.
2. Uporabite lahko brezplačna certifikacijska središča za šifriranje vaših notranjih storitev.
Lastni PKI — to je storitev, ki jo je treba vzdrževati, 100 rubljev na leto za možnost uporabe PKI iz brezplačnih certifikacijskih centrov se več kot povrne v času zaposlenih, ki bi ga sicer porabili za druge naloge.
3. Pri uporabi lastnega certifikacijskega centra boste naleteli na težave za vaše oddaljene zaposlene in kolege, ki želijo delati z BYOD (prinesejo svoje prenosnike, telefone, tablice) in ne morete upravljati njihovih naprav. Prinašajo Mac-e, Linuxe, Androida, iOS, Windows — podpirati takšne naprave nima smisla.
Seveda obstajajo izjeme, in banke z drugimi strogimi podjetji, ki imajo uveljavlene politike varnosti, nikoli ne bodo mogle izboljšati storitev za svoje zaposlene.
Zanje obstajajo plačljivi certifikacijski centri, ki za določen znesek lahko podpisujejo njihove CA certifikate (googlajte 'root signing service').
Obstajajo tudi drugi razlogi, zakaj je uporaba javnega domena bolj smiselna (najpomembneje je, da pripada vam), vendar ta članek ni o tem.
Bistvo je ...
POZOR! Če dodate CA certifikat od Let’s Encrypt na seznam zaupanja za ovirt, to lahko vpliva na varnost vaših sistemov!
Prvo na kar morate biti pozorni — izpostavljanje ovirt v internet je slaba praksa, saj v tem ni praktičnega smisla, dodatno pa ustvarja varnostne grožnje.
Zato je treba pridobiti certifikat na našem bastion gostitelju, nato pa prenesti certifikat in ključe na naš gostitelj z ovirt-engine.
Dodamo zunanji naslov našega bastion gostitelja v DNS z imenom našega ovirt-a. ovirtengine.example.com, namestitev certbota in nginx-a bom pustil izven kadra (kako to narediti je že opisano na habru).
Nastavimo nginx različice >=1.15.7
/etc/nginx/conf.d/default.conf
сервер {
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_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;
}
}
Затем получаем наш сертификат и ключ:
certbot certonly --nginx -d ovirtengine.example.com
Архивируем наш сертификат и ключ:
tar Phczf /tmp/ovirtengine.example.com.tgz /etc/letsencrypt/live/ovirtengine.example.com
Скачиваем архив с бастион-хоста и загружаем на наш ovirt-engine:
scp bastion-host:/tmp/ovirtengine.example.com.tgz /tmp/
scp /tmp/ovirtengine.example.com.tgz ovirtengine.example.com:/
Переходим к цели
Теперь распакуем наш архив и создадим симлинки для упрощения восприятия структуры файлов:
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
Настраиваем встроенный PKI в ovirt, чтобы для проверки сертификатов использовалось хранилище сертификатов Java (OpenJDK):
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
Конвертируем CA от Let's Encrypt в формат DER и добавляем в хранилище сертификатов Java trust store ovirt (это контейнер, в котором хранится список сертификатов, используемый в 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
Urejamo nastavitve SSL za apache, dodajamo parameter za podporo simlinkom in odstranjujemo parameter za CA, s katerim preverjamo certifikate (privzeto se uporablja sistemski nabor zaupanja vrednih CA za preverjanje):
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
Nato za vsak slučaj varnostno kopiramo izvirne datoteke, ki so jih avtomatsko ustvarili PKI ovirt’a, in zamenjamo simlinke z datotekami od 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
Obnovimo SElinux kontekst na datotekah in ponovno zaženemo naše storitve (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 strežnik apache
ovirt-engine — spletni vmesnik ovirt
ovirt-imageio-proxy — demon za nalaganje slik diskov
ovirt-websocket-proxy — storitev za delovanje noVNC konzole
Vse zgoraj navedeno je bilo preverjeno na različici ovirta 4.2.
Samodejno obnavljanje certifikatov na ovirt
Po dobrih praksah glede varnosti ne bi smelo biti povezave med bastion hostom in ovirtom, certifikat pa se izda le za 3 mesece. Tukaj nastane sporno vprašanje, kako je pri meni implementirano obnavljanje certifikatov.
Imam ansible playbook, ki se vsak dan ob 5. uri zjutraj po urniku zažene na foremanu. Ta playbook se poveže na ovirt, preveri trajanje certifikata in če je do poteka ostalo manj kot 5 dni, gre na bastion host in izvede obnavljanje certifikata.
Po obnavljanju certifikata arhivira mapo z datotekami, jo prenese na host formana in razpakira na hostu ovirt. Nato obnovi SElinux kontekste na datotekah in ponovno zažene naše storitve.
Izvor: habr.com
