authentication) dentro de cada pod de Ayakaleaf Pro. A diferencia de OIDC y SAML, los pods se comunican directamente con el directorio. Configura la parte del directorio como se indica en Autenticación LDAP y, después, introduce los valores en Kubernetes como se explica a continuación.
Dónde se ejecuta cada cosa
Configuración
1
Permite que los pods lleguen al directorio
Cada pod que ejecuta Ayakaleaf Pro abre las conexiones LDAP. Si un firewall o una NetworkPolicy protege el directorio, permite las direcciones con las que los pods salen del clúster: normalmente las direcciones de los nodos o tu pasarela de salida (egress gateway).La imagen no incluye Debe mostrar exactamente un
ldapsearch. Para ejecutar la comprobación de búsqueda desde dentro del clúster, usa un pod desechable:dn:.2
Añade los ajustes al ConfigMap
30-config.yaml (additions)
OVERLEAF_LDAP_* se enumeran en Variables de entorno. Todos van en el ConfigMap excepto la contraseña de bind. Pon entre comillas "true", "false", los valores JSON como OVERLEAF_LDAP_SEARCH_ATTRIBUTES: '["mail", "cn"]' y los valores que empiezan por *.3
Guarda la contraseña de bind en el Secret
4
LDAPS o STARTTLS con tu propia CA (opcional)
Guarda la CA en el Secret La lista de CA sustituye a las CA del sistema para las conexiones LDAP. Se lee cuando web arranca.
overleaf-certs montado en /var/lib/overleaf/certs (consulta Certificados y otros archivos) y apunta a ella:5
Aplica y reinicia
Varias réplicas
No hace falta nada más aparte del firewall del paso 1: cada réplica se conecta al directorio por su cuenta, y el resultado del inicio de sesión se guarda en la sesión en Redis.Probado en Kubernetes
Con el outpost LDAP de goauthentik como directorio, en Kubernetes 1.37 con tres réplicas detrás de HAProxy, nuestras pruebas de extremo a extremo para LDAP se superan (26 casos): el primer administrador creado desde el launchpad iniciando sesión mediante LDAP, el inicio de sesión con la contraseña de bind del Secret, el rechazo de contraseñas incorrectas y usuarios desconocidos, la asignación de administrador por grupo y sin asignación, el nombre y el indicador de administrador actualizados en cada inicio de sesión (un atributo de nombre, o nombre y apellidos), los contactos del directorio, el cierre de sesión, las reglas de contraseña para cuentas LDAP, las cuentas suspendidas y el inicio de sesión LDAP con reCAPTCHA.Preguntas y respuestas
El inicio de sesión LDAP falla solo en algunos pods
El inicio de sesión LDAP falla solo en algunos pods
Respuesta: El directorio no es accesible desde todos los nodos. Compruébalo desde cada pod:
¿Dónde veo por qué ha fallado un inicio de sesión?
¿Dónde veo por qué ha fallado un inicio de sesión?
Respuesta: En el log de web del pod que atendió el inicio de sesión:

