Caminhando pelo caminho da melhoria da infraestrutura, resolvi encerrar uma questão antiga e dolorosa - sem gestos desnecessários, dar aos colegas (desenvolvedores, testadores, administradores, etc) a oportunidade de gerenciar de forma independente suas máquinas virtuais em ovirt. Ovirt possui vários componentes que precisam ser configurados para resolver meu problema: a própria interface web, o console noVNC e o upload de imagens de disco.
Não encontrei o botão “Make It Bad”, então estou mostrando quais botões girei para resolver esse problema. Instruções completas abaixo do corte:

AVISO LEGAL:
Antes de começar, gostaria de chamar a atenção para o fato de que, por algum motivo que desconheço, os domínios de infraestrutura são criados em zonas privadas lan, locais e assim por diante.
Não sei o que me impede de usar o domínio de uma organização em uma zona pública. Por exemplo, em vez do domínio Alex-GLuck-Awesome-Company.local, você pode usar com segurança o domínio do site da empresa Alex-GLuck-Awesome-Company.com.
Se você tem medo de não conseguir monitorar os domínios em sua organização e isso quebrar alguma coisa, então, por modestos 100 rublos por ano, você pode comprar um domínio separado para a infraestrutura aglac.com.
Por que é mais lucrativo usar domínios em zonas públicas:
1. Sua organização possui serviços que são acessíveis ao público: vpn, compartilhamento de arquivos (Seafile, Nextcloud) e outros. Configurar a criptografia de tráfego nesses serviços geralmente é um processo improvisado, e não nos defenderemos contra ataques Man-in-the-Middle porque é difícil (na verdade, não).
Ou você tem um endereço de serviço dentro do escritório e outro na Internet, e essas conexões precisam ser mantidas, o que desperdiça nossos limitados recursos especializados. Pois bem, os funcionários têm que lembrar endereços diferentes, o que é inconveniente.
2. Você pode usar autoridades de certificação gratuitas para criptografar seus serviços internos.
Sua própria PKI é um serviço que precisa de suporte; 100 rublos por ano pela oportunidade de usar a PKI de autoridades de certificação gratuitas mais do que compensam o tempo dos funcionários que poderiam gastá-lo em outras tarefas.
3. Ao usar sua própria autoridade de certificação, você prejudicará seus funcionários e colegas remotos que desejam trabalhar com BYOD (traga seus próprios laptops, telefones, tablets) e não poderá gerenciar seus dispositivos. Eles trazem Macs, Linux, Androids, iOS, Windows - não faz sentido apoiar um zoológico assim.
Em tudo, claro, há excepções, e os bancos com outras empresas severas que estabeleceram políticas de segurança nunca serão capazes de melhorar o serviço aos seus funcionários.
Para eles, existem autoridades de certificação pagas que podem assinar seu certificado CA por um determinado valor (Google “serviço de assinatura raiz”).
Existem outras razões pelas quais é mais lucrativo usar o domínio público (o mais importante é que ele pertença a você), mas este artigo não é sobre isso.
A questão é...
ATENÇÃO! Se você adicionar um certificado Let's Encrypt CA à lista confiável do ovirt, isso poderá afetar a segurança dos seus sistemas!
A primeira coisa que você precisa prestar atenção é que expor as interfaces do Ovirt à Internet é uma má prática, porque Isto não faz sentido prático e cria ameaças adicionais à segurança.
Portanto, você precisa obter um certificado em um de nossos hosts bastiões e, em seguida, transferir o certificado e a chave para nosso host com ovirt-engine.
Adicionamos o endereço externo do nosso host bastião ao DNS com nosso nome ovirt ovirtengine.exemplo.com, deixarei a instalação do certbot e do nginx nos bastidores (como fazer isso já está descrito no Habré).
Configurando a versão 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;
}
}
Então obtemos nosso certificado e chave:
certbot certonly --nginx -d ovirtengine.example.com
Arquive nosso certificado e chave:
tar Phczf /tmp/ovirtengine.example.com.tgz /etc/letsencrypt/live/ovirtengine.example.com
Baixe o arquivo do bastion host e carregue-o em nosso mecanismo ovirt:
scp bastion-host:/tmp/ovirtengine.example.com.tgz /tmp/
scp /tmp/ovirtengine.example.com.tgz ovirtengine.example.com:/
Vamos passar para o objetivo
A seguir, descompactamos nosso arquivo e criamos links simbólicos para simplificar a compreensão do sistema de localização de arquivos:
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
Configuramos o pki integrado no Ovirt para que o armazenamento de certificados java (openjdk) seja usado para verificar certificados:
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
Convertemos a CA do formato let's encrypt para o formato der e a adicionamos ao armazenamento de certificados ovirt java trust store (este é um contêiner que contém uma lista de certificados, tal sistema é usado em 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
Editamos as configurações SSL do Apache, adicionamos um parâmetro para suportar links simbólicos e removemos o parâmetro da CA com a qual verificar os certificados (por padrão, o conjunto de CAs confiáveis do sistema será usado para verificação):
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
Então, por precaução, fazemos backup dos arquivos originais gerados por meio da PKI automática do ovirt e os substituímos por links simbólicos com arquivos do 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
Restauramos contextos SElinux nos arquivos e reiniciamos nossos serviços (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 — véspera de ano novo apache
ovirt-engine - interface web ovirt
ovirt-imageio-proxy - daemon para baixar imagens de disco
ovirt-websocket-proxy – serviço para executar o console noVNC
Todos os itens acima foram testados no Ovirt versão 4.2.
Renovação automática de certificados no ovirt
De acordo com as boas práticas de segurança, não deve haver ligação entre o bastion host e o ovirt, e o certificado é emitido apenas por 3 meses. É aqui que surge uma questão controversa sobre como implementei a renovação de certificados.
Eu tenho um manual ansible que funciona no Foreman todos os dias às 5 da manhã, de acordo com um cronograma. Este playbook vai para o ovirt, verifica o período de validade do certificado e, se faltarem menos de 5 dias para a expiração, ele vai para o bastion host e inicia a atualização do certificado.
Após atualizar o certificado, ele arquiva a pasta com os arquivos, baixa-os no host Forman e descompacta-os no host Ovirt. Depois disso, o SElinux restaura os contextos dos arquivos e reinicia nossos serviços.
Fonte: habr.com
