În drum spre îmbunătățirea infrastructurii, am decis să rezolv o problemă veche și dificilă — fără mișcări inutile, să ofer colegilor (dezvoltatori, testeri, administratori etc.) posibilitatea de a gestiona singuri mașinile lor virtuale în ovirt. În ovirt există mai multe componente care trebuie configurate pentru a rezolva problema mea: interfața web, consola noVNC și încărcarea imaginilor de discuri.
Butonul „Fă-o Super” nu l-am găsit, așa că arăt ce setări am ajustat pentru a rezolva această sarcină. Instrucțiunea completă este mai jos:
DISCLAIMER:
Înainte de a începe, aș dori să subliniez că, dintr-o cauză necunoscută, domeniile infrastructurii sunt create în zone private, precum lan, local etc.
Ce anume împiedică utilizarea domeniului organizației în zona publică îmi este necunoscut. De exemplu, în loc de domeniul Alex-GLuck-Awesome-Company.local, se poate folosi linistit domeniul pentru site-ul companiei Alex-GLuck-Awesome-Company.com.
Dacă vă temeți că nu veți putea urmări domeniile din organizația dvs. și că asta ar putea cauza probleme, pentru o modestă sumă de 100 de ruble pe an puteți cumpăra un domeniu separat pentru infrastructură aglac.com.
De ce este mai avantajos să folosiți domenii în zone publice:
1. În cadrul organizației dvs. apar servicii care ies în spațiul public: VPN, schimbul de fișiere (seafile, nextcloud) și altele. Configurarea criptării traficului pe astfel de servicii arată de obicei ca o soluție improvizată, iar apărarea împotriva atacurilor MitM nu o vom face, deoarece este complicat (de fapt, nu este).
Sau, în cadrul biroului, aveți o adresă de serviciu, iar din internet este alta, iar aceste legături trebuie întreținute, ceea ce consumă resursele noastre limitate de specialiști. De asemenea, angajații sunt nevoiți să rețină adrese diferite, ceea ce este incomod.
2. Puteți folosi centre de certificare gratuite pentru criptarea serviciilor interne.
PKI-ul propriu — este un serviciu care trebuie întreținut, 100 de ruble pe an pentru a utiliza PKI de la centrele de certificare gratuite compensează din plin timpul angajaților care ar putea să-l dedice altor sarcini.
Folosind un centru de certificare propriu, veți pune piedici angajaților și colegilor dvs. de la distanță care doresc să lucreze cu BYOD (își aduc laptopurile, telefoanele, tabletele), iar dvs. nu puteți gestiona dispozitivele lor. Aceștia aduc Mac-uri, Linux-uri, Android-uri, iOS-uri, Windows – nu are niciun sens să susțineți un astfel de zoo.
Desigur, există excepții, iar băncile cu alte mari corporații, care au politici de securitate bine stabilite, nu vor putea niciodată să îmbunătățească serviciile pentru angajații lor.
Pentru ei există centre de certificare cu plată, care, pentru o sumă anume, pot semna certificatul CA (googlați „root signing service”).
Există și alte motive pentru care utilizarea unui domeniu public este mai avantajoasă (cel mai important, să vă aparțină), dar articolul nu este despre asta.
Esentialul este…
ATENȚIE! Dacă adăugați certificatul CA de la Let’s Encrypt în lista celor de încredere pentru oVirt, acest lucru poate afecta securitatea sistemelor dvs.!
Primul lucru la care trebuie să fiți atenți este că expunerea interfețelor oVirt pe internet este o practică proastă, deoarece nu are niciun sens practic și generează amenințări suplimentare la adresa securității.
Prin urmare, trebuie să obțineți certificatul pe un bastion host al nostru, după care să transferați certificatul și cheia pe hostul nostru cu oVirt Engine.
Adăugăm adresa externă a bastion host-ului nostru în DNS cu numele nostru de oVirt ovirtengine.example.com, instalarea certbot și nginx o voi lăsa pentru altă dată (cum se face acest lucru a fost deja descris pe Habr).
Configurăm Nginx versiunea >=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;
# allows the server to attach OCSP responses, thereby reducing page load time for users
ssl_stapling on;
ssl_stapling_verify on;
add_header Strict-Transport-Security max-age=15768000;
location / {
return 444;
}
}
Apoi obținem certificatul și cheia noastră:
certbot certonly --nginx -d ovirtengine.example.com
Arhivăm certificatul și cheia noastră:
tar Phczf /tmp/ovirtengine.example.com.tgz /etc/letsencrypt/live/ovirtengine.example.com
Descărcăm arhiva de pe hostul bastion, o transferăm pe ovirt-engine-ul nostru:
scp bastion-host:/tmp/ovirtengine.example.com.tgz /tmp/
scp /tmp/ovirtengine.example.com.tgz ovirtengine.example.com:/
Trecem la destinație
Apoi dezarhivăm arhiva noastră și creăm linkuri simbolice pentru a facilita înțelegerea sistemului de organizare a fișierelor:
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
Configurăm pki-ul încorporat în ovirt, astfel încât pentru verificarea certificatelor să fie folosit magazinul de certificati java(openjdk):
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
Convertim CA de la let’s encrypt în format der și o adăugăm în magazinul de certificați java trust store al ovirtului (acesta este un container care conține lista de certificați, un astfel de sistem este folosit în 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
Modificăm setările SSL pentru Apache, adăugând un parametru pentru suportul linkurilor simbolice și eliminând parametrul pentru CA utilizat pentru validarea certificatelor (va utiliza implicit setul sistemic de CA de încredere pentru verificare):
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
După care, facem backup, pentru orice eventualitate, al fișierelor originale, generate automat prin PKI ovirt, și înlocuim cu linkuri simbolice la fișierele de la 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
Restaurăm contextele SElinux pe fișiere și repornim serviciile noastre (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 apache
ovirt-engine — interfața web ovirt
ovirt-imageio-proxy — daemon pentru încărcarea imaginilor de disc
ovirt-websocket-proxy — serviciu pentru funcționarea consolei noVNC
Tot ce este enumerat mai sus a fost verificat pe versiunea ovirt 4.2.
Actualizarea automată a certificatelor pe ovirt
Conform bunelor practici de securitate, nu ar trebui să existe o conexiune între serverul de bastion și ovirt, iar certificatul este emis doar pentru 3 luni. Aici apare o întrebare controversată despre cum este implementată actualizarea certificatelor la mine.
Am un playbook Ansible care rulează pe foreman zilnic la 5 dimineața, conform programului. Acest playbook accesează ovirt, verifică termenul de valabilitate al certificatului și, dacă mai rămân mai puțin de 5 zile până la expirare, se duce la serverul de bastion și inițiază actualizarea certificatului.
După actualizarea certificatului, arhivează folderul cu fișiere, îl descarcă pe serverul foreman și îl dezarhivează pe serverul ovirt. După aceasta, restaurează contextele SElinux pe fișiere și repornim serviciile noastre.
Sursa: habr.com
