Blog de Amazon Web Services (AWS)

Parte 2 – Integración de acesso Kibana con Cognito

Por Maria Ane Dias, Arquitecta de Soluciones, AWS Brasil

 

Al crear un dominio de Amazon Elasticsearch Service puede elegir que se realice la autenticación de Kibana mediante Amazon Cognito.

Mediante la integración de SAMLv2 puede utilizar AWS Single Sign On (AWS SSO), donde el administrador puede configura la aplicación Kibana en SSO y generar  el archivo SAML para que se configure en el grupo de usuarios de Cognito. Esto no se explicará en esta publicación, pero esta publicación de blog explica mejor cómo integrarse con AWS SSO.

 

 

Paso 1: Creación de grupo de usuarios y grupo de identidades en Cognito

Antes de crear el dominio Elastisearch, debe crear y configurar grupos de usuarios e identidades de Cognito.

Durante la creación del grupo de usuarios, elija un nombre de dominio para el grupo y seleccione la configuración predeterminada. Luego ingrese el grupo de usuarios y haga la configuración del nombre de dominio, menú izquierdo «Nombre de dominio»:

 

 

Después de que el usuario se haya autenticado (en el grupo de usuarios) necesitará autorización (credenciales temporales basadas en roles de AWS), en este punto el grupo de identidades entra en escena. Asociará al usuario autenticado con un rol para que pueda realizar operaciones a través de las API de AWS. Dado que en este caso el rol se está utilizando para acceder a una aplicación (Kibana), asociamos los permisos con el rol autenticado (vea cómo crearlo en el paso 2).

Cognito también le permite configurar un: «Rol no autenticado», para el acceso de los usuarios a los recursos incluso sin autenticación (usuario sin sesión o invitado). Sin embargo, dado que solo queremos proporcionar acceso a usuarios autenticados de manera efectiva, no realizaremos esta configuración. También existe la opción de asociar usuarios con roles específicos de AWS, una herramienta útil cuando se utiliza junto con el control de acceso granular de Kibana y que veremos más adelante.

 

Paso 2: Creación de roles de IAM para el grupo de identidades

En el proceso de configuración de autenticación, deberá crear al menos un rol de IAM para el usuario autenticado que se asociará con el grupo de identidades.

Para que el usuario reciba credenciales de IAM a través del grupo de identidades de Cognito, el rol debe tener una directiva de confianza asociada. La directiva de confianza es la configuración que permite a Cognito realizar una operación AssumeRoleWithWebIdentity.

En la siguiente tabla presentamos un ejemplo de una política de confianza para el grupo de identidades de Cognito. Tenga en cuenta que el ID que se va a utilizar es el ID del grupo de identidades. El rol será de tipo «Web Identity» como se muestra a continuación. Si este rol se utiliza para acceder a otro servicio de AWS distinto de Kibana, seleccione la política según el servicio al que se requiere acceder. Si el acceso es exclusivo de Kibana se puede dejar sin política de acceso.

 

 

¿Cómo se verá la política de confianza de roles?

