Ingeniería

Desmitificación de la autenticación y autorización en Elasticsearch

By
Gabriel Moskovicz

Trabajo en Elastic desde hace más de 4 años, de los cuales 3.5 años me dediqué a soporte y consultoría, y el último medio año estuve en ventas. Sin importar en qué departamento esté, las preguntas más comunes que recibo de los usuarios son sobre cómo asegurar Elasticsearch. ¿Qué tipo de autenticación soporta Elasticsearch? ¿Cómo la configuro? ¿Cómo puedo asegurarme de que los usuarios no vean datos que no deberían ver? El objetivo en este blog es responder esas preguntas y proporcionar algo de ayuda para resolver algunos problemas comunes durante la configuración de la seguridad.

Primero, un poco de historia. Si usas Elasticsearch desde hace tiempo, sabrás que en algún momento la seguridad la proporcionaba un plugin denominado Shield que se ofrecía en X-Pack. Actualmente, esa funcionalidad de seguridad se pasó al Elastic Stack (junto con el resto de X-Pack), y las características más usadas están disponibles gratis en la distribución predeterminada. La seguridad incluye comunicación encriptada (TLS/SSL), autenticación (nativa, LDAP, SSO, etc.), autorización (RBAC, ABAC, etc.), filtrado IP, logs de auditoría y mucho más. En este blog nos enfocaremos en las dos “aut”.

Autenticación en Elasticsearch

En pocas palabras, si un usuario o API desea acceder a Elasticsearch, debe autenticarse.

Elasticsearch soporta varios métodos de seguridad de forma nativa, como los siguientes:

Incluso puedes crear tu propia integración si una de estas opciones no se aplica en tu caso. Sin embargo, por lo general recomendamos que uses una de las integraciones existentes, dado que están validadas y continuamos el desarrollo con ellas para asegurar un soporte adecuado.

El componente más básico de seguridad en Elasticsearch es un realm, que es lo que resuelve y autentica usuarios. Cada uno de los métodos de autenticación mencionados antes se consideraría un realm. Y para funcionar, Elasticsearch usa una cadena de realms. Una cadena de realms es una lista priorizada de realms configurados (de 1 a N realms) en orden ascendente de preferencia. Cuando un usuario intenta acceder a Elasticsearch, la solicitud recorrerá la lista de manera secuencial hasta que se complete correctamente la autenticación o no queden realms para intentar.

Básicamente, el proceso probará con el primer realm configurado en la lista y, si falla, continuará con el siguiente hasta tener éxito con uno de ellos o ejecutar toda la lista de forma exhaustiva. Este primer paso para acceder a Elasticsearch se denomina autenticación.

Una vez autenticado un usuario, Elasticsearch intentará asignarle uno o más roles. Los roles se pueden asignar a los usuarios de forma estática o dinámica durante la autenticación, con base en algunas de las propiedades del usuario. Según el tipo de realm que autenticó al usuario, las propiedades del usuario usadas para asignar un rol pueden ser la membresía de grupo que tiene en un sistema externo o el sufijo de su nombre de usuario en Elasticsearch, etc. Además, Elasticsearch también cuenta con la funcionalidad run as, que permite a los usuarios enviar solicitudes en nombre de otros usuarios sin requerir una nueva autenticación.

Una vez completada la fase de autenticación, el siguiente paso es la autorización. Puedes comprobar el flujo de trabajo completo en el gráfico siguiente:

Cadena de realms en Elasticsearch

Autorización en Elasticsearch

Una vez completada correctamente la autenticación, el usuario pasará al segundo punto de control de seguridad: autorización. La autorización es el proceso de determinar si el usuario tiene permitido ejecutar una solicitud y se realiza a través del mapeo de usuarios a roles predefinidos o definidos por el usuario. Existen roles que se incluyen predeterminados en Elasticsearch, pero también puedes crear roles específicos para tu caso de uso.

Un rol está compuesto por lo siguiente:

  • Una lista de los usuarios que pueden acceder
  • Privilegios de clusters
  • Privilegios globales
  • Privilegios de índices
  • Privilegios de aplicaciones

En la segunda fase, Elasticsearch usará alguno de los siguientes:

  • La API role_mapping, que es el método preferido porque puedes administrar el mapeo de cada rol de un modo centralizado e impulsado por API. Esta es la única manera de configurar mapeos de roles en Elasticsearch Service en Elastic Cloud.
  • El archivo de mapeo de roles (role_mapping.yml) que existe en cada nodo dentro de la carpeta de configuración.

