ProHoster > Блог > Администриране > Как да свържем Ovirt и Let’s Encrypt

Как да свържем Ovirt и Let’s Encrypt

Като стъпвам по пътя на подобряване на инфраструктурата, реших да разреша стария и мъчителен въпрос — без излишни усилия да предоставя възможност на колегите (разработчици, тестери, администратори и т.н.) сами да управляват своите виртуални машини в ovirt. В ovirt има няколко компонента, които трябва да се настроят за решаването на моя въпрос: самият уеб интерфейс, noVNC конзолата и зареждането на образи на дискове.

Не намерих бутони „Направи го супер“, така че показвам какви ръчки крутех, за да реша тази задача. Пълната инструкция е под котката:

Как да интегрираме Ovirt и Let's Encrypt

ОТКАЗ:

Преди да започна, бих искал да обърна внимание, че по неизвестна за мен причина домейните на инфраструктурата се създават в частни зони lan, local и т.н.

Какво пречи да се използва домен на организацията в публична зона, не ми е известно. Например, вместо домейна Alex-GLuck-Awesome-Company.local, спокойно можем да използваме домейн за сайта на компанията Alex-GLuck-Awesome-Company.com.

Ако се страхувате, че не можете да следите домейните в своята организация и че това може да нещо да се счупи, то за скромните 100 лева на година можете да вземете отделен домен за инфраструктура ta aglac.com.

Защо е по-изгодно да се използват домейни в публични зони:

1. Вътре в организацията ви се появяват услуги, които излизат в публичното пространство: VPN, обмен на файлове (seafile, nextcloud) и други. Настройването на криптиране на трафика на такива услуги обикновено изглежда като хепи-енд, и защита от MitM не ще се извършва, защото е сложно (всъщност не е).

Или вътре в офиса имате един адрес на услугата, а от интернет друг, и тези връзки трябва да се поддържат, за което се харчат нашите ограничени ресурси на специалисти. Освен това на служителите им е неудобно да запомнят различни адреси.

2. Можете да използвате безплатни центрове за сертификация за криптиране на вашите вътрешни услуги.

Собствен PKI — това е услуга, която трябва да се поддържа, 100 лева на година за възможността да използвате PKI от безплатни сертификационни центрове с лихва покрива времето на служителите, които могат да го използват за други задачи.

3. При използване на собствен център за сертификация ще поставяте пречки на вашите дистанционни служители и колеги, които искат да работят с BYOD (носят свои лаптопи, телефони, таблети), и не можете да управлявате техните устройства. Те носят Mac, Linux, Android, iOS, Windows — поддържането на такъв зоопарк няма никакъв смисъл.

Разбира се, има изключения, и банки с други строги предприятия, които имат установени политики за сигурност, никога няма да могат да подобрят обслужването за своите служители.

Има платени центрове за сертификация, които срещу определена сума могат да подпишат техния CA сертификат (можете да търсите „root signing service“).

Има и други причини, поради които публичният домейн е по-изгоден (най-важното е, че той принадлежи на вас), но статията не е за това.

Същността е...

ВНИМАНИЕ! Ако добавите сертификат CA от Let’s Encrypt в списъка с доверени за ovirt, това може да повлияе на сигурността на вашите системи!

Първото, на което трябва да обърнете внимание — интерфейсите на ovirt да се излагат на интернет е лоша практика, тъй като в това няма никакъв практичен смисъл, а също така създава допълнителни заплахи за сигурността.

Следователно, сертификатът трябва да бъде получен на някой от нашите бастионни хостове, след което сертификатът и ключът да се прехвърлят на нашия хост с ovirt-engine.

Добавяме външния адрес на нашия бастион-хост в DNS с нашето име на ovirt. ovirtengine.example.com, инсталацията на certbot и nginx ще оставя настрана (как да го направите вече е описано в Хабра).

Настройваме nginx версия >=1.15.7

/etc/nginx/conf.d/default.conf

сървър {
    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_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

Свали архив от бастион хоста и го копирай на нашия ovirt-engine:

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 в ovirt, за да използва хранилището за сертификати 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

Конвертираме CA от Let's Encrypt в der формат и добавяме в хранилището за сертификати java trust store на ovirt (това е контейнер, в който се съхранява списъкът със сертификати, като тази система се използва в 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 — уеб сървър apache
ovirt-engine — уеб интерфейс на ovirt
ovirt-imageio-proxy — демон за зареждане на образи на дискове
ovirt-websocket-proxy — услуга за работа с noVNC конзолата

Всичко изброено дотук беше проверено на версии на ovirt 4.2.

Автообновление на сертификатите на ovirt

Според добрите практики за сигурност, връзката между бастионния хост и ovirt не трябва да съществува, а сертификатът се издава само за 3 месеца. Тук възниква спорен въпрос за начина, по който е реализирано обновлението на сертификатите при мен.

Имам ansible плейбук, който се изпълнява на foreman ежедневно в 5 сутринта по график. Този плейбук влиза в ovirt, проверява срока на валидност на сертификата и ако остава по-малко от 5 дни до изтичането му, отива на бастионния хост и стартира обновлението на сертификата.

След обновлението на сертификата архивира папката с файловете, изтегля на хоста на формана и разархивира на хоста на ovirt. След това възстановява контекстите на SElinux на файловете и рестартира нашите услуги.

Източник: habr.com

Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри 🔥 Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри | ProHoster