Az infrastruktúra fejlesztésének útját járva úgy döntöttem, befejezek egy ősi és fájdalmas kérdést - felesleges gesztusok nélkül lehetőséget adok a kollégáknak (fejlesztők, tesztelők, adminisztrátorok stb.) önállóan kezelni virtuális gépeiket az ovitban. Az Ovirtnak számos összetevője van, amelyeket be kell állítani a probléma megoldásához: maga a webes felület, a noVNC konzol és a lemezképek feltöltése.
Nem találtam a „Make It Bad” gombot, ezért megmutatom, mely gombokat forgattam a probléma megoldásához. Teljes utasítás a vágás alatt:
NYILATKOZAT:
Mielőtt elkezdené, szeretném felhívni a figyelmet arra, hogy számomra ismeretlen okból az infrastruktúra tartományok privát zónákban jönnek létre lan, lokális stb.
Nem tudom, mi akadályoz meg abban, hogy egy szervezet domainjét nyilvános zónában használjam. Például az Alex-GLuck-Awesome-Company.local domain helyett nyugodtan használhatja az Alex-GLuck-Awesome-Company.com vállalati webhely domainjét.
Ha attól tart, hogy nem tudja nyomon követni a szervezetében lévő domaineket, és ez eltörik valamit, akkor szerény évi 100 rubelért vásárolhat külön domaint az aglac.com infrastruktúrához.
Miért jövedelmezőbb a tartományok használata nyilvános zónákban:
1. A szervezete nyilvánosan elérhető szolgáltatásokkal rendelkezik: VPN, fájlmegosztás (seafile, nextcloud) és mások. Az ilyen szolgáltatások forgalmi titkosításának beállítása általában kissé kapkodós feladat, és nem fogunk védekezni a MitM támadások ellen, mert nehéz (nem igazán).
Vagy van egy szolgáltatási címe az irodán belül, egy másik pedig az interneten, és ezeket a kapcsolatokat fenn kell tartani, ami a korlátozott szakértői erőforrásainkat pazarolja. Nos, az alkalmazottaknak emlékezniük kell a különböző címekre, ami kényelmetlen.
2. Ingyenes hitelesítő hatóságokat használhat belső szolgáltatásai titkosításához.
A saját PKI egy olyan szolgáltatás, amelyet támogatni kell; évi 100 rubel az ingyenes hitelesítő hatóságok PKI használatának lehetőségéért, mint amennyit más feladatokra fordíthatnának az alkalmazottak idejéért.
3. A saját tanúsító hatóságának használatakor a BYOD-dal dolgozni kívánó (saját laptopot, telefont, táblagépet hozni) távoli alkalmazottai és kollégái kerekeibe küllőt helyez, és nem tudja kezelni az eszközeiket. Macet, Linuxot, Androidot, iOS-t, Windows-t hoznak – semmi értelme egy ilyen állatkertet támogatni.
Természetesen mindenben vannak kivételek, és a bankok más szigorú vállalatokkal, amelyek biztonsági politikát alakítottak ki, soha nem lesznek képesek javítani alkalmazottaik szolgáltatását.
Számukra fizetős hitelesítési hatóságok állnak rendelkezésre, amelyek egy bizonyos összegért aláírhatják a CA-tanúsítványukat (Google „root signing service”).
Vannak más okok is, amelyek miatt kifizetődőbb a közkincs használata (a legfontosabb, hogy az Öné), de ez a cikk nem erről szól.
A lényeg az...
FIGYELEM! Ha egy Let's Encrypt CA tanúsítványt ad hozzá az ovirt megbízható listájához, az hatással lehet rendszerei biztonságára!
Az első dolog, amire figyelni kell, hogy az Ovirt felületek internetezése rossz gyakorlat, mert Ennek nincs gyakorlati értelme, és további biztonsági fenyegetéseket okoz.
Ezért az egyik bástyagazdánkon kell tanúsítványt szereznie, majd ovirt-motorral át kell adnia a tanúsítványt és a kulcsot a gazdánknak.
Az ovirt nevünkkel adjuk hozzá a dns-hez a bástyás gazdánk külső címét ovirtengine.example.com, a certbot és az nginx telepítését a színfalak mögé hagyom (hogyan kell ezt már a Habrén leírni).
Az njinx verzió beállítása >=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;
}
}
Ezután megkapjuk a tanúsítványunkat és a kulcsot:
certbot certonly --nginx -d ovirtengine.example.com
Archiválja tanúsítványunkat és kulcsunkat:
tar Phczf /tmp/ovirtengine.example.com.tgz /etc/letsencrypt/live/ovirtengine.example.com
Töltse le az archívumot a bástya gazdagépről és töltse fel az ovirt motorunkba:
scp bastion-host:/tmp/ovirtengine.example.com.tgz /tmp/
scp /tmp/ovirtengine.example.com.tgz ovirtengine.example.com:/
Menjünk tovább a cél felé
Ezután kicsomagoljuk archívumunkat, és szimbolikus hivatkozásokat hozunk létre, hogy egyszerűsítsük a fájlhelymeghatározási rendszer megértését:
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
A beépített pki-t az Ovirtban úgy konfiguráljuk, hogy a java tanúsítványtárolót (openjdk) használja a tanúsítványok ellenőrzésére:
cat << EOF > /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 CA-t a let's encrypt-ből der formátumba konvertáljuk, és hozzáadjuk az ovirt java megbízhatósági tároló tanúsítványtárhoz (ez egy tároló, amely egy tanúsítványlistát tartalmaz, ilyen rendszert használnak a 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
Szerkesztjük az apache SSL-beállításait, hozzáadunk egy paramétert a szimbolikus hivatkozások támogatásához, és eltávolítjuk a CA paraméterét, amellyel ellenőrizni tudjuk a tanúsítványokat (alapértelmezés szerint a megbízható CA-k rendszerkészletét használják 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 minden esetre biztonsági másolatot készítünk az ovirt automatikus PKI-jén keresztül generált eredeti fájlokról, és lecseréljük azokat szimbolikus hivatkozásokra 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 a SElinux kontextusokat a fájlokon, és újraindítjuk 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 — webszerver apache
ovirt-engine - ovirt webes felület
ovirt-imageio-proxy - démon lemezképek letöltéséhez
ovirt-websocket-proxy – szolgáltatás a noVNC konzol futtatásához
A fentiek mindegyikét az Ovirt 4.2-es verzióján teszteltük.
Tanúsítványok automatikus megújítása az ovirt
A jó biztonsági gyakorlat szerint a bástyagazda és az ovirt között ne legyen kapcsolat, a tanúsítványt csak 3 hónapra adják ki. Itt vetődik fel egy vitatott kérdés, hogy hogyan valósítottam meg a tanúsítványok megújítását.
Van egy ötletes könyvem, ami minden nap reggel 5-kor fut a foremannél, ütemezés szerint. Ez a játékkönyv az ovirtba kerül, ellenőrzi a tanúsítvány érvényességi idejét, és ha kevesebb, mint 5 nap van hátra a lejáratig, akkor a bástyagazdahoz kerül és megkezdi 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 Forman gazdagépre és kibontja az Ovirt gazdagépre. Ezt követően a SElinux visszaállítja a fájlok kontextusait, és újraindítja szolgáltatásainkat.
Forrás: will.com
