Sammudes infrastruktuuri parandamise teel, otsustasin lahendada vana ja piinava küsimuse — võimaldada kolleegidel (arendajad, тестировщики, administraatorid jne) iseseisvalt hallata oma virtuaalmasinaid ovirt'is. Ovirt'is on mitu komponenti, mida tuleb seadistada, et seda küsimust lahendada: veebiliides, noVNC konsool ja ketaste piltide laadimine.
Nuppu "Teha vinge" ma ei leidnud, seega näitan, milliseid nuppusid ma keerasin, et selle ülesande lahendada. Täielik juhend on allpool:
KÄTTESAAMINE:
Enne alustamist tahaksin juhtida tähelepanu sellele, et mingil mulle tundmatul põhjusel luuakse infrastruktuuri domeenid privaatsetes tsoonides nagu lan, local jne.
Mis takistab organisatsiooni domeeni kasutamist avalikus tsoonis, ei ole mulle teada. Näiteks, selle asemel, et kasutada domeeni Alex-GLuck-Awesome-Company.local, võib julgelt kasutada domeeni ettevõtte veebisaidi jaoks Alex-GLuck-Awesome-Company.com.
Kui te kardate, et ei suuda jälgida oma organisatsiooni domeene ja see võib midagi rikkuda, siis tagasihoidlike 100 rubla eest aastas võite võtta eraldi domeeni infrastruktuuri jaoks aglac.com.
Miks on kasulikum kasutada domeene avalikes tsoonides:
1. Teie organisatsiooni sees tekivad teenused, mis väljuvad avalikku ruumi: VPN, failivahetus (seafile, nextcloud) ja teised. Selliste teenuste liikluse krüpteerimise seadistamine näeb tavaliselt välja nagu kiire ja kerge, ja Meie ei kaitse end MitM-i eest, sest see on keeruline (tegelikkuses mitte).
Või on teie kontoris teenuse aadress üks, kuid internetist teine, ja neid ühendusi tuleb säilitada, millele kulutatakse meie piiratud spetsialistide ressursse. Samuti peavad töötajad meeles pidama erinevaid aadresse, mis on ebamugav.
2. Te saate kasutada tasuta sertifitseerimiskeskuste teenuseid oma sisemiste teenuste krüpteerimiseks.
Omandatud PKI — see on teenus, mida tuleb toetada, 100 rubla aastas tasuta sertifitseerimiskeskuste PKI kasutamise võimaluse eest katab kenasti töötajate aja, mida nad võiksid kasutada muude ülesannete täitmiseks.
3. Kui kasutate oma sertifitseerimiskeskust, segate oma eemal olevate töötajate ja kolleegide tööd, kes soovivad kasutada BYOD (toovad oma sülearvutid, telefonid, tahvelarvutid) ja te ei saa nende seadmeid hallata. Nad toovad Macid, Linuxid, Androidid, iOS-i, Windowsi — sellise loomaaia toetamine ei oma mingit mõtet.
Muidugi on kõikjal erandeid, ja pangad koos teiste karmide ettevõtetega, kellel on püsinud turvapoliitikad, ei suuda kunagi oma teenuseid oma töötajatele parandada.
Nende jaoks on tasulised sertifitseerimiskeskused, mis teatud tasu eest saavad nende CA sertifikaadi allkirjastada (otsige 'root signing service').
On ka teisi põhjuseid, miks avaliku domeeni kasutamine on kasulikum (peamine on, et see kuuluks teile), kuid artikkel ei käsitle seda.
Oluline on asja tuum…
HOIATUSE! Kui lisate Let’s Encrypt CA sertifikaadi ovirt'ile usaldusväärsete hulka, võib see mõjutada teie süsteemide turvalisust!
Esimene asi, millele tähelepanu pöörata — ovirt'i liideseid internetti avaldada on halb praktika, kuna selles pole mingit praktilist mõtet ja see loob täiendavaid turvaohtusid.
Seega on vaja certifikaati saada mõnel meie bastion-hostil, seejärel kandke sertifikaat ja võti meie ovirt-engine hostile.
Lisame oma bastion-hosti välise aadressi DNS-isse koos meie ovirt'i nimega ovirtengine.example.com, certboti ja nginx'i installatsioon jääb minu poolt mainimata (kuidas seda teha on juba Habr's kajastatud).
Seame üles Nginx versiooniga >=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;
ssl_stapling on;
ssl_stapling_verify on;
add_header Strict-Transport-Security max-age=15768000;
location / {
return 444;
}
}
Seejärel saame meie sertifikaadi ja võtme:
certbot certonly --nginx -d ovirtengine.example.com
Arhiivime meie sertifikaadi ja võtme:
tar Phczf /tmp/ovirtengine.example.com.tgz /etc/letsencrypt/live/ovirtengine.example.com
Laadime bastioni hostilt arhiivi ja saadame selle meie ovirt-teenusele:
scp bastion-host:/tmp/ovirtengine.example.com.tgz /tmp/
scp /tmp/ovirtengine.example.com.tgz ovirtengine.example.com:/
Liigume sihtkohta
Edasi lahti pakime meie arhiivi ja loome sümboolseid linke, et süsteemi failide asukoht oleks arusaadavam:
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
Seadistame ovirtis sisseehitatud pki, et sertifikaatide kontrollimiseks kasutataks java (openjdk) sertifikaatide hoidlat:
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
Konvertime let’s encrypti CA der-formaati ja lisame selle ovirt java trust store'i sertifikaatide hoidjasse (see on konteiner, kus hoitakse sertifikaatide nimekirja, mida kasutatakse javis):
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 SSL-i seadeid, lisame sümboollinkide toe ning eemaldame CA parameetri, millega sertifikaate kontrollitakse (vaikimisi kasutatakse süsteemi usaldusväärsete CA-de komplekti kontrollimiseks):
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 varundame igaks juhuks originaalfailid, mis on genereeritud PKI ovirt'i automaatika teel, ja asendame sümboollinkidega Let's Encrypti failid:
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 taaskäivitame 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 — ovirti veebi liides
ovirt-imageio-proxy — ketaste piltide laadimise daemoon
ovirt-websocket-proxy — teenus noVNC konsooli jaoks
Kõik eelpool loetletud on testitud ovirti versioonil 4.2.
Ovirti sertifikaatide automaatne uuendamine
Hea turvapraktika kohaselt ei tohiks bastioni ja ovirti vahel olla ühendust ning sertifikaat väljastatakse vaid kolmeks kuuks. Siinkohal tekib vaieldav küsimus, kuidas sertifikaatide uuendamine on mul korraldatud.
Mul on ansible'i mänguplaan, mis käivitatakse igapäevaselt Foremanis kell 5 hommikul ajakava järgi. See mänguplaan siseneb ovirti, kontrollib sertifikaadi kehtivusaega ja kui kehtivuse lõpuni on jäänud vähem kui 5 päeva, läheb bastioni ja käivitab sertifikaadi uuendamise.
Pärast sertifikaadi uuendamist arhiveerib ta failide kausta, laadib Foremani hostisse ja dekomprimeerib selle ovirti hostis. Seejärel taastab ta failide SElinux kontekstid ja taaskäivitame meie teenused.
Allikas: habr.com
