2.15 - Directrices de seguridad del conector de destino de Hive - Teradata QueryGrid

Teradata® QueryGrid™ Guía de instalación y uso

Product
Teradata QueryGrid
Release Number
2.15
Release Date
Marzo de 2021
Content Type
Administración
Configuración
Guía del usuario
Instalación
Publication ID
B035-5991-031K-ESN
Language
Español (España)

General

Cuando establezca parámetros para los conectores de destino de Hive en los emparejamientos de enlaces, asegúrese de que la propiedad Rutas de archivo de configuración contenga la ruta de acceso correcta. QueryGriddepende en gran medida de esta configuración al procesar transferencias de datos. Consulte Propiedades de conectores y enlaces de Hive.

Kerberos

QueryGrid puede utilizar la autenticación Kerberos con un conector de destino de Hive. Hay dos formas de autenticación Kerberos:

Username/Password
El conector de destino de Hive autentica el nombre de usuario y la contraseña para Kerberos antes de enviar la consulta al origen de datos.
Username/Keytab
Hive se configura para habilitar la autenticación mediante Keytab de Kerberos.
Cuando utiliza un conector de destino de Hive en un emparejamiento de enlaces de NVP para acceder a un clúster de Hadoop con Kerberos:
  • Seleccione Kerberos para la propiedad Mecanismo de autenticación.
  • Configúrelo como SoloHS2 si solo se ha asegurado el HiveServer2 (por ejemplo, LDAP/CUSTOM/PAM). Esta no es una configuración común.
  • Verifique que el usuario de Teradata QueryGrid (tdqg) tenga permiso para ejecutar kinit. Consulte Verificación del permiso para ejecutar kinit.
    Al utilizar Kerberos en CDH, debe establecer el NVP principal de Kerberos de Hive en la entidad de seguridad Kerberos correcta para HiveServer2, no la entidad de seguridad Kerberos para el usuario que se conecta a HiveServer2. El formato de la configuración debe ser primaryname/instancename@realmname.

Kerberos de confianza

El conector de Hive admite el valor de authentication mechanism de Trusted Kerberos, que permite la suplantación de los usuarios finales de QueryGrid con una sola cuenta de servicio de Kerberos. Si la cuenta de servicio de Kerberos tiene privilegios de nivel de Hadoop para suplantar a un usuario solicitado, las consultas de QueryGrid se ejecutan en la sesión como ese usuario solicitado.

Esta característica solo se admite con clústeres de Hadoop de Kerberos y QueryGrid 2.13 y versiones posteriores. La configuración de Kerberos es la misma que la configuración de autenticación de Kerberos, pero con algunas opciones adicionales.

El usuario suplantado se pasa al sistema de destino mediante la propiedad hive.server2.proxy.user de JDBC. El usuario suplantado debe estar en Allowed OS users para ejecutar consultas en los sistemas de origen y de destino. Hay dos maneras de definir el usuario suplantado:
Opciones Descripción
Usuario en el sistema iniciador (predeterminado) El usuario del sistema Teradata se pasa al sistema de destino como el usuario suplantado con el nombre de usuario en minúsculas.
Asignación de usuarios La asignación de usuarios puede definir al usuario suplantado con un nombre de usuario que distingue entre mayúsculas y minúsculas en el sistema de destino para cualquier usuario del sistema iniciador. Un caso de uso típico es cuando el nombre de usuario suplantado no está en minúsculas.

Al configurar la suplantación de usuario en HiveServer2, el usuario del servicio debe poder suplantar al usuario solicitado. Esto requiere configurar las propiedades hadoop.proxyuser.kerberos_service_user.groups y hadoop.proxyuser.kerberos_service_user.hosts en el archivo core-site.xml para la cuenta de servicio de Kerberos. JDBC desencadena las consultas de QueryGrid desde el nodo del controlador; por lo tanto, las direcciones IP de los nodos de controlador deben especificarse en la propiedad hadoop.proxyuser.kerberos_service_user.hosts.

Evite el uso de comodines (*) como valor para las propiedades hadoop.proxyuser.<krb service>.hosts y hadoop.proxyuser.<krb service>.groups. Aplique las restricciones previstas en los grupos de usuarios que puedan ser suplantados por diferentes hosts.

Knox (solo HDP y Dataproc)

Si se habilita, Knox es una opción de seguridad que sirve como servicio de puerta de enlace entre Hive y HiveServer2 cuando se configura en las propiedades del conector de Hive. El conector de Hive se conecta al servicio Knox en lugar de directamente a HiveServer2. A continuación, las solicitudes del conector de Hive se envían al servicio Knox y Knox redirige la solicitud a HiveServer2. Consulte la documentación de Knox y Hortonworks Data Platform (HDP) o Dataproc para obtener información sobre cómo configurar Knox correctamente.

Hay una limitación con Knox cuando SSL está habilitado y Knox se conecta a HiveServer2 usando la autorización SPNEGO. En este escenario, Knox no funciona con Hive.

Cuando una base de datos de Hortonworks Hadoop está protegida por Knox y desea que el conector de Hive de QueryGrid se conecte a través de Knox, asegúrese de que las siguientes propiedades de enlace NVP contengan los valores correctos:

Configuración Descripción
Contraseña de la conexión de Knox Contraseña para la conexión Knox. Solo es necesaria cuando se utiliza Knox.
Nombre de usuario de la conexión de Knox Nombre de usuario para la conexión Knox. Solo es necesario cuando se utiliza Knox.
Ruta del contexto de Knox Ruta de contexto de Knox para HS2, por ejemplo: gateway/mycluster/hive. Solo es necesaria cuando se utiliza Knox.
Host de puerta de enlace de Knox Host de puerta de enlace de Knox. El uso de esta propiedad indica que se está utilizando Knox.
Puerto de puerta de enlace de Knox Número de puerto de puerta de enlace Knox. Los valores de número de puerto válidos son 1024 a 65535.
Ruta del almacén de confianza de Knox Ruta del almacén de confianza de Knox. Solo es necesaria cuando se utiliza Knox.
Contraseña del almacén de confianza de Knox Contraseña del almacén de confianza de Knox. Solo es necesaria cuando se utiliza Knox.

Para obtener más información, consulte Propiedades de conectores y enlaces de Hive.