A la API role_mapping la debe invocar un usuario con los derechos adecuados para administrar roles. El rol superuser que tiene el usuario de Elastic es un ejemplo de esto; sin embargo, puedes crear un rol específico para esto también.

Los realms y roles son completamente distintos por definición. Los realms y las cadenas de realms son lo que usamos para obtener la autenticación, y después de la fase de autenticación terminamos usando roles para el mapeo a los usuarios. Mientras que un usuario solo se autenticará con un único realm de la cadena de realms, en la segunda fase el usuario puede mapearse de uno a varios roles. A esto también se lo conoce como Control de Acceso basado en roles.

Pasos para solucionar problemas de autenticación y autorización

Ahora que ya repasamos los conceptos básicos de la autenticación y autorización, veamos algunos de los pasos para solucionar problemas que puedes usar si encuentras algún inconveniente.

401: no autorizado

Si no puedes autenticarte con ninguno de los realms, recibirás una respuesta con el código de estado 401 Unauthorized. La forma más sencilla de probar tus credenciales en la lista de realms configurados es usar cURL con un marcador que permita la inspección (por ejemplo, -v). Es posible que obtengas una respuesta como la siguiente: 

curl https://xxxxxx:9200 -u test:test -v 
> User-Agent: curl/7.54.0 
> Accept: */* 
> 
< HTTP/1.1 401 Unauthorized 
< Content-Type: application/json; charset=UTF-8 
< Date: Tue, 10 Sep 2019 15:59:33 GMT 
< Www-Authenticate: Bearer realm="security" 
< Www-Authenticate: ApiKey 
< Www-Authenticate: Basic realm="security" charset="UTF-8" 
< Content-Length: 455 
< Connection: keep-alive 
< 
* Connection #0 to host 06618318cff64c829af1cd5a2beb91a5.us-east-1.aws.found.io left intact 
{"error":{"root_cause":[{"type":"security_exception","reason":"unable to authenticate user [test] for REST request [/]","header":{"WWW-Authenticate":["Bearer realm=\"security\"","ApiKey","Basic realm=\"security\" charset=\"UTF-8\""]}}],"type":"security_exception","reason":"unable to authenticate user [test] for REST request [/]","header":{"WWW-Authenticate":["Bearer realm=\"security\"","ApiKey","Basic realm=\"security\" charset=\"UTF-8\""]}},"status":401}%

Este mensaje de error puede ayudarte a conocer la causa raíz de tu problema. Por ejemplo, existen realms específicos como SAML que requieren Kibana o una aplicación web personalizada para realizar la interacción con Elasticsearch y el proveedor de identidad.

Habilitación de registros de errores

Después de configurar los realms, la cadena de realms, los roles y el mapeo de roles, si aún tienes problemas, puedes configurar con facilidad algunos registros adicionales para obtener más información sobre el proceso de autenticación y autorización que abordamos antes.

Con la configuración de registros dentro de la API de configuración del cluster, puedes definir cualquier nivel de registro para cualquiera de los realms.

Echemos un vistazo a un ejemplo con el realm LDAP. Si falla la autenticación o autorización de usuario, puedes configurar el nivel de registro siguiente para obtener más información al respecto: 

PUT /_cluster/settings 
{ 
  "transient": { 
     "logger.org.elasticsearch.xpack.security.authc.ldap":"DEBUG", 
     "logger.org.elasticsearch.xpack.security.authz":"DEBUG" 
   } 
}

Esto aumentará el nivel de registro para el paquete LDAP de la configuración predeterminada a DEBUG. También puedes habilitar el registro TRACE para obtener incluso más información como cada llamada LDAP realizada al servidor y la respuesta de este. Puedes encontrar el nombre del paquete para la habilitación en cada REALM específico usando el repositorio de GitHub. Por ejemplo, este es el código para el realm LDAP. En la primera línea de código puedes ver el paquete que se debe usar para el nivel de registro: 

package org.elasticsearch.xpack.security.authc.ldap;

Una vez habilitado, obtendrás muchas líneas de log, como en el ejemplo siguiente: 

[2019-09-12T08:41:20,628][DEBUG][o.e.x.s.a.l.LdapRealm   ] [xxxxxxx] user not found in cache, proceeding with normal authentication
[2019-09-12T08:41:21,180][TRACE][o.e.x.s.a.l.s.LdapUtils ] LDAP Search SearchRequest(baseDN='dc=xxx,dc=xxxx,dc=domain,dc=com', scope=SUB, deref=NEVER, sizeLimit=0, timeLimit=5, filter='(cn=vchatzig)', attrs={1.1}) => SearchResult(resultCode=0 (success), messageID=2, entriesReturned=1, referencesReturned=0) ([SearchResultEntry(dn='cn=xxxxxxx,ou=xxxxx,dc=intc,dc=xxxx,dc=domain,dc=com', messageID=2, attributes={}, controls={})])

Aquí podemos ver el realm LDAP intentando obtener el usuario de la caché (que podría estar desactualizada) y después realizando la solicitud LDAP Search al servidor con las configuraciones específicas que proporcionamos. Este es solo un ejemplo de muchas líneas de log que obtendrás.

Nota: Habilitar el registro es muy bueno para los diagnósticos, pero no para el rendimiento. Recomendamos configurar el nivel de registro nuevamente a su valor predeterminado una vez que sepas que todo funciona. Para hacerlo, usa lo siguiente: 

PUT /_cluster/settings 
{ 
  "transient": { 
     "logger.org.elasticsearch.xpack.security.authc.ldap": null, 
     "logger.org.elasticsearch.xpack.security.authz": null 
   } 
}

Ten en cuenta que algunos de estos paquetes podrían cambiar entre versiones, por lo que recomendamos volver a revisar los enlaces de la documentación para la versión específica de Elasticsearch que usas, junto con los enlaces de clases de GitHub para ese lanzamiento en particular.

Problemas comunes de SAML

El realm SAML requiere un proveedor de identidad (como Okta o Auth0) y una aplicación web (Kibana es la predeterminada) que, junto con Elasticsearch, actúen como el proveedor de servicios. Estos son algunos de los problemas que se presentan habitualmente:

  • Ajuste incorrecto de la URL de servicio de consumidor de aserciones en la configuración del proveedor de identidad (IdP). El endpoint que generalmente necesitas configurar en el proveedor de identidad es https://kibana.xxxx.com/api/security/v1/saml.
  • Los metadatos del proveedor de identidad no son accesibles a través de internet. El valor de la configuración idp.metadata.path en Elasticsearch en las instalaciones o en Elastic Cloud deberían ser accesibles a través de la red en la que se ejecutan Elasticsearch o Kibana. De lo contrario, debes descargar los metadatos desde un host que pueda acceder a ellos o puedes solicitarlos a un administrador del IdP, agregarlos como archivo local en Elasticsearch y consultarlos. El error mostrado será similar al siguiente: 
    Caused by: net.shibboleth.utilities.java.support.resolver.ResolverException: net.shibboleth.utilities.java.support.resolver.ResolverException: Non-ok status code 404 returned from remote metadata source https://xxxx.xxxx/xxx/yyyyyyyy/sso/saml/metadata
  • Es posible que puedas autenticarte, pero que el usuario no pueda abrir Kibana. En este caso, por lo general recomendamos volver a revisar los mapeos de roles de los usuarios para verificar que al menos uno de sus roles tenga acceso a Kibana.

La configuración del proveedor de identidad es tan importante como la configuración de Elasticsearch o Kibana, y siempre debemos estar atentos a errores de escritura y discrepancias entre las configuraciones esperadas y las establecidas. A pesar de que cada IdP específico tiene sus propias configuraciones, recomendamos leer detenidamente la documentación de cada configuración específica necesaria.

Para conocer los problemas más comunes y los pasos de solución de problemas para SAML, puedes visitar nuestra documentación para solución de problemas que se actualiza con cada lanzamiento.

Resumen

La autenticación en Elasticsearch es muy sencilla de configurar si comprendemos todos los conceptos involucrados. Además, comprender qué funciona, qué no y por qué a veces puede ser difícil, pero en este blog abarcamos muchas opciones para profundizar en el tema. Puedes usar nuestra documentación para dar los primeros pasos con la seguridad en Elasticsearch o nuestra guía para resolver problemas sobre seguridad de nuestra documentación. Ve a nuestro gerente sénior de productos de Elastic Security explicar en detalle la experiencia de los primeros pasos.

También recomendamos volver a revisar la página Suscripciones para obtener más información sobre las características incluidas en cada nivel. Por último, si tienes alguna pregunta específica, puedes comunicarte con tu representante de soporte o usar nuestros foros de debate.

¡Disfruta la seguridad!