Az infrastruktúra fejlesztése érdekében elhatároztam, hogy végleg megoldom egy régi és fájdalmas kérdést – felesleges manőverek nélkül lehetőséget biztosítsak a kollégáimnak (fejlesztőknek, tesztelőknek, rendszergazdáknak stb.), hogy önállóan kezelhessék virtuális gépeiket az Ovirtben. Az Ovirtben több komponenst is be kell állítani a kérdésem megoldásához: maga a webes felület, a noVNC konzol és a lemezképek feltöltése.
A «Tedd szuper» gombokat nem találtam, ezért bemutatom, hogy milyen módokat használtam a feladat megoldására. Teljes útmutató lentebb:
FIGYELMEZTETÉS:
A kezdés előtt szeretném felhívni a figyelmet arra, hogy valami ismeretlen okból az infrastruktúra domainjei privát zónákban, mint a lan, local stb. kerülnek létrehozásra.
Nem tudom, mi akadályozza meg, hogy egy szervezet domainjét nyilvános zónában használjuk. Például a domain helyett, mint az Alex-GLuck-Awesome-Company.local, nyugodtan használhatjuk a cég weboldalának domainjét: Alex-GLuck-Awesome-Company.com.
Ha attól fél, hogy nem tudja nyomon követni a domainjeit a szervezetében, és ez valamit tönkretesz, akkor évi 100 rubelért külön domain lehetőséget vásárolhat az infrastruktúrához: aglac.com.
Miért éri meg nyilvános zónákban használni a domaineket:
1. A szervezet belsejében olyan szolgáltatások jelennek meg, amelyek nyilvános térbe lépnek: vpn, fájlmegosztás (seafile, nextcloud) és mások. Az ilyen szolgáltatások forgalmának titkosítása általában hanyagul történik, és az MitM ellen védekezni nehéz, pedig valójában nem az.
Vagy az irodán belül egy szolgáltatás címe van, míg az internetről egy másik, és ezt a kapcsolatot fenntartani szükséges, amire szakembereink korlátozott erőforrásait költjük. A munkavállalóknak emlékezniük kell a különböző címekre, ami kényelmetlen.
2. Ingyenes tanúsítványkiadó központokat használhat a belső szolgáltatások titkosításához.
A saját PKI egy olyan szolgáltatás, amelyet fenntartani kell, míg az ingyenes tanúsítványkiadóktól való használati lehetőség 100 rubelért bőven megtéríti azokat az időt, amelyet a munkatársak más feladatokra költhetnének.
3. Ha saját tanúsítványközpontot használ, akkor gátat vet a távoli munkatársainak és kollégáinak, akik BYOD-ot (hozzák a saját laptopjukat, telefonjukat, táblagépüket) szeretnének használni, és nem tudja kezelni az eszközeiket. Ők Mac-eket, Linuxokat, Androidokat, iOS-t és Windows-t hoznak — ennyi különféle eszköz támogatására nincs értelme.
Mindennek természetesen vannak kivételei, és a bankok, valamint más szigorú vállalatok, amelyeknek megszilárdult biztonsági politikájuk van, soha nem tudják majd javítani szolgáltatásaikat a munkatársaik számára.
Számukra léteznek díjköteles tanúsítványközpontok, amelyek egy meghatározott összeg ellenében aláírhatják a CA tanúsítványukat (keresse meg a "root signing service" kifejezést).
Vannak más okok is, amiért a nyilvános domain használata előnyösebb (a legfontosabb, hogy a tiéd legyen), de ez a cikk nem erről szól.
A lényeg, hogy…
FIGYELEM! Ha hozzáadja a Let’s Encrypt CA tanúsítványát az ovirt megbízható listájához, az befolyásolhatja rendszereinek biztonságát!
Először is érdemes megjegyezni, hogy az ovirt interfészeit az internetre kitenni rossz gyakorlat, mivel ennek semmilyen gyakorlati hozamai nincsenek, és további biztonsági fenyegetéseket jelent.
Tehát a tanúsítványt egy bástyahoston kell beszerezni, majd a tanúsítványt és a kulcsot átkonvertálni az ovirt-engine-nal rendelkező hostunkra.
Hozzáadjuk a bástyahostunk külső címét a DNS-hez az ovirt nevünkkel. ovirtengine.example.com, a certbot és az nginx telepítése a háttérbe kerül (hogyan kell ezt megtenni, arról már írtak a habrán).
Beállítjuk az nginx verzióját >=1.15.7
/etc/nginx/conf.d/default.conf
szerver {
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;
}
}
szerver {
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;
# lehetővé tesszük a szerver számára, hogy csatolja az OCSP válaszokat, ezzel csökkentve az oldalak betöltési idejét a felhasználók számára
ssl_stapling on;
ssl_stapling_verify on;
add_header Strict-Transport-Security max-age=15768000;
location / {
return 444;
}
}
Ezután megszerezzük a tanúsítványunkat és a kulcsot:
certbot certonly --nginx -d ovirtengine.example.com
Archiváljuk a tanúsítványunkat és a kulcsot:
tar Phczf /tmp/ovirtengine.example.com.tgz /etc/letsencrypt/live/ovirtengine.example.com
Letöltjük a bastion hoszt archívumát, feltöltjük az ovirt engine-re:
scp bastion-host:/tmp/ovirtengine.example.com.tgz /tmp/
scp /tmp/ovirtengine.example.com.tgz ovirtengine.example.com:/
Áttérünk a célra
Ezután kicsomagoljuk az archívumot és szimbolikus linkeket hozunk létre a fájlok elhelyezkedésének megértésének megkönnyítése érdekében:
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
Beállítjuk az integrált PKI-t az ovirtben, hogy a tanúsítványok ellenőrzéséhez a java (openjdk) tanúsítványtárat használja:
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
A let’s encrypt által kibocsátott CA-t der formátumba konvertáljuk és hozzáadjuk az ovirt java trust store tanúsítványtárához (ez egy olyan tároló, amely a tanúsítványok listáját tartalmazza, ezt a rendszert a java használja):
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
Az SSL beállításait szerkesztjük az apache-ban, hozzáadunk egy paramétert a szimlinkek támogatásához, és eltávolítjuk a CA paramétert, amellyel a tanúsítványokat ellenőrizni kell (alapértelmezés szerint a rendszer megbízható CA-k készletét fogja használni az ellenőrzéshez):
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
Ezután biztonsági másolatot készítünk az eredeti fájlokról, amelyeket az ovirt PKI generált automatikusan, és szimlinkeket helyettesítünk a Let's Encrypt fájljaival:
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
Visszaállítjuk az SElinux kontextusokat a fájlokon, és újraindítjuk a szolgáltatásainkat (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 szerver apache
ovirt-engine — az ovirt webes felülete
ovirt-imageio-proxy — a lemezképek betöltésére szolgáló démon
ovirt-websocket-proxy — a noVNC konzol működéséhez szükséges szolgáltatás
Mindaz, amit felsoroltunk, az ovirt 4.2-es verzióján lett tesztelve.
Automatikus tanúsítványfrissítés ovirt-hez
A biztonsági jó gyakorlatok szerint a bastion host és az ovirt között nem lenne szabad kapcsolatnak lennie, és a tanúsítványt csak 3 hónapra adják ki. Itt merül fel a vitás pont a tanúsítványok frissítésének módjáról.
Van egy ansible playbookom, ami napi rendszerességgel, reggel 5 órakor fut a foreman-en. Ez a playbook belép az ovirt-be, ellenőrzi a tanúsítvány lejárati idejét, és ha az 5 napon belül lejár, bemegy a bastion host-ra és elindítja a tanúsítvány frissítését.
A tanúsítvány frissítése után archiválja a fájlokat tartalmazó mappát, letölti a formán a hosztra, és kicsomagolja az ovirt hosztra. Ezt követően visszaállítja az SElinux kontextusokat a fájlokon, és újraindítja a szolgáltatásainkat.
Forrás: habr.com
