Seguridad
Resumen de Seguridad de GBDS
GBDS posee un módulo de seguridad que utiliza tokens JWT para realizar autenticación y autorización de usuarios. GBDS puede integrarse con cualquier directorio de usuarios compatible con LDAP para la autenticación, y con Apache Ranger para proporcionar auditoría de autorización y acceso.
Componentes
Hay cuatro componentes principales que trabajan juntos para proporcionar seguridad a las operaciones de GBDS: Módulo de Seguridad del API, Ranger, Solr y el Almacenamiento de Credenciales LDAP.
Módulo de Seguridad del API
Todas las solicitudes a la API pasan primero por el módulo de seguridad, que aplica autenticación y autorización para recursos protegidos.
Almacenamiento de Credenciales LDAP
Una instancia LDAP (como Active Directory, OpenLDAP) mantiene información sobre usuarios y grupos de usuarios, y proporciona autenticación para acceder a la API de GBDS y autorizar las transacciones de la API.
Ranger
Apache Ranger es un framework de seguridad que proporciona un control de acceso fino a la API de GBDS. Se pueden crear políticas de seguridad para bloquear o permitir accesos a los endpoints de la API basadas en criterios como grupo de usuario, nombre de usuario, recursos solicitados, métodos HTTP usados y dirección IP.
Solr
GBDS usa Solr para almacenar registros de acceso de todas las solicitudes a la API; a través del panel de control de Ranger, estos registros pueden verse, buscarse y exportarse.
Flujos de Trabajo Habilitados para Seguridad
Autenticación
Hay dos métodos para autenticarse con la API. Cuando el cliente no posee un token válido, debe usarse autenticación por credenciales. En este caso, el cliente realiza una petición al endpoint de creación de token, enviando un payload JSON con las credenciales válidas para un usuario registrado en LDAP. A continuación, el Módulo de Seguridad crea un vínculo con el directorio LDAP, usando las credenciales del usuario de vinculación (Bind User, vea más abajo), y realiza la autenticación. Luego, crea un Sujeto Autenticado: un usuario asociado con todos los grupos a los que pertenece. Finalmente, el Módulo de Seguridad construye un token JWT, lo firma digitalmente y lo devuelve al cliente. Este token puede usarse para realizar solicitudes posteriores a la API de GBDS.
Cuando el cliente ya tiene un token válido, pero próximo a expirar, es posible usar ese token para crear uno nuevo con un tiempo de expiración posterior. Primero el cliente hace una solicitud al endpoint de creación de token con el token válido. El Módulo de Seguridad validará el token y creará uno nuevo, usando el mismo Sujeto Autenticado, pero con un nuevo expirationTime. El nuevo token será enviado al usuario. Como este flujo no requiere consultar el directorio LDAP, es mucho más rápido. Las aplicaciones cliente deben diseñarse para usar la renovación de token siempre que sea posible.
Realizando una Solicitud de API
Cuando se adquiere un token JWT válido, se envía a la API de GBDS con cada solicitud, siguiendo el estándar JWT. La solicitud tendrá un encabezado de autorización con el esquema Bearer, es decir, Authorization: Bearer <token>. Para recursos protegidos, el Módulo de Seguridad extraerá el token del encabezado y validará su firma usando la Clave de Firma original. Si el token es válido, la solicitud queda autenticada. A continuación, el Módulo de Seguridad construirá un AuthorizationContext con el nombre del sujeto, grupo del sujeto, recursos de la solicitud, dirección IP y método HTTP. Este AuthorizationContext será enviado a Ranger para autorizar o denegar la solicitud y será registrado por Solr, junto con sus resultados: Permitido o Denegado. Finalmente, si la solicitud es autorizada, será encaminada a la API de GBDS para su procesamiento.
Configuraciones
Archivos
El módulo de seguridad utiliza cuatro archivos de configuración diferentes:
/etc/griaule/conf/gbscluster.properties: Archivo primario de configuración de GBDS. Cuando la seguridad está activa, las opciones de seguridad se configuran en este archivo./etc/griaule/conf/gbsapi/keystore.jks: Keystore protegido por contraseña que contiene la Ldap Bind User Password y JWT Signing Key. Solo accesible por el usuario griaule./etc/griaule/conf/gbsapi/truststore: Truststore protegido por contraseña que contiene la Ldap Server Certificate para permitir conexiones LDAP. Solo accesible por el usuario griaule./etc/griaule/conf/gbsapi/.password: Archivo de contraseñas que contiene las contraseñas de keystore y truststore. Las contraseñas se almacenan en texto claro, y solo deberían ser accesibles por el usuario griaule.
Opciones de Seguridad
GBDS puede funcionar con o sin la seguridad activada, y esto se controla mediante la clave de configuración booleana: gbscluster.api.security.enabled. Cuando esta clave está definida como false, toda la seguridad queda deshabilitada y todas las demás claves de seguridad se ignoran. Si está definida como true, las siguientes claves de configuración DEBEN también deberán configurarse:
Generales
gbscluster.api.security.keystore: ruta al keystore generado a partir del script de generación del keystoregbscluster.api.security.truststore: ruta al truststore que contiene el certificado del servidor LDAP. Requerido para usar LDAPS.gbscluster.api.security.passwords: ruta al archivo que contiene las contraseñas del truststore y keystore. Este archivo debe tener acceso restringido al usuario griaule.
Autenticación
gbscluster.api.security.ldap.url: URL de conexión al servidor de almacenamiento de usuarios LDAP.gbscluster.api.security.ldap.userSearchBase: Nombre Distinguido/Distinguished Name (DN) del repositorio de usuarios en el servidor LDAP. Ejemplo:ou=Users,dc=pd,dc=griaulegbscluster.api.security.ldap.userSearchAttribute: Atributo de usuario que será usado como nombre de usuario durante la autenticación. Ejemplo:sAMAccountName,uidgbscluster.api.security.ldap.userGroupMembershipAttribute: Atributo de usuario que contiene la información de pertenencia a grupos. Ejemplo:memberOfgbscluster.api.security.ldap.bindUserDNNombre distinguido del usuario de vinculación (Bind User). El usuario de vinculación es una cuenta de usuario usada por GBDS para enlazarse al servidor LDAP, autenticar usuarios y obtener sus grupos.
Token
gbscluster.api.security.token.ttlInMilliseconds: Tiempo de vida, en milisegundos, del token JWT. Valores válidos: entre 30 minutos y 3 horas.
Autorización
gbscluster.api.security.authorization.ranger.configurationDirectory: Directorio con las configuraciones específicas de Ranger para GBDS.
Integrando con Active Directory
Verificando Resolución de DNS
Antes de comenzar, asegúrese de que la resolución de nombres para el dominio en el que las máquinas del cluster serán integradas funciona correctamente. Para el dominio llamado pd.griaule, use el siguiente comando:
Asegúrese de que la SECCIÓN DE RESPUESTA está presente y contiene el nombre de host y la dirección IP del controlador de dominio.
Resuelva cualquier problema de resolución DNS antes de continuar.
Instalando los Paquetes Necesarios
Integrando con el AD
Usar la utilidad realm es la forma más conveniente de integrar SSSD con AD. Ejecute el siguiente comando para mostrar la información básica sobre el dominio:
Unirse al Dominio
Para unirse, necesitará una cuenta que pertenezca al grupo de administradores del dominio.
Luego, habilite NSS y PAM con:
Y, finalmente, verifique que la máquina se haya unido al dominio correctamente consultando un usuario del dominio:
Solucionando Errores
Si surge algún problema, use los siguientes consejos:
Verifique de nuevo la resolución de nombres DNS. Esta es la causa más frecuente de errores.
Asegúrese de que los directorios
/etc/sssd/y/etc/sssd/conf.dexisten y ambos tienen permiso 0600.Aumente el debug_level en
/etc/sssd/sssd.confen todas las secciones, es decir,[sssd],[nss],[pam],[domain]. Luego, reinicie el servicio sssd:sudo service sssd restart. Los registros se generarán en la carpeta/var/log/sssd/En el caso del error
Insufficient permission to join the domain ...: el usuario usado para unirse al dominio no tiene permiso. Verifique si el usuario forma parte delDomain Admins group
Integrando con OpenLdap
Esta guía explica cómo realizar la instalación mínima de OpenLDAP que será compatible con GBDS para autenticación y autorización.
Instale OpenLdap
Dependencias
Conéctese al host LDAP e instale los paquetes necesarios:
Inicie el Demonio LDAP
A continuación, inicie el Demonio LDAP y configure para que arranque automáticamente al iniciar el sistema:
Genere la contraseña de root
Ejecute el comando ldappasswd para crear una contraseña root de LDAP. Anote tanto la contraseña normal como la versión codificada devuelta por ldappasswd.
Cree la base de datos hdb
El hdb es una variante jerárquica del backend de base de datos bdb. En el modelo de configuración abajo, defina las siguientes variables de acuerdo con su caso de uso:
olcSuffix: Representa el nombre de dominio para el cual el LDAP proporcionará la información de cuentas. Además, este nombre distinguido será agregado a las queries que serán enviadas al backend.
olcRootDN: es el nombre distinguido del usuario que tendrá acceso administrativo al servidor LDAP.
olcRootPW: Define la contraseña del usuario administrador. La contraseña será el resultado codificado del comando
slappasswd, que se ejecutó previamente.
Coloque la configuración en un archivo llamado db.ldif.
ASEGÚRESE DE SUSTITUIR olcRootPW, olcRootDN y olcSuffix.
Asegúrese de que no haya espacios innecesarios ni líneas en blanco, o podrían ocurrir problemas. Vea: https://serverfault.com/questions/578710/wrong-attributetype-when-using-ldapadd
Envíe los cambios al servidor
Si no usa sudo, tendrá problemas de permisos: ldap_modify: Insufficient access (50)
Restringir el Acceso de Monitoreo a ldapadm
Coloque las siguientes configuraciones en el archivo llamado monitor.ldif y actualice el dn.base, donde dice UPDATE ME, con el nombre distinguido del valor definido previamente en oclRootDN.
Envíe los cambios al servidor
Si no usa sudo, tendrá problemas de permisos: ldap_modify: Insufficient access (50)
Agregue el archivo de configuración del backend hdb
Este archivo define las opciones de configuración básicas para el backend hdb:
Agregue esquemas LDAP esenciales
Habilite el módulo memberOf
ES NECESARIO HACER ESTO ANTES DE QUE SE CREE CUALQUIER GRUPO. EL ATRIBUTO MEMBEROF ES UN ATRIBUTO OPERACIONAL Y NO SE CREA RETROACTIVAMENTE.
Este módulo es necesario para consultar los grupos de un usuario. Coloque la siguiente configuración en el archivo llamado memberof_config.ldif:
Para enviar los cambios al servidor, ejecute el comando:
Genere la base de datos para su dominio
Finalmente, especificamos la base de datos, que usará las configuraciones previamente creadas, para servir todas las solicitudes al dominio (valor de olcSuffix). Actualice el DN de Users y Groups para coincidir con las configuraciones del dominio. Inserte las configuraciones en db_structure.ldif.
Para enviar los cambios al servidor, use la cuenta de administrador configurada (olcRootDN) después del parámetro -D. La utilidad ldapadd pedirá la contraseña de la cuenta de administrador previamente definida.
Solucionando Errores
Tenga en cuenta que los mensajes de error devueltos por OpenLdap pueden ser confusos. Si tiene problemas con la instalación, se recomienda habilitar el modo debug. Pare el servicio slapd y luego reinicie directamente el proceso con la opción de debug -d -1:
Si TLS está habilitado, incluya también la cadena para el endpoint ldaps:
Cifrando contraseñas en OpenLdap
Por defecto, OpenLdap almacena las contraseñas en texto claro. Para cambiar este comportamiento, es necesario: Definir un algoritmo global de hash de contraseñas y habilitar la política de contraseñas para cifrar automáticamente cualquier contraseña en texto claro.
Configurando el Algoritmo de Hash
Usaremos el algoritmo SHA-512 con 50000 rondas y sal de 16 bytes. Cree un archivo llamado hash_algorithm.ldif
Para enviar las configuraciones al servidor:
Importar el Esquema de Política de Contraseñas
Cargar el módulo de Política de Contraseñas
Cree un archivo llamado password_policy_config.ldif conteniendo:
Luego envíe los cambios con:
Si encuentra un error indicando que pwdAttribute no existe, significa que el esquema de política de contraseñas no fue importado.
Creando una Política de Contraseña Predeterminada
Cree un archivo llamado password_policy.ldif conteniendo:
Luego envíe los cambios con el comando abajo, reemplazando el olcRootDN:
Mejorando la Seguridad
Desactivando Enlace Anónimo
Cree un archivo disable_anon_binding.ldif conteniendo:
Luego envíe los cambios:
Para probar si los cambios funcionaron, ejecute la siguiente búsqueda anónima:
Desactivando Permiso de Lectura de Contraseñas de Usuario
Finalmente, cualquier usuario puede obtener la contraseña de otro usuario. Aunque las contraseñas estén cifradas, esto debe evitarse. Más aún si se decide mantener las contraseñas en texto claro. Entonces, cree un archivo llamado disabled_password_read.ldif.
ASEGÚRESE DE QUE NO HAYA SALTOS DE LÍNEA PARA olcAccess
Envíe los cambios:
Si ejecuta una búsqueda enlazada con cualquier usuario que no sea olcRootDN, la única contraseña devuelta será la del propio usuario.
Habilitando LDAPS
Antes de continuar, asegúrese de que su instancia de OpenLdap está funcionando y que posee dos unidades organizativas: una para usuarios y otra para grupos. Puede verificar esto usando Apache Directory Studio para conectar al servidor usando la URL de conexión ldap, por ejemplo: ldap://192.168.0.100:389, y con su cuenta de administrador configurada (olcRootDN).
Para habilitar LDAPS, será necesario un certificado válido firmado por una autoridad de confianza (trusted authority). Alternativamente, proveemos una guía de cómo configurar su propia autoridad certificadora y cómo usarla para firmar certificados de su servidor.
Cree su CA
Si ya tiene un certificado válido, puede omitir este paso.
En CentOS, encontrará el archivo openssl.cnf, que contiene la configuración principal para su CA, en el directorio /etc/pki/tls. Sin embargo, nuestra CA se ubicará en /etc/pki/CA.
Primero, cree el archivo index.txt y los archivos seriales, que contendrán información de los certificados firmados y el número de serie del certificado a usar, respectivamente.
A continuación, agregue las siguientes políticas a /etc/pki/tls/openssl.cnf:
Ahora, cambie al directorio de la CA:
Generaremos el certificado CA, válido por 10 años, con el comando siguiente. La utilidad le pedirá que defina la contraseña de la clave privada y la información sobre el sujeto del certificado (la CA, en este caso). Anote esta contraseña, se requerirá para firmar certificados.
A continuación, limite los permisos de acceso a la clave privada de la CA:
Cree un Certificado para el Servidor LDAP
Primero, creamos una solicitud de firma de certificado para el servidor LDAP:
Luego, firmamos el server.csr usando la clave privada de la CA:
Ahora, el ldap_cert.pem es el certificado para su servidor y su clave privada está en el archivo ldap_key.pem.
la clave privada del servidor no está cifrada (-nodes parámetro). Esto es menos seguro, pero OpenLdap no soporta claves cifradas. Por lo tanto, es indispensable restringir todo acceso a ese archivo, como se hará en los pasos siguientes.
Configurando OpenLdap para usar el certificado y la clave
Primero, copie el certificado de la CA a /etc/openldap/cacerts. Esto hará que OpenLdap confíe en el certificado firmado por su CA.
Luego, instale el certificado de su servidor ldap en /etc/openldap/certs:
Establecer permiso 400 para la clave privada del servidor es INDISPENSABLE.
Cree un archivo llamado enable_ldaps.ldif con las siguientes configuraciones:
Luego, envíe los cambios al servidor y pruebe los archivos de configuración:
Habilite el Endpoint TLS
En el archivo /etc/sysconfig/slapd, añada ldaps:/// en la línea que comienza con SLAPD_URLS=. Después de esto, la línea debería ser similar a:
Forzar TLS
Cree un archivo llamado force_tls.ldif con el siguiente contenido:
Entonces, envíe los cambios al servidor:
Ahora pruebe el requisito TLS ejecutando la siguiente búsqueda. Debe ser denegada debido al requisito TLS:
A PARTIR DE AHORA, CUALQUIER LLAMADA AL ldapi:/// QUE REQUIERA EL olcRootDN (p. ej., aquellas que crean entidades en el árbol del directorio) DEBE REALIZARSE EN EL ldaps:///. LLAMADAS QUE PUEDEN USAR -Y EXTERNAL (p. ej., que modifica cn=config) TODAVÍA PUEDEN USAR ldapi:///.
Configuración TLS del lado del cliente
Para permitir que utilidades como ldapsearch se conecten vía TLS, agregue TLS_REQCERT allow a /etc/openldap/ldap.conf:
Crear un Usuario Binding para el Ranger del GBDS
El GBDS y el Ranger exigirán que el usuario se vincule al servidor LDAP para ejecutar consultas y autenticaciones. El único privilegio que este usuario necesita es leer el árbol de directorio.
No use el olcRootDN como el usuario de enlace.
Cree un archivo llamado bind_user.ldif con el siguiente contenido. Reemplace o dn: por uno que coincida con su instalación. Adicionalmente, defina la contraseña del usuario de enlace. Si habilita el cifrado de la contraseña, escriba la contraseña en texto plano. Si no, use slappasswd para producir un hash para la contraseña y escriba el hash en el archivo .ldif (Similar a cómo se creó la contraseña de olcRootDN).
Envíe los cambios con:
Para probar si el usuario fue creado correctamente, ejecute la siguiente búsqueda autenticándose con el usuario de enlace credentials:his
API de LDAP
La API LDAP es una API proporcionada por Griaule para ayudar en la gestión de usuarios y grupos. Usted puede autenticar, crear, eliminar o modificar datos de usuarios y listar datos de usuarios y datos de grupos mediante la API.
Si los archivos de la API no fueron proporcionados, contacte al Equipo de Soporte de Griaule.
La API completa puede ser accedida en Api do LDAP.
La API funciona con seguridad SSL y es necesaria una truststore y keystore. Para más información sobre la creación de éstas, vea la sección Configurando la Seguridad del GBDS.
Configurando la API
Para instalar y configurar correctamente la API, siga los pasos:
Extraiga el paquete proporcionado.
En
/etc/griaulecree el directorioldap.Mueva el directorio
confdel paquete proporcionado al directorio/etc/griaule/ldap.Mueva el
config.propertiesal directorio/etc/griaule/ldap.Abra el archivo
config.propertiesy ajuste los parámetros de configuración de acuerdo con su entorno.En
/var/lib/griaulecree el directorioldap.Mueva el archivo
bs-ldap-api.jary el scriptkill-api.shystart-api.shal nuevo directorio.Ejecute el script de inicio (start).
Creando Nuevos Usuarios y Grupos
Para crear un nuevo usuario, invoque Create User. La API creará el usuario, la contraseña y los grupos a los que el usuario pertenece.
Si se requieren modificaciones en un usuario existente, invoque Modify User Data.
Para recuperar datos del usuario, invoque Get User Data.
Para añadir, modificar o eliminar grupos, acceda a /etc/griaule/ldap/conf/group-list.json y modifique el archivo según lo deseado. También puede ver todos los grupos invocando List Groups.
Instalando el Ranger
Después de que OpenLdap o Active Directory estén configurados, puede procederse a la instalación del Ranger.
Prerrequisitos
Instalando ambari-infra
Vaya al Ambari e instale el servicio Ambari-infra. Esto proporcionará una instancia de Solr para almacenar datos auditados para el Ranger.
Instale y Configure la Instancia MySQL
Instale una instancia de MySQL
Cree el usuario rangerdba y conceda los privilegios necesarios
Note que Rangerdba$1 es la contraseña para el usuario rangerdba. Sustituya por la contraseña deseada.
Pruebe si el usuario rangerdba fue creado con éxito:
mysql -u rangerdba -pInstale el conector MySQL:
yum install mysql-connector-java*Registre el conector con Ambari, ejecutando los siguientes comandos en el host con el servidor Ambari instalado:
ambari-server setup --jdbc-db=mysql --jdbc-driver=/usr/share/java/mysql-connector-java.jar
Instalando el Servicio del Ranger
Vaya al Ambari y agregue el servicio Ranger. Visite cada una de las siguientes pestañas de configuración antes de finalizar la instalación.
Ranger Admin
Deje el nombre de usuario de la BD del Ranger como
rangeradmin. Ponga la contraseña que desee, pero guárdela para después.Asegúrese de que las opciones
Setup DatabaseyDatabase Userestén marcadas comoYesPara el nombre de usuario DBA, use la cuenta de usuario creada en los pasos anteriores.
Información de Usuarios del Ranger
Este servicio importará usuarios y grupos en la base de datos del Ranger.
A continuación, damos SUGERENCIAS para valores en varias opciones de configuración requeridas. Usted debe asegurarse de que correspondan a su implementación LDAP.
Cambie el Sync Source para el
Ldap/ADEn la pestaña Common Config:
LDAP/AD URL: Si la URL configurada aquí es para LDAPS, el certificado LDAPS necesitará ser importado en el truststore de usersync como se describe en la sección Importar el Certificado Ldaps
Bind User: Complete el usuario DN de enlace y la contraseña. El usuario solo necesita privilegio de lectura para el repositorio de Usuarios y Grupos.
En la pestaña User Configs:
Username Attribute: atributos que almacenan el userName para el inicio de sesión. Para AD, usualmente
sAMAccountNamey para OpenLdap,uid.User Search Base: DN para el nodo que contiene el usuario que necesita ser sincronizado (Usuario AD).
En la pestaña Group Configs:
Group member Attribute: Atributo de la entidad Grupo que almacena qué usuario pertenece a qué grupo, además de información sobre la asociación usuario-grupo. Es usualmente
memberGroup Name Attribute: Atributo del grupo que contiene el nombre del grupo. Usualmente
cnGroup Object Class: Clase de la entidad de grupo. Para AD, es usualmente
group, para OpenLdap es usualmentegroupOfNamesGroup Search Base: con el nodo que contiene los grupos que necesitan ser sincronizados
Ranger Audit
Marque la opción
Audit to SolrMarque la opción
Solr Cloud
Verificación de la Instalación
Sincronización de Usuario
Vaya al sitio web del Ranger en http://<host>:6080, inicie sesión y vaya a Settings, y entonces, Users/Groups. Todos los usuarios y grupos de la User/Group Search Base deben estar presentes. Si no es así, ocurrió un problema con la sincronización de usuario. Verifique el registro en /var/log/ranger/usersync/usersync.log para identificar el error.
Solr Audit
Vaya a la UI de ambari-infra y verifique la existencia de la colección ranger_audits
Habilitando la Integración del Ldap con TLS
Para habilitar que Ranger use LDAPS en lugar de LDAP, se deben hacer dos cambios. Primero, necesitamos actualizar la URL de conexión LDAP a la URL protegida por TLS. Segundo, necesitamos importar el certificado LDAPS.
Cambiando la URL de Conexión LDAP
Vaya, en Ambari, a Ranger, Configs, Ranger User Info, Common Configs. Cambie el LDAP/AD URL a ldaps://<hostname>:636
Importar el Certificado Ldaps
Si su repositorio LDAP está usando TLS, necesita importar su certificado en el UserSync truststore del ranger.
Para obtener la ubicación del truststore, vaya a Ambari, Ranger, Configs, Advanced, Advanced ranger-ugsync-site, ranger.usersync.truststore.file. Luego, use el keytool de Java para importar el certificado LDAPS en la truststore. Si la truststore ya existe, será necesaria una contraseña. Si no, anote la contraseña usada. La necesitará después.
A continuación, corrija el permiso y el propietario de la truststore.
Si la truststore es nueva, vaya a Ambari, Ranger, Configs, Advanced, Advanced ranger-ugsync-site y defina las propiedades:
ranger.usersync.truststore.file: con la ruta absoluta a la truststore
ranger.usersync.truststore.password: contraseña para la truststore
Solucionando Errores
Si no es posible crear el SSLContext para la comunicación con el gestor de políticas, hay un problema con las credenciales y las claves del usersync. La única forma de resolver este problema es eliminar la truststore /usr/hdp/current/ranger-usersync/conf/mytrustore.jks, recrearla con el certificado LDAPS y actualizar la configuración de la contraseña en Ambari, Ranger, Configs, Advanced ranger-usersync-site
Configurando la Seguridad del GBDS
Una vez que Ranger, Solr y el servidor LDAP estén instalados y configurados, podemos proceder con las configuraciones del GBDS.
Creando el Keystore del GBDS
El keystore se usará para guardar las contraseñas de los usuarios vinculados y las claves de firma para los tokens JWT generados por la API.
Ejecute el script /var/lib/griaule/gbsapi/scripts/create_keystore.py pasando la ruta al nuevo almacén de claves y la ruta para crear el archivo de contraseñas. El script preguntará por la contraseña del usuario de enlace a guardar. Luego, el script creará el keystore con la contraseña del usuario de enlace y una clave de firma aleatoria. El keystore será protegido por una contraseña generada aleatoriamente, la cual será guardada en el archivo de contraseñas especificado. Por último, los archivos del keystore y de contraseñas tendrán los permisos cambiados a solo lectura.
El archivo de contraseñas contiene las contraseñas en texto plano. Por lo tanto, es indispensable que esto se mantenga en una ubicación segura con acceso permitido solamente al usuario griaule.
Creando trustore para LDAPS
Si pretende conectarse a su servidor LDAP usando SSL, necesita importar el certificado del servidor a un truststore y configurar el GBDS para usarlo.
Suponiendo que el certificado del servidor se llame server_cert.pem, ejecute el siguiente comando y use una contraseña fuerte para el truststore:
Además de crear la truststore, este comando restringirá el acceso al usuario griaule. Luego, guarde la contraseña de la truststore en el archivo de contraseñas.
Actualizando el Archivo de Configuración
Edite el archivo /etc/griaule/conf/gbscluster.properties y modifique las siguientes propiedades:
gbscluster.api.security.enabled: defina como true para habilitar la seguridad.
gbscluster.api.security.keystore: ruta al keystore que usted creó (
/etc/griaule/conf/gbsapi/keystore.jks)gbscluster.api.security.truststore: ruta a la truststore que usted creó (
/etc/griaule/conf/gbsapi/truststore)gbscluster.api.security.passwords: ruta al archivo de contraseñas (
etc/griaule/conf/gbsapi/.passwords)gbscluster.api.security.ldap.url: URL del servidor LDAP, ejemplo:
ldap://<host>:389. Si habilitó LDAPS, esto debe serldaps://<host>:636gbscluster.api.security.ldap.userSearchBase: El DN del nodo del árbol que guarda los usuarios que estarán habilitados para autenticación en el GBDS. En su guía de instalación de OpenLdap, el DN debería ser:
ou=Users,dc=oldap,dc=pd,dc=griauleES NECESARIO QUE SEA EL MISMO DN CONFIGURADO EN RANGER
gbscluster.api.security.ldap.userSearchAttribute: Atributo de la entidad Usuario que contiene el
userName, que será usado durante la autenticación.ES NECESARIO QUE SEA EL MISMO CONFIGURADO EN RANGER
gbscluster.api.security.ldap.userGroupMembershipAttribute: Atributo de la entidad Usuario que contiene el DN de los grupos a los que pertenece. Usualmente memberOf.
ES NECESARIO QUE SEA EL MISMO CONFIGURADO EN RANGER
gbscluster.api.security.ldap.bindUserDN: DN del usuario de enlace. Use el mismo configurado para Ranger.
gbscluster.api.security.token.ttlInMilliseconds: Tiempo de vida, en milisegundos, para el token JWT generado por la API. Los valores válidos están entre 30 minutos y 3 horas. Recomendamos 1 hora.
Instalando el Servicio de Autorización del Ranger
Para instalar y ejecutar el servicio de autorización del Ranger, es necesario haber creado un usuario GBDS y un usuario ADMIN.
Para crear el usuario administrador, abra el archivo administrator_group.ldif en la carpeta /etc/openldap y agregue lo siguiente al archivo:
A continuación, en el archivo gbds_user.ldif, cree el usuario GBDS.
Aplique los cambios reiniciando Ranger a través de la GUI del Ambari.
Si el TLS está activo, recuerde cambiar ldapi:/// por ldaps:///.
Cuando los cambios se apliquen, ejecute el Servicio de autorización de Ranger.
Para finalizar el proceso, actualice los Archivos XML del Ranger. Vaya a /etc/griaule/conf/gbsapi/ y en el archivo ranger-gbds-audit.xml, modifique según:
Haga lo mismo para ranger-gbds-security.xml
Configurando el PHP LDAP Admin
PHP LDAP Admin es una herramienta para gestionar OPENLDAP vía GUI, es una alternativa al uso de la CLI. El usuario puede agregar/modificar/eliminar usuarios, grupos, roles, etc. vía GUI. Tenga en cuenta que esto no es necesario para que LDAP funcione.
Primero, instale las dependencias de PHPLDAPAdmin.
En /etc/httpd/conf.d, actualice el archivo phpldapadmin.conf con
Y también actualice el archivo config.php en la carpeta /etc/phpldapadmin con
Ejecute el siguiente comando para iniciar y habilitar los servicios HTTPD
Después de habilitar HTTPD, es necesario especificar las posibles actualizaciones. Si el firewall está activado, ejecute
Y si SELinux está habilitado, ejecute
Valide la GUI de PHP LDAP Admin abriendo la interfaz en http://localhost/ldapadmin con el usuario (DN, por ejemplo, cn=ldapadm,dc=oldap,dc=pd,dc=griaule) y contraseña. Luego, haga clic en los menús desplegables y confirme si todos los usuarios y grupos están disponibles.
Última actualización
¿Te fue útil?