{

  «Versión»: «2012-10-17",

  «Declaración»: [

    {

      «Efecto»: «Permitir»

      «Principal»: {

        «Federado»: «cognito-identity.amazonaws.com»

      },

      «Acción»: «STS: AssumerOleWithWebIdentity»,

      «Condición»: {

        «StringEquals»: {

                                         «cognito-identity.amazonaws.com:aud»: «us-east-1:xxxxxxxx-c0cb-xxxx-b... ( El ID del grupo de identidades Cognito aquí)»

        },

        «forAnyValue:StringLike»: {

          «cognito-identity.amazonaws.com:amr»: «autenticado»

        }

      }

    }

Después de crear el rol, configúrelo en el grupo de identidades de Cognito en la opción de rol autenticado, como se muestra a continuación:

 

 

Si tiene intención de utilizar varios perfiles de acceso para Kibana, será necesario utilizar varios roles de IAM, un rol para cada perfil con permisos diferenciados que se asociarán con usuarios autenticados.

 

Paso 3: Selección de grupos de Cognito en Elasticsearch

Cuando cree o edite su dominio de Elasticsearch, navegue a través de la pantalla donde se debe seleccionar el grupo de usuarios y el grupo de identidades, como se muestra a continuación. En esta misma pantalla, en el caso de crear un nuevo dominio, tendrá la opción de activar el control de acceso granular de Elasticsearch o no.

 

 

Opción de control de acceso granular y cognito

Existen dos formas distintas de configurar los permisos de acceso de ElasticSearch mediante Cognito: el acceso predeterminado y el control de acceso granular.

Sin control de acceso granular:

Si no está utilizando la opción Control de acceso granular de Elasticsearch, todos los usuarios se asociarán al mismo rol autenticado que el grupo de identidades de Cognito y  todos los usuarios tendrán los mismos permisos de acceso a Kibana. En este caso no hay distinción de permisos de acceso entre los usuarios a Kibana.

Control de acceso granular con base de usuarios interna en Elasticsearch:

La opción Control de acceso granular que crea una base de usuarios interna en la instancia de Elasticsearch no admite la administración de usuarios de Cognito (los usuarios se encuentran en una base de datos de instancias internas o en el grupo de usuarios de Cognito) y en el grupo de usuarios, como se explica en la parte 1 de este BlogPost se vuelven reutilizables en otros dominios y aplicaciones y no se pierden si el dominio se elimina. Por lo tanto, se supone aquí que si el usuario optó por el Control de Acceso Granular con Cognito está utilizando la opción Usuario Maestro.

Control de acceso granular con usuario maestro y base de usuarios en Cognito — esta es la opción que se seguirá explicando en este blog:

En el caso del control de acceso granular con Cognito (usuario maestro), es posible asociar diferentes roles de Kibana con diferentes roles de AWS, permitiendo así un control granular de lo que puede acceder cualquier persona dentro de Kibana. Esto se hace a través de AWS Identity and Access Management (IAM).

 En el momento de crear el dominio Elasticsearch, al rellenar el ARN de IAM del usuario maestro de control de acceso granular (sección de configuración que se presenta en la figura siguiente), se debe utilizar el mismo rol Autenticado que el grupo de identidades de Cognito.

 

 

Paso 4: Configuración de la directiva de dominio en Elasticsearch

Al crear el dominio Elasticsearch y habilitar Cognito simplemente seleccione el grupo de usuarios y el grupo de identidades que ya deben estar creados y configurados como se explicó anteriormente y  si desea configurar el control de acceso granular, coloque el «rol autenticado» IAM ARN como usuario maestro.

Para mayor seguridad, en la configuración de directiva de acceso al dominio de Elasticsearch se sugiere limitar el acceso al ARN de roles de Cognito, que será el siguiente: tenga en cuenta que el dominio no está abierto, ya que solo los usuarios asociados con estos roles pueden acceder al dominio:

 

 

{

  «Versión»: «2012-10-17",

  «Declaración»: [

    {

      «Efecto»: «Permitir»

      «Principal»: {

        «AWS»: [

          [ «arn:aws:iam። 123456789012:role/cognito_identityPoolAuth_rol»,

                       « arn:aws:iam። 123456789012:role/IAMLimitedUser «]

        ]

      },

      «Acción»: [

        «ES:ESHTTP*»

      ],

      « Recurso»: «arn:aws:es:region:123456789012:dominio/nombre-dominio/*»

    }

  ]

}

 

Si está utilizando Cognito sin Control de Acceso Granular, simplemente autorice en la política de acceso el rol autenticado de Cognito Identity Pool, porque, como se explicó al principio, no hay forma de controlar quién accede a qué dentro de la aplicación Kibana, por lo que no tiene sentido tener un usuario limitado, para ejemplo. En el paso 6 veremos cómo configurar un usuario limitado, que depende del control de acceso granular habilitado.

 

Paso 5: Acceso al Panel de control de Kibana

Después de crear el dominio integrado con Cognito, el usuario maestro tendrá acceso al Panel de control de Kibana. El enlace a Kibana se encuentra en la pantalla de inicio del dominio de Elasticsearch y será accesible según la configuración (la opción de acceso, por ejemplo a través de VPC, se explica en la parte 1 de este blog).

 

 

El usuario maestro de control de acceso granular tendrá acceso a la sección «Seguridad» en la interfaz de Kibana (tenga en cuenta el bloqueo en el menú de la izquierda a continuación):

 

 

En la sección Seguridad, puede asociar roles de Kibana (que se muestran a continuación) con roles de AWS (a través del rol IAM ARN).

 

 

Paso 6: Creación de usuarios con acceso limitado en Kibana

Para crear un usuario común de Kibana sin acceso a la sección de configuración de seguridad, simplemente asocie el rol kibana_user de Kibana a un rol de AWS y utilice la asociación específica de roles del grupo de identidades de Cognito que se explicará a continuación.

Pertenencia de usuarios a roles específicos en el grupo de identidades de Cognito

En el grupo de identidades de Cognito, configure la sección Proveedores de autenticación, donde debe apuntar al grupo de usuarios de Cognito, ya que proporcionará autenticación. En esta parte se selecciona el rol Autenticado, es decir, aquí es posible asociar usuarios autenticados con roles específicos según reglas predefinidas (menú que se muestra abierto en la captura de pantalla a continuación). Las reglas se aplican en el orden en que se guardan. Se pueden reordenar arrastrando y reorganizando el orden de ellas. Si hay varios roles disponibles para un usuario, la aplicación puede especificar la función con el parámetro CustomRoleEearn.

 Usando el rol predeterminado todos los usuarios autenticados se asociarán al rol autenticado (que en el caso del control granular es el rol de administrador y tendrá acceso a la sección de configuración de seguridad de Kibana):

 

 

Ejemplo de unión de permisos mediante reglas

En la configuración predeterminada de los grupos de usuarios de Cognito, se asigna un conjunto de atributos a todos los usuarios, pero también se pueden agregar atributos personalizados como se puede ver en la captura de pantalla a continuación.

 

 

Usando estos atributos podemos crear reglas para asociar usuarios con diferentes roles de IAM, y estos roles pueden ser asociados con roles de Kibana por el administrador en la sección Seguridad de la interfaz de Kibana, como se mostró anteriormente. El usuario tendrá dentro de Kibana los permisos que establece el rol de Kibana. Si el rol de IAM no está asociado con un rol de Kibana, el usuario no tendrá acceso.

 

 

En el caso que se muestra a continuación, el usuario con el atributo Family_name «Ane» se está asociando con el rol de IAM denominado IAMLimitedUser. Este rol es un rol con la misma política de confianza que el rol autenticado en el lado de AWS, pero ha sido asociado por el administrador de Kibana (en la parte de seguridad de Kibana) con el rol kibana_user que es un usuario ordinario de Kibana sin acceso a la parte de seguridad.

 

 

En el siguiente ejemplo se puede observar a un usuario usando el rol nativo kibana_user de Kibana donde es posible notar la ausencia del bloqueo en el menú de la izquierda.

 

 

No es necesario utilizar grupos de usuarios del grupo de usuarios de Cognito; quién permite  asociar usuarios autenticados con roles de IAM en este escenario es el grupo de identidades de Cognito.

Al eliminar un grupo de Cognito, compruebe que está vinculado a un dominio de Elasticsearch y elimine primero el dominio de Elasticsearch y, a continuación, el grupo de Cognito.

 

Paso 7: Solución de problemas

Cuando se utiliza el control de acceso granular y la autenticación con Cognito, si no se realizan los ajustes de rol adecuados, Kibana muestra una página de inicio de sesión no funcional o una página de rol que falta, dependiendo del error de configuración:

 

 

ARN de IAM del usuario maestro de control de acceso granular distinto del rol Autenticado del grupo de identidades de Cognito:

 

 

Le sugerimos que siga los pasos para validar la configuración cuando experimente problemas con la autenticación de Kibana a través de Cognito:

  • Revise la política de confianza delos roles utilizados.
  • Compruebe que el rol Cognito Autenticated es el mismo rol que el usuario maestro de Elasticsearch.
  • Revaluar la política de acceso del dominio Elasticsearch.

 

Enlaces útiles:

 

 

Sobre la autora

Maria Ane Dias es Arquitecta de Soluciones en AWS le gusta trabajar en seguridad, desarrollo de IoT más allá de la fabricación vertical y ayudar a iniciar a los clientes en su camino hacia la nube. Tiene 16 años de experiencia en desarrollo de software y arquitectura.

 

 

Agradecimientos a los revisores: Daniel García: Especialista en seguridad de AWS; Rafael Gumiero, Lucas Lins: Arquitectos de soluciones de AWS.