Duke ecur përgjatë rrugës së përmirësimit të infrastrukturës, vendosa të përfundoj një pyetje të lashtë dhe të dhimbshme - pa gjeste të panevojshme, t'u jap mundësinë kolegëve (zhvilluesve, testuesve, administratorëve, etj.) të menaxhojnë në mënyrë të pavarur makinat e tyre virtuale në ovirt. Ovirt ka disa komponentë që duhet të konfigurohen për të zgjidhur problemin tim: vetë ndërfaqja e uebit, konsola noVNC dhe ngarkimi i imazheve të diskut.
Nuk e gjeta butonin "Make It Bad", kështu që po ju tregoj se cilat pulla kam kthyer për të zgjidhur këtë problem. Udhëzimet e plota poshtë prerjes:
DISCLAIMER:
Para se të filloj, dëshiroj të tërheq vëmendjen tuaj për faktin se për ndonjë arsye të panjohur për mua, domenet e infrastrukturës krijohen në zona private lan, lokale, etj.
Nuk e di se çfarë më pengon të përdor domenin e një organizate në një zonë publike. Për shembull, në vend të domenit Alex-GLuck-Awesome-Company.local, mund të përdorni me siguri domenin për faqen e internetit të kompanisë Alex-GLuck-Awesome-Company.com.
Nëse keni frikë se nuk do të jeni në gjendje të mbani gjurmët e domeneve në organizatën tuaj dhe kjo do të prishë diçka, atëherë për një 100 rubla modeste në vit mund të blini një domen të veçantë për infrastrukturën aglac.com.
Pse është më fitimprurëse përdorimi i domeneve në zonat publike:
1. Organizata juaj ka shërbime që janë të aksesueshme publikisht: përfshirë, ndarja e skedarëve (seafile, nextcloud) dhe të tjera. Konfigurimi i enkriptimit të trafikut në shërbime të tilla është zakonisht një punë paksa e shpejtë dhe ne nuk do të mbrohemi nga sulmet MitM sepse është e vështirë (jo tamam).
Ose keni një adresë shërbimi brenda zyrës dhe një tjetër nga interneti, dhe këto lidhje duhet të mirëmbahen, gjë që harxhon burimet tona të kufizuara të specialistëve. Epo, punonjësit duhet të mbajnë mend adresa të ndryshme, gjë që është e papërshtatshme.
2. Ju mund të përdorni autoritetet falas të certifikatës për të enkriptuar shërbimet tuaja të brendshme.
PKI juaj është një shërbim që duhet të mbështetet; 100 rubla në vit për mundësinë për të përdorur PKI nga autoritetet e certifikimit falas më shumë sesa paguan për kohën e punonjësve që mund ta shpenzojnë atë për detyra të tjera.
3. Kur përdorni autoritetin tuaj të certifikatës, do të vendosni një fole në rrotat e punonjësve dhe kolegëve tuaj në distancë që duan të punojnë me BYOD (të sjellin laptopët, telefonat, tabletët e tyre) dhe nuk mund të menaxhoni pajisjet e tyre. Ata sjellin Mac, Linux, Android, iOS, Windows - nuk ka kuptim të mbështesim një kopsht të tillë zoologjik.
Në çdo gjë, natyrisht, ka përjashtime dhe bankat me ndërmarrje të tjera të ashpra që kanë vendosur politika sigurie nuk do të jenë kurrë në gjendje të përmirësojnë shërbimin për punonjësit e tyre.
Për ta, ka autoritete certifikimi me pagesë që mund të nënshkruajnë certifikatën e tyre CA për një shumë të caktuar ("shërbimi i nënshkrimit rrënjësor" të Google).
Ka arsye të tjera pse është më fitimprurëse përdorimi i një domeni publik (më e rëndësishmja është se ju takon juve), por ky artikull nuk ka të bëjë me këtë.
Çështja është...
KUJDES! Nëse shtoni një certifikatë Let's Encrypt CA në listën e besuar të ovirt, kjo mund të ndikojë në sigurinë e sistemeve tuaja!
Gjëja e parë që duhet t'i kushtoni vëmendje është se ekspozimi i ndërfaqeve Ovirt në internet është praktikë e keqe, sepse Kjo nuk ka kuptim praktik dhe krijon kërcënime shtesë për sigurinë.
Prandaj, ju duhet të merrni një certifikatë në një nga hostet tona të bastionit dhe më pas të transferoni certifikatën dhe çelësin te hosti ynë me motorin ovirt.
Ne shtojmë adresën e jashtme të hostit tonë bastion në dns me emrin tonë ovirt ovirtengine.example.com, Unë do ta lë instalimin e certbot dhe nginx prapa skenave (si ta bëni këtë është përshkruar tashmë në Habré).
Konfigurimi i versionit 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;
}
}
Pastaj marrim certifikatën dhe çelësin tonë:
certbot certonly --nginx -d ovirtengine.example.com
Arkivoni certifikatën dhe çelësin tonë:
tar Phczf /tmp/ovirtengine.example.com.tgz /etc/letsencrypt/live/ovirtengine.example.com
Shkarkoni arkivin nga hosti i bastionit dhe ngarkoni atë në motorin tonë ovirt:
scp bastion-host:/tmp/ovirtengine.example.com.tgz /tmp/
scp /tmp/ovirtengine.example.com.tgz ovirtengine.example.com:/
Le të kalojmë te qëllimi
Më pas, ne shpaketojmë arkivin tonë dhe krijojmë lidhje simbolike për të thjeshtuar kuptimin e sistemit të vendndodhjes së skedarëve:
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
Ne konfigurojmë pki-në e integruar në Ovirt në mënyrë që ruajtja e certifikatave java (openjdk) të përdoret për të verifikuar certifikatat:
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
Ne e konvertojmë CA-në nga let's encrypt në format der dhe e shtojmë atë në dyqanin e certifikatave të ovirt java trust store (ky është një kontejner që përmban një listë certifikatash, një sistem i tillë përdoret 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
Ne redaktojmë cilësimet SSL për apache, shtojmë një parametër për të mbështetur lidhjet simbolike dhe heqim parametrin për CA me të cilin kontrollohen certifikatat (si parazgjedhje, grupi i sistemit të CA-ve të besuara do të përdoret për verifikim):
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
Më pas, për çdo rast, ne bëjmë kopje rezervë të skedarëve origjinal të krijuar përmes PKI-së automatike të ovirt dhe i zëvendësojmë ato me lidhje simbolesh me skedarë nga 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
Ne rivendosim kontekstet SElinux në skedarë dhe rinisim shërbimet tona (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 — server web apache
ovirt-engine - ndërfaqe ueb ovirt
ovirt-imageio-proxy - demon për shkarkimin e imazheve të diskut
ovirt-websocket-proxy - shërbim për ekzekutimin e konsolës noVNC
Të gjitha sa më sipër u testuan në versionin 4.2 të Ovirt.
Rinovimi automatik i certifikatave në ovirt
Sipas praktikave të mira të sigurisë, nuk duhet të ketë lidhje midis hostit të bastionit dhe ovirtit dhe certifikata lëshohet vetëm për 3 muaj. Pikërisht këtu lind një çështje e diskutueshme se si kam zbatuar rinovimin e certifikatave.
Unë kam një libër lojërash ansible që funksionon në kryepunëtor çdo ditë në orën 5 të mëngjesit sipas një orari. Ky libër lojërash shkon në ovirt, kontrollon periudhën e vlefshmërisë së certifikatës dhe nëse kanë mbetur më pak se 5 ditë para skadimit, ai shkon te hosti i bastionit dhe fillon përditësimin e certifikatës.
Pas përditësimit të certifikatës, ai arkivon dosjen me skedarë, e shkarkon atë në hostin Forman dhe e zbërthen në hostin Ovirt. Pas së cilës SElinux rikthen kontekstet në skedarë dhe rinis shërbimet tona.
Burimi: www.habr.com
