Kročením po ceste zlepšenia infraštruktúry som sa rozhodol vyriešiť starý a mučivý problém — bez zbytočného behania poskytnúť kolegom (vývojárom, testerom, administrátorom a pod.) možnosť samostatne spravovať svoje virtuálne stroje v ovirt-e. V ovirt existuje niekoľko komponentov, ktoré je potrebné nastaviť na vyriešenie môjho problému: samotné webové rozhranie, noVNC konzolu a nahádzanie obrazov diskov.
Našiel som len zopár tlačidiel «Spraviť zázrak», tak ukazujem, aké úpravy som robil, aby som túto úlohu splnil. Kompletný návod je pod odkazom:
ZODPOVEDNOSŤ:
Pred začiatkom by som rád upozornil, že z neznámeho mi dôvodu sú domény infraštruktúry vytvárané v súkromných zónach lan, local, a podobne.
Čo bráni použitiu domény organizácie v verejnej zóne, neviem. Napríklad, namiesto domény Alex-GLuck-Awesome-Company.local, môžeme smelo použiť doménu pre webovú stránku spoločnosti Alex-GLuck-Awesome-Company.com.
Ak sa bojíte, že nebudete schopní sledovať domény vo svojej organizácii a že to niečo pokazí, môžete si za skromných 100 rubľov ročne získať samostatnú doménu pre infraštruktúru aglac.com.
Prečo je výhodnejšie používať domény vo verejných zónach:
1. V rámci organizácie sa objavujú služby, ktoré sa dostávajú do verejného priestoru: vpn, zdieľanie súborov (seafile, nextcloud) a iné. Nastavenie šifrovania premávky na takýchto službách obvykle vyzerá ako improvisácia, a chrániť sa pred MitM nebude jednoduché (v skutočnosti nie je).
Ale vo vnútri kancelárie máte jednu adresu služby, a z internetu inú, a tieto spojenia musíte udržiavať, na čo míňame naše obmedzené zdroje odborníkov. A zamestnanci si musia pamätať rôzne adresy, čo je nepríjemné.
2. Môžete používať bezplatné certifikačné centrá na šifrovanie vašich interných služieb.
Vlastný PKI — to je služba, ktorú treba udržiavať, 100 rubľov ročne za možnosť používania PKI od bezplatných certifikačných centier sa bohatou vyplatí čas zamestnancov, ktorí by ho mohli tráviť na iné úlohy.
3. Používanie vlastného certifikačného centra bude prekážkou vašim vzdialeným zamestnancom a kolegom, ktorí chcú pracovať s BYOD (prinášajú svoje notebooky, telefóny, tablety) a vy nemôžete spravovať ich zariadenia. Prinášajú Macy, Linuxy, Androidy, iOS a Windows – nemá zmysel podporovať takúto zmes zariadení.
Samozrejme, existujú výnimky, a banky s inými vážnymi podnikmi, ktoré majú zavedené bezpečnostné politiky, už nikdy nebudú schopné zlepšiť služby pre svojich zamestnancov.
Pre nich existujú platené certifikačné centra, ktoré za určitú sumu môžu podpísať ich CA certifikát (vyhľadajte „root signing service“).
Existujú aj ďalšie dôvody, prečo je výhodnejšie používať verejnú doménu (najdôležitejšie je, aby patrila vám), ale to nie je téma článku.
Podstata, a vec…
POZOR! Ak pridáte certifikát CA od Let’s Encrypt do zoznamu dôveryhodných pre ovirt, môže to ovplyvniť bezpečnosť vašich systémov!
Prvé, na čo treba upozorniť – vystavovať ovirt rozhrania na internet je zlá prax, pretože to nemá žiadny praktický zmysel a vytvára dodatočné bezpečnostné hrozby.
Nasledujúco je nutné získať certifikát na niektorom našom bastion hoste a potom preniesť certifikát a kľúč na náš hostiteľ s ovirt-engine.
Pridajte externú adresu nášho bastion hosta do DNS s naším názvom ovirt. ovirtengine.example.com, inštaláciu certbot a nginx nechám bokom (ako to urobiť na habre už bolo opísané).
Nastavujeme nginx verzie >=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;
# Allowing the server to attach OCSP responses, thus reducing page loading times for users
ssl_stapling on;
ssl_stapling_verify on;
add_header Strict-Transport-Security max-age=15768000;
location / {
return 444;
}
}
Potom dostaneme náš certifikát a kľúč:
certbot certonly --nginx -d ovirtengine.example.com
Archivujeme náš certifikát a kľúč:
tar Phczf /tmp/ovirtengine.example.com.tgz /etc/letsencrypt/live/ovirtengine.example.com
Stiahneme archív z bastion hosta a nahrajeme ho na náš ovirt engine:
scp bastion-host:/tmp/ovirtengine.example.com.tgz /tmp/
scp /tmp/ovirtengine.example.com.tgz ovirtengine.example.com:/
Prejdeme k cieľu
Ďalej rozbalíme náš archív a vytvoríme symbolické odkazy pre lepšie pochopenie systému umiestnenia súborov:
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
Nastavujeme vstavané pki v ovirte, aby sa na overovanie certifikátov používalo úložisko certifikátov 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
Konvertujeme CA od let’s encrypt do formátu der a pridáme ho do úložiska certifikátov java trust store ovirta (to je kontajner, v ktorom sa nachádza zoznam certifikátov, tento systém sa používa v javách):
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
Upravujeme nastavenia SSL pre Apache, pridávame parameter na podporu symlinkov a odstraňujeme parameter pre CA, ktorým sa overujú certifikáty (predvolene sa bude používať systémová sada dôveryhodných CA na overovanie):
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
Potom zálohujeme originálne súbory generované prostredníctvom PKI ovirt a nahrádzame symlinkmi na súbory z 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
Obnovujeme kontexty SElinux na súboroch a reštartujeme naše služby (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 server apache
ovirt-engine — webové rozhranie ovirt
ovirt-imageio-proxy — démon na nahrávanie diskových obrazov
ovirt-websocket-proxy — služba pre fungovanie noVNC konzoly
Všetko vyššie uvedené bolo overené na verzii ovirta 4.2.
Automatické aktualizácie certifikátov na ovirt
Podľa dobrých bezpečnostných praktík by nemala existovať priama komunikácia medzi bastion-hostom a ovirtom, a certifikát sa vydáva iba na 3 mesiace. Tu nastáva sporný moment ohľadom toho, ako je realizované aktualizovanie certifikátov.
Mám ansible playbook, ktorý sa spúšťa na foreman každý deň o 5:00 ráno podľa rozvrhu. Tento playbook sa prihlási do ovirt, skontroluje platnosť certifikátu a ak zostáva menej než 5 dní do vypršania, ide na bastion-host a spúšťa aktualizáciu certifikátu.
Po aktualizácii certifikátu archívuje priečinok so súbormi, stiahne ho na hostiteľovi foreman a rozbalí ho na hostiteľovi ovirt. Potom obnovuje kontexty SElinux na súboroch a reštartujeme naše služby.
Zdroj: habr.com
