Na cestě ke zlepšení infrastruktury jsem se rozhodl vyřešit starý a bolavý problém — bez zbytečných pohybů poskytnout kolegům (vývojářům, testerům, správcům atd.) možnost samostatně spravovat své virtuální stroje v ovirt. V ovirt je několik komponent, které je třeba nastavit pro vyřešení mého dotazu: samotné webové rozhraní, konzole noVNC a nahrávání obrazů disků.
Hledal jsem tlačítko „Udělat skvělé věci“, ale nenašel jsem ho, takže ukazuji, jaké úpravy jsem provedl, abych toto zadání vyřešil. Úplný návod je níže:
UPOZORNĚNÍ:
Před začátkem bych rád upozornil, že z nějakého mně neznámého důvodu jsou domény infrastruktury vytvářeny v privátních zónách lan, local atd.
Co mi brání používat doménu organizace v veřejné zóně, mi není jasné. Například namísto domény Alex-GLuck-Awesome-Company.local lze bez obav použít doménu pro webové stránky společnosti Alex-GLuck-Awesome-Company.com.
Pokud se obáváte, že nebudete schopni sledovat domény ve své organizaci a že něco porušíte, můžete si za skromné 100 korun ročně vzít samostatnou doménu pro infrastrukturu aglac.com.
Proč je výhodnější používat domény ve veřejných zónách:
1. Ve vaší organizaci se objevují služby, které se spojují s veřejným prostorem: vpn, sdílení souborů (seafile, nextcloud) a další. Nastavení šifrování provozu na takových službách obvykle vypadá jako zmatek, a ochrana před MitM je komplikovaná (ve skutečnosti ne).
Nebo máte v kanceláři jednu adresu služby, ale z internetu je jiná, a tyto spojení je třeba udržovat, což vyžaduje naše omezené zdroje specialistů. Navíc si zaměstnanci musí pamatovat různé adresy, což je nepohodlné.
2. Můžete využít bezplatné certifikační autority pro šifrování vašich interních služeb.
Vlastní PKI — to je služba, kterou je třeba udržovat, 100 korun ročně za možnost použití PKI od bezplatných certifikačních autorit více než pokryje čas zaměstnanců, kteří by ho mohli věnovat jiným úkolům.
3. Při použití vlastního certifikačního centra budete komplikovat práci svým vzdáleným zaměstnancům a kolegům, kteří chtějí pracovat s BYOD (přinášejí vlastní notebooky, telefony, tablety), a nebudete moci spravovat jejich zařízení. Přinášejí Mac, Linux, Android, iOS, Windows — udržovat takovou směsici nemá žádný smysl.
Samozřejmě existují výjimky a banky s jinými velkými podniky, které mají zavedené bezpečnostní politiky, už nikdy nebudou schopny zlepšit služby pro své zaměstnance.
Pro ně existují placená certifikační centra, která za určitou částku mohou podepsat jejich CA certifikát (googlete „root signing service“).
Existují i jiné důvody, proč je výhodnější používat veřejnou doménu (nejdůležitější je, aby patřila vám), ale článek o tom není.
Podstata, ano…
POZOR! Pokud přidáte certifikát CA od Let’s Encrypt do seznamu důvěryhodných pro ovirt, může to ovlivnit bezpečnost vašich systémů!
První, na co je třeba si dát pozor — vystavování ovirt rozhraní na internet je špatná praxe, protože to nemá žádný praktický smysl a vytváří to další bezpečnostní hrozby.
Proto je třeba získat certifikát na nějakém našem bastionovém hostiteli, a poté přenést certifikát a klíč na náš host s ovirt-engine.
Přidáváme externí adresu našeho bastionového hosta do DNS s naším názvem ovirta ovirtengine.example.com, instalaci certbota a nginx nechám stranou (jak to udělat je již popsáno na Habru).
Konfigurujeme nginx verze >=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;
}
}
Pak získáme náš certifikát a klíč:
certbot certonly --nginx -d ovirtengine.example.com
Paketujeme náš certifikát a klíč:
tar Phczf /tmp/ovirtengine.example.com.tgz /etc/letsencrypt/live/ovirtengine.example.com
Stáhneme archiv z bastion-hostu 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:/
Přejdeme k cíli
Dále rozbalíme náš archiv a vytvoříme symbolické odkazy pro lepší pochopení systému umístění souborů:
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 integrovanou PKI v ovirtu, aby používala úložiště certifikátů Java (openjdk) pro ověřování certifikátů:
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 přidáme ji do úložiště certifikátů Java trust store ovirta (je to takový kontejner, ve kterém je seznam certifikátů, tento systém se používá v 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
Upravujeme nastavení SSL pro Apache, přidáváme parametr pro podporu symlinků a odstraňujeme parametr pro CA, kterým se ověřují certifikáty (podle defaultu se použije systémová sada důvěryhodných CA pro ověřování):
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
Poté zálohujeme originální soubory automaticky generované prostřednictvím PKI ovirt na každou náhodu a nahrazujeme je symlinky na soubory od 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 souborech a restartujeme 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 — webový server apache
ovirt-engine — webové rozhraní ovirt
ovirt-imageio-proxy — démon pro stahování obrazů disků
ovirt-websocket-proxy — služba pro práci s konzolí noVNC
Vše výše uvedené bylo ověřeno na verzi ovirt 4.2.
Automatická aktualizace certifikátů na ovirt
Podle dobrých bezpečnostních praktik by mezi bastion-hostem a ovirtem neměla být žádná komunikace, a certifikát se vydává pouze na 3 měsíce. Zde se objevuje sporný bod ohledně toho, jak je aktualizace certifikátů u mě realizována.
Mám Ansible playbook, který se spouští na Foreman každodenně v 5 hodin ráno podle rozpisu. Tento playbook se přihlásí do ovirtu, zkontroluje dobu platnosti certifikátu a pokud zbývá méně než 5 dní do vypršení, jde na bastion-host a spouští aktualizaci certifikátu.
Po aktualizaci certifikátu archivuje složku se soubory, stáhne ji na hostitele Foreman a rozbalí na hostiteli ovirt. Poté obnovuje kontexty SElinux na souborech a restartujeme naše služby.
Zdroj: habr.com
