Seguindo o caminho de melhorar a infraestrutura, decidi encerrar a pergunta antiga e dolorosa - sem gestos extras, oferecer a oportunidade para colegas (desenvolvedores, testadores, administradores, etc.) gerenciarem independentemente suas máquinas virtuais em tempo real. Existem vários componentes em andamento que eu preciso configurar para resolver minha pergunta: a própria interface da web, o console noVNC e o preenchimento de imagens de disco.
Não encontrei os botões "Make Flicker", então mostro quais canetas girei para resolver esse problema. Instruções completas sob o corte:
AVISO LEGAL:
Antes de começar, gostaria de chamar a atenção para o fato de que, por algum motivo desconhecido para mim, os domínios de infraestrutura são criados em zonas privadas lan, local e assim por diante.
O que me impede de usar o domínio da organização na zona pública é desconhecido para mim. Por exemplo, em vez do domínio Alex-GLuck-Awesome-Company.local, você pode usar com segurança o domínio para o site da empresa Alex-GLuck-Awesome-Company.com.
Se você tem medo de não conseguir acompanhar os domínios da sua organização, e isso vai quebrar alguma coisa, por modestos 100 rublos por ano, você pode usar um domínio separado para a infraestrutura do aglac.com.
Por que é mais lucrativo usar domínios em zonas públicas:
1. Serviços que aparecem no seu espaço público dentro da sua organização: VPN, compartilhamento de arquivos (seafile, nextcloud) e outros. A configuração da criptografia de tráfego nesses serviços geralmente parece um erro de gravação e não nos protegeremos do MitM, porque é difícil (na verdade não é).
Ou dentro do escritório, você tem um endereço de serviço e outro da Internet, e essas comunicações devem ser mantidas, nas quais nossos recursos especializados limitados são gastos. Bem, os funcionários precisam se lembrar de endereços diferentes, o que é inconveniente.
2. Você pode usar autoridades de certificação gratuitas para criptografar seus serviços internos.
O Own PKI é um serviço que precisa ser suportado, 100 rublos por ano, para a oportunidade de usar o PKI de autoridades de certificação gratuitas mais do que pagar pelo tempo dos funcionários que poderiam gastá-lo em outras tarefas.
3. Ao usar sua própria autoridade de certificação, você colocará palitos nas rodas de seus funcionários e colegas remotos que desejam trabalhar com o BYOD (traga seus laptops, telefones, tablets) e você não poderá controlar seus dispositivos. Eles trazem papoulas, Linux, andróides, iOS, Windows - não há sentido em apoiar esse zoológico.
No total, é claro, há exceções e os bancos com outras empresas duras que estabeleceram políticas de segurança nunca poderão melhorar o serviço para seus funcionários.
Existem autoridades de certificação pagas para eles, que, por um determinado valor, podem assinar seus certificados de CA (google "serviço de assinatura raiz").
Há outras razões pelas quais é mais lucrativo usar um domínio público (a coisa mais importante é que ele pertence a você), mas o artigo não é sobre isso.
A linha inferior, mas o ponto ...
ATENÇÃO! Se você adicionar um certificado CA de Let's Encrypt à lista confiável do usuário, isso poderá afetar a segurança dos seus sistemas!A primeira coisa que você precisa prestar atenção é que colocar a interface da Internet na Internet é uma prática ruim, porque isso não faz sentido prático e cria ameaças adicionais à segurança.
Portanto, você precisa obter um certificado em alguns dos nossos hosts bastiões e, em seguida, transferir o certificado e a chave para o nosso host com mecanismo de ovirt.
Se adicionarmos o endereço externo de nosso host bastião no DNS com o nome ovirtengine.example.com
ovirt , deixarei a instalação do certbot e do nginx nos bastidores (como fazer isso no hub já foi descrito).
Configurando a versão do Nginx> = 1.15.7
/etc/nginx/conf.d/default.confserver { 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; } }
Em seguida, obtemos nosso certificado e chave:
certbot certonly --nginx -d ovirtengine.example.com
Arquivamos nosso certificado e chave:
tar Phczf /tmp/ovirtengine.example.com.tgz /etc/letsencrypt/live/ovirtengine.example.com
Faça o download do arquivo do host bastião, faça o upload para nosso ovirt-enzhin:
scp bastion-host:/tmp/ovirtengine.example.com.tgz /tmp/ scp /tmp/ovirtengine.example.com.tgz ovirtengine.example.com:/
Vá para a meta
Em seguida, descompactamos nosso arquivo e criamos links simbólicos para simplificar o entendimento 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 interno no ovirt para usar o armazenamento de certificados java (openjdk) para verificação de certificado:
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 de vamos criptografar para o formato der e adicionamos um ovirt ao armazenamento de certificados do armazenamento confiável java (esse é um contêiner em que a lista de certificados está localizada, um 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 o parâmetro para oferecer suporte a links simbólicos e removemos o parâmetro da CA, que verificará os certificados (por padrão, o sistema usará a CA confiável configurada para verificação):
sed -r -i 's|^(SSLCACertificateFile.*)|#\1|g' /etc/httpd/conf.d/ssl.conf sed -r -i '0,/(^#?SSLCACertificateFile.*)/ s//\1\nOptions FollowSymlinks/' /etc/httpd/conf.d/ssl.conf
Depois disso, por precaução, faremos o backup dos arquivos originais gerados através da PKI ovirt'a automaticamente e substituiremos os links simbólicos pelos 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 os contextos do 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 - servidor web apache
ovirt-engine - interface da web ovirt
ovirt-imageio-proxy - daemon para carregar imagens de disco
ovirt-websocket-proxy - serviço para executar o console noVNC
Todos os itens acima foram testados na versão 4.2 do ovirt.
Renovar automaticamente certificados para ovirt
De acordo com as boas práticas de segurança, não deve haver uma conexão entre o host do bastião e o ovirt, e o certificado é emitido apenas por 3 meses. É aqui que um ponto controverso aparece sobre como eu implementei a renovação de certificado.
Eu tenho um manual do conjunto que é executado no capataz diariamente às 5 da manhã em um horário. Este manual entra em vigor, verifica o período de validade do certificado e, se restarem menos de 5 dias antes da expiração, ele acessa o host do bastião e inicia a renovação do certificado.
Depois de atualizar o certificado, ele arquiva a pasta com os arquivos, baixa o forman para o host e descompacta o host anterior. Em seguida, restaura os contextos do SElinux nos arquivos e reinicia os nossos serviços.