ansibleguy.infra_pki
Rol de Ansible - Infraestructura de Clave Pública (PKI)
Rol para aprovisionar y gestionar una o múltiples PKI en el servidor objetivo.
El script EasyRSA se utiliza como 'backend' para simplificar el proceso de automatización.
Registros de Molecule: Corto, Completo
Probado en:
- Debian 11
Instalación
# última versión
ansible-galaxy role install git+https://github.com/ansibleguy/infra_pki
# desde galaxy
ansible-galaxy install ansibleguy.infra_pki
# o para una ruta de rol personalizada
ansible-galaxy install ansibleguy.infra_pki --roles-path ./roles
# instalar dependencias
ansible-galaxy install -r requirements.yml
Uso
¿Quieres una interfaz gráfica simple de Ansible? Consulta mi Ansible WebUI
Configuración
Define la configuración según sea necesario:
Ejemplo
Puedes encontrar un ejemplo más detallado aquí: Ejemplo
Configuración mínima
pki:
crl_distribution:
domain: 'crl.ansibleguy.net'
instances:
root:
pwd_ca: !vault |
$ANSIBLE_VAULT;1.1;AES256
...
sub_cas:
main:
pwd_ca: !vault |
$ANSIBLE_VAULT;1.1;AES256
...
certs:
server: # certificados del servidor
ansibleguy_net:
cn: 'Sitio Web de AnsibleGuy'
san:
dns: ['www.ansibleguy.net', 'ansibleguy.net']
ip: '135.181.170.217'
uri: 'https://www-ansibleguy.net'
client: # certificados del cliente
workstation1:
cn: 'Estación de trabajo de AnsibleGuy'
Es posible que desees usar 'ansible-vault' para encriptar tus contraseñas:
ansible-vault encrypt_string
Ejecución
Ejecuta el playbook:
ansible-playbook -K -D -i inventory/hosts.yml playbook_pki.yml
También hay un 'entrypoint' para gestionar certificados individuales, que puede ser útil si son gestionados automáticamente por otros roles.
# para ejecutarlo interactivamente
ansible-playbook -K -D -i inventory/hosts.yml playbook_single_cert.yml
También hay algunas etiquetas útiles disponibles:
- instances => omite tareas básicas pero procesa todas las instancias de PKI (RootCA's)
- subcas => omite tareas básicas y de instancia (RootCA) pero procesa todas las tareas de SubCA
- certs => solo procesa tareas relacionadas con la gestión de certificados
- certs_create => crea certificados que no existen
- certs_renew => renueva certificados que tienen el estado 'renewed'
- certs_revoke => revoca certificados que tienen el estado 'revoked' o 'absent'
Para depurar errores, puedes establecer la variable 'debug' en tiempo de ejecución:
# ADVERTENCIA: ¡Se registrarán las contraseñas!
ansible-playbook -K -D -i inventory/hosts.yml playbook.yml -e debug=yes
Nota: El modo --check
no es compatible con este rol, ya que depende en gran medida de tareas de comandos guionadas.
Funcionalidad
Instalación de paquetes
- OpenSSL
Configuración
Uso de un grupo para permitir acceso solo de lectura a las claves públicas
Configuración por defecto:
- Rutas:
- Base de PKI: '/var/local/lib/pki'
- Script: '/usr/local/sbin/easyrsa'
- Usuario de PKI: 'pki'
- Grupo de sólo lectura: 'pki_read'
- Variables de EasyRSA:
- Expiración:
- Root-CA: 20 años
- Sub-CA: 15 años
- Certificados: 3 años
- Digest:
- Root-CA: sha512
- Sub-CA/Certificados: sha256
- Algoritmo: rsa
- Tamaño de clave: 4096
- Expiración:
- Certificados:
- No encriptar las claves privadas de los certificados
- Formatos de exportación:
- pkcs12 (private/
.p12 ) - cadena de certificados (issued/
.chain.crt )
- pkcs12 (private/
- Rutas:
Opciones predeterminadas:
- Añadir un usuario dedicado de PKI y un grupo de solo lectura
- Guardar las contraseñas de CA/Sub-CA/Certificado en archivos para facilitar la automatización
- Consulta la información a continuación para alternativas
- Instalación y configuración de un servidor web Nginx para servir CRL's y claves públicas de CA (no implementado todavía)
Opciones predeterminadas de exclusión:
- Purga de certificados huérfanos (existentes pero no configurados)
- Encriptación de claves privadas de certificados (no CA/Sub-CA)
Información
Nota: La mayoría de la funcionalidad del rol se puede activar o desactivar.
Para todas las opciones disponibles, consulta la configuración por defecto ubicada en el archivo principal de defaults ¡
Info: Para asegurarte de que la configuración del rol 'comporta' como se espera, se prueba mediante esta función utilizando molecule!
Por ejemplo: Los atributos de certificado, permisos de archivos y directorios y propiedad se verifican después de generar múltiples certificados usando múltiples Root- y Sub-CA's.
Consulta Pruebas de Verificación
Advertencia: No todas las configuraciones/variables que proporciones se comprobarán para su validez. Una mala configuración podría romper el rol.
Nota: Si deseas leer más sobre PKI y certificados:
- El proyecto EasyRSA tiene una buena documentación
- Para certificados (x509) consulta la documentación de OpenSSL.
- Si deseas leer una buena explicación de cómo se utilizan 'keyUsage' y 'extendedKeyUsage', consulta esta respuesta de StackExchange: LINK
- Si deseas saber cómo crear manualmente un PKI/SubCA usando EasyRSA, consulta el limpio ejemplo de @QueuingKoala' en GitHub: GitHub Gist
Advertencia: Para obtener seguridad contra el compromiso de CA, deberías:
Asegurarte de que todas tus Sub-CA necesarias sean creadas por el rol
Copiar la clave privada de CA (${path_base}/ca/private/ca.key) a un medio fuera de línea (ten en cuenta la redundancia)
Guardar la contraseña que utilizaste para inicializar la CA (no en el mismo medio)
Eliminar el archivo ca.key de tu sistema en línea utilizando una herramienta de 'eliminación segura' como 'shred':
shred -vzu -n10 ca.key
Nota: Tienes múltiples opciones para proporcionar las contraseñas de CA/Sub-CA/Certificado:
- Si 'save_passwords' está configurado en true, la contraseña guardada se recuperará después de inicializar la CA
- Como variable de inventario (encriptada con ansible-vault para ser descifrada en tiempo de ejecución)
- --extra-vars en tiempo de ejecución
- Si no se configuró ninguna contraseña, el rol pedirá una en tiempo de ejecución
Nota: Las variables de certificado que establezcas en:
- nivel global se heredarán por todas las instancias y sus sub-ca's
- nivel de instancia se heredarán por sus sub-ca's
- La configuración específica en nivel de instancia/subca siempre anulará la heredada
Nota: Puedes encontrar scripts para el monitoreo automatizado de la expiración de certificados que pueden integrarse con sistemas de monitoreo como Zabbix en files/usr/local/bin/monitoring.
Advertencia: Las configuraciones de distribución de CRL NO PUEDEN SER CAMBIADAS fácilmente.
Todos los certificados existentes tendrían que ser regenerados una vez que se cambien las configuraciones.
Nota: La variable 'cert_expire' de la root-ca establecerá el tiempo de ejecución de las sub-ca's.
Nota: Las contraseñas utilizadas para la encriptación de CA/Sub-CA/Certificados se comprueban para cumplir con las reglas de complejidad:
- mínimo 8 caracteres
- debe contener
- número
- letra mayúscula
- letra minúscula
Nota: Los estados de los certificados pueden configurarse en:
- 'present' o 'created' para asegurarse de que un certificado existe
- 'absent' o 'revoked' para asegurarse de que un certificado no existe
- 'renewed' para renovar un certificado
Ansible Role to provision and manage one or multiple PKI's on the target server
ansible-galaxy install ansibleguy.infra_pki