Infrastruktuuri täiustamise teel otsustasin lahendada juba ammu vaevanud küsimuse — pakkuda kolleegidele (arendajatele, testijatele, administraatoritele jne) võimaluse hallata oma virtuaalmasinaid ovirt's ilma liigsete pingutusteta. Ovirtis on mitmeid komponente, mis tuleb minu probleemi lahendamiseks seadistada: veebiliides, noVNC konsool ja ketta piltide laadimine.
Ei leidnud nuppu „Tee lahe“, seetõttu näitan, milliseid nuppe ma keerasin, et seda ülesannet lahendada. Täielik juhend on allpool:
DISCLAIMER:
Enne alustamist tahaksin juhtida tähelepanu, et mõne mulle teadmata põhjusel luuakse infrastruktuuri domeenid privaatsetes tsoonides nagu lan, local jne.
Mille tõttu ei saa kasutada organisatsiooni domeeni avalikus tsoonis, ei ole mulle teada. Näiteks, selle asemel, et kasutada domeeni Alex-GLuck-Awesome-Company.local, on täiesti võimalik kasutada ettevõtte veebisaidi domeeni Alex-GLuck-Awesome-Company.com.
Kui te kardate, et ei suuda oma organisatsioonis domeene jälgida ja see midagi ära rikub, siis väikese 100 rubla aastamaksu eest saate võtta eraldi domeeni infrastruktuuri jaoks aglac.com.
Miks on avalikes piirkondades domeenide kasutamine soodsam:
1. Teie organisatsioonis tekivad teenused, mis saavad ligipääsu avalikkusele: VPN, failide jagamine (Seafile, Nextcloud) ja teised. Traffic'i krüpteerimise seadistamine sellistes teenustes näeb tavaliselt välja nagu killustik ja MitM rünnakute eest me end ei kaitsme, kuna see on keeruline (tegelikult pole see nii).
Või on teie kontoris teenuse ühtne aadress, kuid internetist juurdepääsuks on see teine, ning neid seoseid tuleb säilitada, milleks kulutame meie piiratud spetsialistide ressursse. Lisaks peavad töötajad mäletama erinevaid aadresse, mis tekitab ebamugavusi.
2. Saate kasutada tasuta sertifitseerimiskeskusi oma siseteenuste krüpteerimiseks.
Oma PKI on teenus, mida tuleb hooldada; 100 rubla aastas tasuta sertifitseerimiskeskuste PKI kasutamise võimaluse eest katab ära töötajate aja, mida nad saaksid kulutada teistele ülesannetele.
Kasutades oma sertifitseerimiskeskust, paned sa takistusi oma kaug töötajatele ja kolleegidele, kes soovivad kasutada BYOD (toovad oma sülearvuteid, telefone, tahvelarvuteid), ning sa ei saa nende seadmeid hallata. Nad toovad Mac-id, Linuxid, Androidid, iOS-i, Windowsi — sellise loomaaias hoidmine ei oma mingit mõtet.
Muidugi on kõigis asjades erandeid, ning pangad koos teiste karmide ettevõtetega, kellel on kehtestatud turvapoliitikad, ei suuda enam kunagi oma teenuseid oma töötajatele parandada.
Nende jaoks on saadaval tasulised sertifitseerimiskeskused, mis teatud tasu eest saavad nende CA sertifikaadi allkirjastada (otsi 'root signing service').
On ka teisi põhjuseid, miks avaliku domeeni kasutamine on kasulikum (peamine on, et see kuulub sulle), kuid artikkel ei käsitle seda.
Oma asja point...
Tähelepanu! Kui lisad Let’s Encrypt’i CA sertifikaadi ovirt’i usaldatute nimekirja, võib see mõjutada sinu süsteemide turvalisust!
Esimene asi, millele tähelepanu pöörata, on see, et ovirt'i liidese väljapandmine interneti on halba praktika, kuna see ei oma mingit praktilist mõtet ja loob täiendavaid turvaohtusid.
Seega on vajalik sertifikaadi saamine mõnel meie bastionihostist, mille järel tuleb sertifikaat ja võti meie hostile ovirt-engine'iga üle kanda.
Lisame meie bastionihosti välise aadressi DNS-ise koos meie ovirt'i nimega. ovirtengine.example.com, certboti ja nginx'i installatsiooni jätan ma kõrvale (kuidas seda teha on juba Habr'is kirjeldatud).
Seame üles Nginx'i versioonis >=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;
# lubame serverile OCSP vastuste lisamise, et vähendada laadimisaja
ssl_stapling on;
ssl_stapling_verify on;
add_header Strict-Transport-Security max-age=15768000;
location / {
return 444;
}
}
Seejärel saame oma sertifikaadi ja võtme:
certbot certonly --nginx -d ovirtengine.example.com
Arhiveerime meie sertifikaadi ja võtme:
tar Phczf /tmp/ovirtengine.example.com.tgz /etc/letsencrypt/live/ovirtengine.example.com
Laadime bastion-hostilt alla arhiivi ja laadime selle oma ovirt-engine'i:
scp bastion-host:/tmp/ovirtengine.example.com.tgz /tmp/
scp /tmp/ovirtengine.example.com.tgz ovirtengine.example.com:/
Sammume sihtkohta
Seejärel lahti pakime meie arhiivi ja loome sümboolsed lingid, et hõlbustada failide asukoha mõistmist:
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
Seame ovirtis sisse sisseehitatud pki, et kasutada sertifikaatide kontrollimiseks java (openjdk) sertifikaadipoe:
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
Konverteerime let’s encrypt CA der formaati ja lisame selle ovirt's java trust store'i (see on konteiner, kus hoitakse sertifikaatide nimekirja, sellist süsteemi kasutatakse javades):
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
Muudame Apache'i SSL-seadeid, lisame sümbolite toimetamiseks parameetri ja eemaldame CA parameetri, millega sertifikaate kontrollida (vaikimisi kasutatakse süsteemi usaldusväärsete CA-de kogumit):
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
Seejärel teeme igaks juhuks originaalfailidest varukoopia, mis on genereeritud PKI ovirt’a poolt automaatselt, ja asendame sümbolid Let’s Encrypti failidega:
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
Taastame failide SElinux kontekstid ja käivitame uuesti meie teenused (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 — veebiserver. apache
ovirt-engine — ovirt'i veebiliides
ovirt-imageio-proxy — demon ketasfailide laadimiseks
ovirt-websocket-proxy — teenus noVNC konsooli jaoks
Kõik ülaltoodud on kontrollitud oVirt 4.2 versioonil.
Sertifikaatide automaatne uuendamine oVirtis.
Heade turvapraktikate kohaselt ei tohiks bastion-host ja oVirt omavahel ühenduses olla ning sertifikaat antakse välja vaid kolmekuuseks. Siin tekib vaieldav hetk, kuidas on sertifikaatide uuendamine minu puhul teostatud.
Mul on Ansible'i mänguplaan, mis töötab Foremani peal iga päev kell 5 hommikul graafiku alusel. See mänguplaan siseneb oVirti, kontrollib sertifikaadi kehtivusaega ja kui kehtivus on vähem kui 5 päeva, läheb bastion-hostile ja käivitab sertifikaadi uuendamise.
Pärast sertifikaadi uuendamist arhiveerib ta failide kausta, laadib Foremani hostile alla ja dekompresseerib oVirti hostile. Seejärel taastab ta failide SElinux kontekstid ja taaskäivitab meie teenused.
Allikas: habr.com
