Caminando por el camino de mejorar la infraestructura, decidí terminar la antigua y dolorosa pregunta: sin gestos innecesarios, brindar a colegas (desarrolladores, evaluadores, administradores, etc.) la oportunidad de administrar sus máquinas virtuales de manera independiente en primer lugar. Hay varios componentes que necesito configurar para resolver mi pregunta: la interfaz web en sí, la consola noVNC y el llenado de imágenes de disco.
No encontré los botones "Hacer parpadeo", así que muestro qué bolígrafos utilicé para resolver este problema. Instrucciones completas debajo del corte:
Descargo de responsabilidad:
Antes de comenzar, me gustaría llamar la atención sobre el hecho de que, por alguna razón desconocida para mí, los dominios de infraestructura se crean en zonas privadas lan, locales, etc.
Lo que me impide usar el dominio de la organización en la zona pública es desconocido para mí. Por ejemplo, en lugar del dominio Alex-GLuck-Awesome-Company.local, puede usar el dominio de forma segura para el sitio de la compañía Alex-GLuck-Awesome-Company.com.
Si tiene miedo de no poder realizar un seguimiento de los dominios en su organización, y esto romperá algo, entonces, por unos modestos 100 rublos al año, puede tomar un dominio separado para la infraestructura de aglac.com.
Por qué es más rentable usar dominios en zonas públicas:
1. Servicios que aparecen en su espacio público dentro de su organización: VPN, uso compartido de archivos (seafile, nextcloud) y otros. La configuración del cifrado de tráfico en dichos servicios generalmente parece un error, y no nos protegeremos de MitM, porque es difícil (en realidad no).
O dentro de la oficina tiene una dirección de servicio y otra de Internet, y estas comunicaciones deben mantenerse, en las que se gastan nuestros recursos especializados limitados. Bueno, los empleados tienen que recordar diferentes direcciones, lo cual es inconveniente.
2. Puede utilizar autoridades de certificación gratuitas para cifrar sus servicios internos.
Own PKI es un servicio que necesita soporte, 100 rublos al año para la oportunidad de usar PKI de las autoridades de certificación gratuitas más que pagar por el tiempo de los empleados que podrían gastarlo en otras tareas.
3. Cuando use su propia autoridad de certificación, colocará palos en las ruedas de sus empleados y colegas remotos que quieran trabajar con BYOD (traiga sus computadoras portátiles, teléfonos, tabletas) y no podrá controlar sus dispositivos. Traen amapolas, Linux, androides, iOS, Windows: no tiene sentido apoyar ese zoológico.
En general, por supuesto, hay excepciones, y los bancos con otras empresas severas que han establecido políticas de seguridad nunca podrán mejorar el servicio para sus empleados.
Hay autoridades de certificación pagadas para ellos, que por una cierta cantidad pueden firmar su certificado de CA ("servicio de firma raíz" de Google).
Hay otras razones por las que es más rentable usar un dominio público (lo más importante es que te pertenece), pero el artículo no trata sobre eso.
La conclusión, pero el punto ...
ATENCION! Si agrega un certificado de CA de Let's Encrypt a la lista de confianza de ovirt, ¡esto puede afectar la seguridad de sus sistemas!Lo primero a lo que debe prestar atención es que poner la interfaz de Internet en Internet es una mala práctica, porque Esto no tiene ningún sentido práctico y crea amenazas de seguridad adicionales.
Por lo tanto, debe obtener un certificado en algunos de nuestros hosts de bastión y luego transferir el certificado y la clave a nuestro host con ovirt-engine.
Agregamos la dirección externa de nuestro servidor de bastión en el DNS con nuestro nombre
ovirtengine.example.com , dejaré la instalación de certbot y nginx detrás de escena (ya se ha descrito cómo hacerlo en el hub).
Configuración de la versión de 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; } }
Luego obtenemos nuestro certificado y clave:
certbot certonly --nginx -d ovirtengine.example.com
Archivamos nuestro certificado y clave:
tar Phczf /tmp/ovirtengine.example.com.tgz /etc/letsencrypt/live/ovirtengine.example.com
Descargue el archivo del servidor bastión, cárguelo en nuestro ovirt-enzhin:
scp bastion-host:/tmp/ovirtengine.example.com.tgz /tmp/ scp /tmp/ovirtengine.example.com.tgz ovirtengine.example.com:/
Ir a la meta
A continuación, desempaquetamos nuestro archivo y creamos enlaces simbólicos para simplificar la comprensión del sistema de ubicación de archivos:
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 el pki incorporado en la pantalla para usar el almacén de certificados de Java (OpenJDK) para la verificación del 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
Convertimos CA de vamos a encriptar a formato der y agregamos un ovirt al almacén de certificados del almacén de confianza de Java (este es un contenedor que contiene la lista de certificados, tal sistema se usa en 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 la configuración SSL para apache, agregamos el parámetro para admitir enlaces simbólicos y eliminamos el parámetro para CA, que verificará los certificados (de forma predeterminada, el sistema usará el conjunto de CA confiable para la verificación):
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
Después de eso, por si acaso, haremos una copia de seguridad de los archivos originales generados a través de PKI ovirt'a automáticamente y reemplazaremos los enlaces simbólicos con archivos de 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 en archivos y reiniciamos nuestros servicios (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 - interfaz web ovirt
ovirt-imageio-proxy - demonio para cargar imágenes de disco
ovirt-websocket-proxy - servicio para ejecutar la consola noVNC
Todo lo anterior ha sido probado en la versión 4.2 del ovirt.
Auto renovar certificados para ovirt
De acuerdo con las buenas prácticas de seguridad, no debe haber una conexión entre el servidor del bastión y el servidor, y el certificado se emite solo por 3 meses. Aquí es donde aparece un punto controvertido sobre cómo he implementado la renovación del certificado.
Tengo un libro de jugadas de conjunto que se ejecuta en foreman todos los días a las 5 a.m.en un horario. Este libro de jugadas entra en vigencia, verifica el período de validez del certificado y si quedan menos de 5 días antes de la fecha de vencimiento, va al host del bastión e inicia la renovación del certificado.
Después de actualizar el certificado, archiva la carpeta con los archivos, descarga el host de forma y descomprime el host original en el host. Luego restaura los contextos de SElinux en los archivos y reinicia nuestros servicios.