Ko sem hodil po poti izboljšanja infrastrukture, sem se odločil dokončati starodavno in boleče vprašanje - brez nepotrebnih potez omogočite kolegom (razvijalcem, preizkuševalcem, skrbnikom itd.), da samostojno upravljajo svoje virtualne stroje v ovirtu. Ovirt ima več komponent, ki jih je treba konfigurirati za rešitev moje težave: sam spletni vmesnik, konzolo noVNC in nalaganje slik diska.
Nisem našel gumba »Make It Bad«, zato vam pokažem, katere gumbe sem obračal, da bi rešil to težavo. Celotna navodila pod rezom:
OPOZORILO:
Preden začnem, bi vas rad opozoril na dejstvo, da se iz neznanega razloga infrastrukturne domene ustvarjajo v zasebnih conah lan, local itd.
Ne vem, kaj mi preprečuje uporabo domene organizacije v javnem območju. Na primer, namesto domene Alex-GLuck-Awesome-Company.local lahko varno uporabite domeno za spletno stran podjetja Alex-GLuck-Awesome-Company.com.
Če se bojite, da ne boste mogli spremljati domen v vaši organizaciji in bo to nekaj pokvarilo, potem lahko za skromnih 100 rubljev na leto kupite ločeno domeno za infrastrukturo aglac.com.
Zakaj je bolj donosno uporabljati domene v javnih conah:
1. Vaša organizacija ima javno dostopne storitve: VPN, deljenje datotek (seafile, nextcloud) in drugi. Nastavitev šifriranja prometa v takšnih storitvah je običajno nekoliko površna zadeva in se ne bomo branili pred napadi MitM, ker je to težko (ne pravzaprav).
Ali pa imate en servisni naslov znotraj pisarne in drugega iz interneta in te povezave je treba vzdrževati, kar zapravlja naše omejene strokovne vire. No, zaposleni si morajo zapomniti različne naslove, kar je neprijetno.
2. Za šifriranje svojih notranjih storitev lahko uporabite brezplačne overitelje potrdil.
Vaš lastni PKI je storitev, ki jo je treba podpreti; 100 rubljev na leto za možnost uporabe PKI od brezplačnih certifikacijskih organov plača več kot čas zaposlenih, ki bi ga lahko porabili za druge naloge.
3. Ko uporabljate lastnega overitelja potrdil, boste dali v poštev svojim oddaljenim zaposlenim in kolegom, ki želijo delati z BYOD (prinesejo svoje prenosnike, telefone, tablice) in ne morete upravljati njihovih naprav. Prinesejo Mace, Linuxe, Androide, iOS, Windows – nima smisla podpirati takega živalskega vrta.
V vsem seveda obstajajo izjeme in banke z drugimi ostrimi podjetji, ki imajo vzpostavljene varnostne politike, nikoli ne bodo mogle izboljšati storitev za svoje zaposlene.
Zanje obstajajo plačani overitelji, ki lahko za določen znesek podpišejo njihovo potrdilo CA (Google “root signing service”).
Obstajajo še drugi razlogi, zakaj je bolj donosno uporabljati javno domeno (najpomembneje je, da pripada vam), vendar ta članek ne govori o tem.
Bistvo je ...
POZOR! Če dodate potrdilo Let's Encrypt CA na ovirtov seznam zaupanja vrednih, lahko to vpliva na varnost vaših sistemov!
Prva stvar, na katero morate biti pozorni, je, da je izpostavljanje Ovirt vmesnikov internetu slaba praksa, saj To nima praktičnega smisla in ustvarja dodatne varnostne grožnje.
Zato morate pridobiti certifikat na enem od naših bastion gostiteljev, nato pa certifikat in ključ prenesti na našega gostitelja z ovirt-motorjem.
Dodamo zunanji naslov našega bastion gostitelja v dns z našim imenom ovirt ovirtengine.example.com, namestitev certbota in nginxa bom pustil v zakulisju (kako to narediti je že opisano na Habréju).
Nastavitev različice njinx >=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;
}
}
Nato dobimo potrdilo in ključ:
certbot certonly --nginx -d ovirtengine.example.com
Arhivirajte naš certifikat in ključ:
tar Phczf /tmp/ovirtengine.example.com.tgz /etc/letsencrypt/live/ovirtengine.example.com
Prenesite arhiv z bastion gostitelja in ga naložite v naš motor ovirt:
scp bastion-host:/tmp/ovirtengine.example.com.tgz /tmp/
scp /tmp/ovirtengine.example.com.tgz ovirtengine.example.com:/
Gremo naprej k cilju
Nato razpakiramo naš arhiv in ustvarimo simbolne povezave za poenostavitev razumevanja sistema lokacije datotek:
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
V Ovirtu konfiguriramo vgrajeni pki tako, da se za preverjanje potrdil uporablja shramba potrdil java (openjdk):
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
CA pretvorimo iz let's encrypt v format der in ga dodamo v shrambo potrdil ovirt java trust store (to je vsebnik, ki vsebuje seznam potrdil, tak sistem se uporablja v Javi):
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
Uredimo nastavitve SSL za apache, dodamo parameter za podporo simbolnih povezav in odstranimo parameter za CA, s katerim preverjamo potrdila (privzeto bo za preverjanje uporabljen sistemski nabor zaupanja vrednih CA):
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, ustvarjene s samodejnim PKI-jem družbe ovirt, in jih nadomestimo s simbolnimi povezavami z datotekami 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
V datotekah obnovimo kontekst SElinux in znova 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 — spletni strežnik apache
ovirt-engine - spletni vmesnik ovirt
ovirt-imageio-proxy - demon za prenos slik diska
ovirt-websocket-proxy - storitev za zagon konzole noVNC
Vse našteto je bilo testirano na Ovirt različici 4.2.
Samodejno obnavljanje certifikatov na ovirt
V skladu z dobro varnostno prakso ne sme biti povezave med bastion hostom in ovirtom, certifikat pa se izda samo za 3 mesece. Tukaj se pojavi sporno vprašanje o tem, kako sem izvedel podaljšanje certifikatov.
Imam ansible playbook, ki teče na foremanu vsak dan ob 5. uri zjutraj po urniku. Ta playbook gre v ovirt, preveri obdobje veljavnosti potrdila in če je do izteka ostalo manj kot 5 dni, gre v bastion host in začne posodabljati potrdilo.
Po posodobitvi certifikata arhivira mapo z datotekami, jo prenese na gostitelj Forman in razpakira na gostitelj Ovirt. Po tem SElinux obnovi kontekste datotek in znova zažene naše storitve.
Vir: www.habr.com
