Крокуючи шляхом поліпшення інфраструктури, я вирішив добити стародавнє і болісне питання - без зайвих рухів тіла надавати можливість колегам (розробникам, тестувальникам, адмінам, etc) самостійно керувати своїми віртуалками в ovirt'є. У ovirt є кілька компонентів, які треба налаштувати для вирішення мого питання: сам веб-інтерфейс, noVNC консоль і заливка образів дисків.
Кнопки "Зробити Зашибісь" я не знайшов, тому показую які ручки я крутив, щоб вирішити це завдання. Повна інструкція під катом:
ВІДМОВА ВІД ВІДПОВІДАЛЬНОСТІ:
Перед початком хотів би звернути увагу, що з якоїсь невідомої причини домени інфраструктури створюються в приватних зонах lan, local, і так далі.
Що заважає використовувати домен організації у громадській зоні мені невідомо. Наприклад, замість домену Alex-GLuck-Awesome-Company.local можна сміливо використовувати домен для сайту компанії Alex-GLuck-Awesome-Company.com.
Якщо ви боїтеся, що не зможете встежити за доменами в своїй організації, і це зламає щось, то за скромні 100 рублів на рік можете взяти окремий домен для інфраструктури aglac.com.
Чому вигідніше використовувати домени у публічних зонах:
1. У вас всередині організації з'являються послуги, що виходять в громадський простір: ВПН, обмін файлами (seafile, nextcloud) та інші. Налаштовувати шифрування трафіку на таких сервісах зазвичай виглядає як тяп-ляп, і від MitM захищатись ми не будемо, тому що складно (насправді ні).
Або всередині офісу у вас одна адреса сервісу, а з інтернету інша, і ці зв'язки треба підтримувати, на що витрачаються наші обмежені ресурси фахівців. Та й співробітникам доводиться запам'ятовувати різні адреси, що незручно.
2. Ви можете використовувати безкоштовні центри сертифікації для шифрування ваших внутрішніх послуг.
Власний PKI - це сервіс, який треба підтримувати, 100 рублів на рік за можливість використання PKI від безкоштовних центрів сертифікації з лишком окупають час співробітників, які могли б витрачати його на інші завдання.
3. При використанні власного центру сертифікації ви вставлятимете палиці в колеса вашим віддаленим співробітникам і колегам, які хочуть працювати з BYOD (приносять свої ноути, телефон, планшети) і ви не можете керувати їх пристроями. Вони приносять маки, лінукси, андройди, IOS, вінду – підтримувати такий зоопарк немає жодного сенсу.
У всьому, звичайно, є винятки, і банки з іншими суворими ентрпрайзами, які мають безпекові політики, вже ніколи не зможуть поліпшити сервіс для своїх співробітників.
Для них є платні центри сертифікації, які за певну суму можуть підписати їх CA сертифікат (гуглити root signing service).
Є й інші причини, чому публічний домен використовувати вигідніше (найголовніше, щоб він належав вам), але стаття не про це.
Суть, та річ…
УВАГА! Якщо ви додасте сертифікат CA від Let's Encrypt до списку довірених для ovirt'у, це може вплинути на безпеку ваших систем!
Перше на що треба звернути увагу - інтерфейси оверта виставляти в інтернет - це погана практика, тому що. в цьому немає практичного сенсу, а додаткові загрози безпеці створює.
Отже отримувати сертифікат необхідно на якомусь нашому бастіон-хості, після чого переносити сертифікат і ключ на наш хост з ovirt-engine.
Додаємо зовнішню адресу нашого бастіон-хоста в днс з нашим ім'ям овірта ovirtengine.example.com, встановлення certbot і nginx я залишу за кадром (як це зробити на хабрі вже описано).
Налаштовуємо нджинкс версії >=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;
}
}
Потім отримуємо наш сертифікат та ключ:
certbot certonly --nginx -d ovirtengine.example.com
Архівуємо наш сертифікат та ключ:
tar Phczf /tmp/ovirtengine.example.com.tgz /etc/letsencrypt/live/ovirtengine.example.com
Завантажуємо з бастіон-хоста архів, заливаємо на наш овірт-енжин:
scp bastion-host:/tmp/ovirtengine.example.com.tgz /tmp/
scp /tmp/ovirtengine.example.com.tgz ovirtengine.example.com:/
Переходимо до мети
Далі ми розпаковуємо наш архів і створюємо симлінки для спрощення розуміння системи розташування файлів:
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
Налаштовуємо вбудований pki в овірт, щоб для перевірки сертифікатів використовувалося сховище сертифікатів java(openjdk):
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
Конвертуємо CA від let's encrypt'а в der формат і додаємо в сховище сертифікатів java trust store оверта (це такий контейнер, в якому знаходиться перелік сертифікатів, така система використовується в 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
Редагуємо налаштування SSL для apache, додаємо параметр для підтримки симлінків та прибираємо параметр для CA, яким перевіряти сертифікати (за замовчуванням буде користуватися системний набір довірених CA для перевірки):
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
Після чого бекапуємо про всяк випадок оригінальні файли, згенеровані через PKI ovirt'а автоматичний і підмінюємо симлінками на файли від 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
Відновлюємо SElinux контексти на файлах та перезапускаємо наші сервіси (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 - веб-сервер апаш
ovirt-engine — веб-інтерфейс ovirt
ovirt-imageio-proxy - демон для завантаження образів дисків
ovirt-websocket-proxy — сервіс для роботи консолі noVNC
Все перераховане вище було перевірено на версії овірта 4.2.
Автооновлення сертифікатів на ovirt
Відповідно до добрих практик з безпеки, зв'язку між бастіон-хостом та овіртом бути не повинно, а сертифікат видається лише на 3 місяці. Ось тут з'являється спірний момент, як реалізовано оновлення сертифікатів у мене.
У мене є ансибл плейбук, який запускається на foreman щодня о 5 ранку за розкладом. Цей плейбук заходить на овірт, перевіряє термін дії сертифіката і якщо до закінчення залишилося менше 5 днів, йде на бастіон-хост та запускає оновлення сертифіката.
Після оновлення сертифіката він архівує папку з файлами, завантажує на хост форману та розархівує на хост овірта. Після чого відновлює SElinux контексти на файлах та перезапускаємо наші сервіси.
Джерело: habr.com
