Podążając ścieżką ulepszania infrastruktury, postanowiłem dokończyć stare i bolesne pytanie - zapewnić współpracownikom (programistom, testerom, administratorom itp.) możliwość samodzielnego zarządzania swoimi maszynami wirtualnymi w ovirt, bez zbędnego zamieszania. Aby rozwiązać mój problem, należy skonfigurować kilka komponentów ovirt: sam interfejs sieciowy, konsolę noVNC i ładowanie obrazów dysków.
Nie znalazłem przycisku „Make it Awesome”, więc pokażę ci, które pokrętła wykorzystałem, aby rozwiązać ten problem. Pełne instrukcje poniżej:
OŚWIADCZENIE:
Zanim zaczniemy, chciałbym zaznaczyć, że z jakiegoś nieznanego mi powodu domeny infrastrukturalne są tworzone w prywatnych strefach LAN, lokalnych i tak dalej.
Nie wiem, co uniemożliwia korzystanie z domeny organizacji w strefie publicznej. Na przykład zamiast domeny Alex-GLuck-Awesome-Company.local możesz śmiało używać domeny dla strony internetowej firmy Alex-GLuck-Awesome-Company.com.
Jeśli obawiasz się, że nie będziesz w stanie kontrolować domen w swojej organizacji i przez to coś się zepsuje, to za skromne 100 rubli rocznie możesz wziąć oddzielną domenę dla infrastruktury aglac.com.
Dlaczego korzystanie z domen w strefach publicznych jest bardziej opłacalne:
1. Twoja organizacja oferuje usługi, które są publicznie dostępne: VPN, udostępnianie plików (Seafile, NextCloud) i inne. Konfiguracja szyfrowania ruchu w takich usługach to zazwyczaj dość niedbała robota i nie będziemy bronić się przed atakami typu MitM, ponieważ jest to trudne (nie do końca).
Albo w biurze masz jeden adres świadczenia usług, a przez Internet inny, a połączenia te trzeba utrzymywać, co marnuje nasze ograniczone zasoby specjalistyczne. Cóż, pracownicy muszą pamiętać różne adresy, co jest niewygodne.
2. Możesz użyć bezpłatnych urzędów certyfikacji do zaszyfrowania swoich wewnętrznych usług.
Własna infrastruktura PKI jest usługą, która wymaga wsparcia; 100 rubli rocznie za możliwość korzystania z PKI w bezpłatnych centrach certyfikacji to wydatek przewyższający wynagrodzenie za czas pracowników, którzy mogliby go poświęcić na inne zadania.
3. Korzystając z własnego centrum certyfikacji, utrudniasz pracę zdalnym pracownikom i współpracownikom, którzy chcą pracować w modelu BYOD (przynoszą własne laptopy, telefony, tablety), a Ty nie możesz zarządzać ich urządzeniami. Przywożą komputery Mac, Linux, Android, iOS, Windows - nie ma sensu wspierać takiego zoo.
Oczywiście, od każdej reguły są wyjątki, a banki i inne przedsiębiorstwa, które opracowały zasady bezpieczeństwa, nigdy nie będą w stanie poprawić jakości usług świadczonych swoim pracownikom.
Istnieją płatne centra certyfikacji, które mogą podpisać ich certyfikat CA za określoną kwotę (wpisz w wyszukiwarce „root signing service”).
Istnieją również inne powody, dla których korzystanie z domeny publicznej jest bardziej opłacalne (najważniejszy jest fakt, że należy ona do Ciebie), ale ten artykuł nie jest o tym.
Chodzi o to, że...
UWAGA! Jeśli dodasz certyfikat CA Let's Encrypt do zaufanej listy ovirt, może to wpłynąć na bezpieczeństwo Twoich systemów!
Pierwszą rzeczą, na którą należy zwrócić uwagę, jest to, że publikowanie interfejsów OVR w Internecie to zła praktyka, ponieważ nie ma to żadnego praktycznego sensu, a ponadto stwarza dodatkowe zagrożenia bezpieczeństwa.
Dlatego konieczne jest uzyskanie certyfikatu na jednym z naszych hostów bastionowych, a następnie przesłanie certyfikatu i klucza na nasz host za pomocą ovirt-engine.
Dodaj zewnętrzny adres naszego hosta bastionowego do DNS z naszą nazwą ovirta ovirtengine.example.comInstalację certbot i nginx pozostawię w tle (jak to zrobić zostało już opisane na Habr).
Konfigurowanie wersji 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;
}
}
Następnie pobieramy nasz certyfikat i klucz:
certbot certonly --nginx -d ovirtengine.example.com
Archiwizujemy nasz certyfikat i klucz:
tar Phczf /tmp/ovirtengine.example.com.tgz /etc/letsencrypt/live/ovirtengine.example.com
Pobierz archiwum z hosta bastionu i prześlij je do naszego jawnego silnika:
scp bastion-host:/tmp/ovirtengine.example.com.tgz /tmp/
scp /tmp/ovirtengine.example.com.tgz ovirtengine.example.com:/
Przejdźmy do celu
Następnie rozpakowujemy nasze archiwum i tworzymy dowiązania symboliczne, aby łatwiej było zrozumieć system lokalizacji plików:
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
Konfigurujemy wbudowany plik pki w ovirt tak, aby do sprawdzania certyfikatów był używany magazyn certyfikatów 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
Konwertujemy CA z formatu let's encrypt do formatu der i dodajemy go do zaufanego magazynu certyfikatów Java ovirta (jest to kontener zawierający listę certyfikatów; taki system jest używany w Javie):
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
Edytujemy ustawienia SSL dla Apache, dodajemy parametr obsługujący dowiązania symboliczne i usuwamy parametr dla urzędu certyfikacji, który będzie sprawdzał certyfikaty (domyślnie do sprawdzania będzie używany systemowy zestaw zaufanych urzędów certyfikacji):
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
Następnie, na wszelki wypadek, wykonujemy kopię zapasową oryginalnych plików wygenerowanych za pomocą automatycznej infrastruktury kluczy publicznych (PKI) programu ovirt i zastępujemy je dowiązaniami symbolicznymi do plików 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
Przywracamy konteksty SElinux dla plików i ponownie uruchamiamy nasze usługi (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 - interfejs sieciowy ovirt
ovirt-imageio-proxy — demon do pobierania obrazów dysków
ovirt-websocket-proxy — usługa do obsługi konsoli noVNC
Wszystkie powyższe rozwiązania zostały przetestowane na wersji ovirta 4.2.
Automatyczna aktualizacja certyfikatów na ovirt
Zgodnie z dobrymi praktykami bezpieczeństwa, nie powinna istnieć żadna komunikacja między hostem bastionowym a serwerem źródłowym, a certyfikat jest wydawany tylko na 3 miesiące. W tym miejscu pojawia się kontrowersyjna kwestia dotycząca sposobu wdrażania odnowienia certyfikatu w moim przypadku.
Mam podręcznik Ansible, który uruchamia się na komputerze Foreman codziennie o 5 rano zgodnie z harmonogramem. Ten podręcznik trafia do ovirt, sprawdza datę ważności certyfikatu i jeśli do upływu terminu pozostało mniej niż 5 dni, trafia do hosta bastionu i rozpoczyna aktualizację certyfikatu.
Po zaktualizowaniu certyfikatu archiwizuje folder z plikami, pobiera go na hosta forman i rozpakowuje na hoście ovirt. Następnie SElinux przywróci konteksty plików i ponownie uruchomi nasze usługi.
Źródło: www.habr.com
