沿著改善基礎設施的道路走下去，我決定解決一個古老而痛苦的問題——無需不必要的手勢，為同事（開發人員、測試人員、管理員等）提供在ovirt中獨立管理他們的虛擬機的機會。 Ovirt 有幾個元件需要設定來解決我的問題：Web 介面本身、noVNC 控制台和上傳磁碟映像。
我沒有找到“讓它變得糟糕”按鈕，所以我向您展示了我使用哪些旋鈕來解決這個問題。完整說明如下：
免責聲明：
在開始之前，我想提請您注意這樣一個事實：由於某種我不知道的原因，基礎設施域是在私有區域 lan、local 等中創建的。
我不知道是什麼阻止我在公共區域中使用組織的網域。例如，您可以安全地使用公司網站 Alex-GLuck-Awesome-Company.com 的網域，而不是網域 Alex-GLuck-Awesome-Company.local。
如果您擔心無法追蹤組織中的網域，並且這會破壞某些內容，那麼您可以每年花費 100 盧布為 aglac.com 基礎設施購買一個單獨的網域。
為什麼在公共區域使用網域名稱更有利可圖：
1. 貴機構提供面向公眾的服務： 虛擬專用網例如檔案共享（Seafile、Nextcloud）等。在這些服務上設定流量加密通常比較草率，而且我們不會防禦中間人攻擊，因為這很困難（其實不然）。
或者您在辦公室內有一個服務地址，另一個來自互聯網，並且需要維護這些連接，這浪費了我們有限的專業資源。那麼，員工必須記住不同的地址，這很不方便。
2. 您可以使用免費的憑證授權單位來加密您的內部服務。
您自己的 PKI 是一項需要支援的服務；每年 100 盧布才能獲得使用免費認證機構提供的 PKI 的機會，這比員工可以將其花在其他任務上的時間還要多。
3. 當使用您自己的憑證授權單位時，您將為想要使用 BYOD（自備筆記型電腦、手機、平板電腦）的遠端員工和同事設定輻條，而您無法管理他們的裝置。他們帶來了 Mac、Linux、Android、iOS、Windows - 支持這樣的動物園是沒有意義的。
當然，凡事都有例外，銀行和其他制定了安全政策的苛刻企業永遠無法改善對其員工的服務。
對他們來說，有付費的憑證授權單位可以支付一定金額簽署他們的 CA 憑證（Google「根簽名服務」）。
使用公共領域更有利可圖的原因還有其他原因（最重要的是它屬於您），但本文與此無關。
重點是...
注意力！如果您將 Let's Encrypt CA 憑證新增至 ovirt 的受信任清單中，可能會影響您系統的安全！
您需要注意的第一件事是將 Ovirt 介面暴露到網路上是不好的做法，因為這沒有實際意義，並且會造成額外的安全威脅。
因此，您需要在我們的一個堡壘主機上取得證書，然後使用 ovirt-engine 將證書和密鑰傳輸到我們的主機。
我們將堡壘主機的外部位址加入到帶有 ovirt 名稱的 dns 中 ovirtengine.example.com，我將把 certbot 和 nginx 的安裝留在幕後（Habré 上已經描述瞭如何做到這一點）。
設定 njinx 版本 >=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
從堡壘主機下載檔案並將其上傳到我們的 ovirt 引擎：
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
我們在Ovirt中設定內建的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
我們將let's encrypt中的CA轉換為der格式，並將其新增至ovirt 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
我們編輯 apache 的 SSL 設置，添加一個參數以支援符號鏈接，並刪除用於檢查證書的 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
然後，為了以防萬一，我們備份透過 ovirt 自動 PKI 產生的原始文件，並將它們替換為來自 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 Web 介面
ovirt-imageio-proxy - 用於下載磁碟映像的守護進程
ovirt-websocket-proxy - 用於運行 noVNC 控制台的服務
以上所有內容均在 Ovirt 4.2 版本上進行了測試。
ovirt 上的憑證自動更新
根據良好的安全實踐，堡壘主機和ovirt之間不應有任何連接，並且證書僅頒發3個月。這就是我如何實施憑證更新的一個有爭議的問題。
我有一個 ansible 劇本，每天早上 5 點根據時間表在 foreman 上運行。該 playbook 會前往 ovirt，檢查憑證的有效期，如果距離到期時間還剩不到 5 天，則會前往堡壘主機並開始更新憑證。
更新憑證後，它將包含檔案的資料夾存檔，下載到 Forman 主機並將其解壓縮到 Ovirt 主機。之後 SElinux 恢復檔案的上下文並重新啟動我們的服務。
來源： www.habr.com
