O blog da AWS

Integrando o Acesso do Kibana com Cognito na AWS – Parte 2

Por Maria Ane Dias, Arquiteta de Soluções da AWS Brasil

 

12 de setembro de 2022: Este blogpost foi atualizado para refletir o novo nome do AWS Single Sign-On (SSO) – AWS IAM Identity Center. Leia mais sobre a mudança de nome aqui.

No momento de criar um domínio do Amazon Elasticsearch Service é possível escolher que a autenticação do Kibana seja feita usando o Amazon Cognito.

O Amazon Cognito permite adicionar cadastramento, login e controle de acesso de usuários a aplicativos web e móveis com rapidez e facilidade. O Amazon Cognito escala até milhões de usuários e oferece suporte a login com provedores de identidade social como Facebook, Google e Amazon, além de provedores de identidade empresariais por meio de SAML 2.0.

O Amazon Cognito possui dois componentes, sendo que o User Pool é o que faz a autenticação do usuário, com a possibilidade dele se autenticar usando uma base de usuários local ao serviço ou integrações com outros serviços: Facebook, Google, Amazon, Apple, OpenIDConnect e SAML 2.0 através da configuração de Identidade Federada (menu a esquerda embaixo na imagem):

Usando a integração por SAMLv2 é possível usar o AWS IAM Identity Center (sucessor do AWS Single Sign-On), onde o administrador do Single Sign On faz a configuração da aplicação Kibana no AWS IAM Identity Center (sucessor do AWS Single Sign-On) e informa o arquivo SAML para que o mesmo seja configurado no Cognito User Pool. Isto não será explicado neste blogpost, mas, este blog post explica melhor como fazer esta integração com o AWS AWS IAM Identity Center (sucessor do AWS Single Sign-On)..

Passo 1: Criação do User Pool e do Identity Pool no Cognito

Antes de criar o domínio do Elastisearch é preciso criar e configurar o Cognito User e Identity pools.

Durante a criação do User Pool escolha um nome de domínio para o pool e selecione as configurações padrão (default). Depois, entre no User Pool e faça a Configuração do nome de domínio, menu a esquerda “Domain Name”:

Depois que o usuário se autenticou (no User pool) ele precisa de autorização (credenciais temporárias AWS baseada em roles), neste momento entra em cena o Identity Pool. É ele que irá associar o usuário autenticado a um role (perfil) para que este possa executar operações através das APIs da AWS. Como neste caso o role está sendo usado para acessar uma aplicação (Kibana), associamos as permissões ao authenticated role (veja como criá-lo no passo 2).

 O Cognito permite também configurar uma associação a um role não autenticado – “Unauthenticated role”, para acesso de usuários a recursos mesmo sem autenticação (visitantes). No entanto, como queremos apenas prover acesso a usuários efetivamente autenticados, não faremos esta configuração. Há também a opção de associar usuários a roles AWS específicos, ferramenta útil quando usada em conjunto com o Controle de Acesso Granular do Kibana e que veremos mais adiante.

Passo 2: Criando IAM Roles para o Identity Pool

 No processo de configuração de autenticação, será necessário criar ao menos um role do IAM para o Authenticated User que será associado ao Identity Pool.

 Para que o usuário receba credenciais do IAM através do Cognito Identity pool, o role precisa ter uma Trust Policy associada. A Trust Policy é a configuração que permite ao Cognito executar uma operação de assume role (AssumeRoleWithWebIdentity).

No quadro abaixo apresentamos um exemplo de uma Trust Policy para o Cognito Identity Pool. Note que o ID a ser usado é o do Identity Pool. O role será do tipo “Web Identity”, conforme imagem abaixo. Caso este role seja usado para acessar outro serviço da AWS além do Kibana, selecione a política conforme o serviço acessado. Caso o acesso seja exclusivo ao Kibana pode-se deixar sem política de acesso.

Como vai ficar a trust policy do role:

{

  "Version": "2012-10-17",

  "Statement": [

    {

      "Effect": "Allow",

      "Principal": {

        "Federated": "cognito-identity.amazonaws.com"

      },

      "Action": "sts:AssumeRoleWithWebIdentity",

      "Condition": {

        "StringEquals": {

               "cognito-identity.amazonaws.com:aud": "us-east-1:xxxxxxxx-c0cb-xxxx-b.... (COGNITO Identity pool ID aqui)"

        },

        "ForAnyValue:StringLike": {

          "cognito-identity.amazonaws.com:amr": "authenticated"

        }

      }

    }

Após criar o role, configure-o no Identity Pool do Cognito na opção de Authenticated role, conforme imagem abaixo:

Se a intenção for usar múltiplos perfis de acesso ao Kibana serão necessários vários roles do IAM, um role para cada perfil com permissões diferenciadas que serão associados aos usuários autenticados.

Passo 3: Selecionando os Pools do Cognito no Elasticsearch

Ao criar ou editar seu domínio do Elasticsearch você passará pela tela onde o User Pool e o Identity Pool devem ser selecionados, conforme imagem abaixo. Nesta mesma tela, no caso de criação de um domínio novo, estará a opção de habilitar ou não o controle de acesso granular do Elasticsearch.

Opção de controle de acesso granular e Cognito

Existem duas formas distintas de configurar as permissões de acesso ao ElasticSearch usando o Cognito: acesso padrão e controle de acesso granular.

Sem controle de acesso granular:

Caso você não esteja usando a opção de Controle de Acesso Granular do Elasticsearch, todos os usuários serão associados ao mesmo authenticated role do Cognito Identity Pool, pois, todos os usuários terão as mesmas permissões de acesso ao Kibana. Neste caso não existe distinção de permissões de acesso  entre usuários ao Kibana.

Controle de acesso granular com base interna de usuários no Elasticsearch:

A opção de Controle de acesso granular criando uma base interna de usuários na instância do Elasticsearch não é compatível com o gerenciamento de usuários pelo Cognito (os usuários estão em um banco interno da instância ou no Cognito User Pool) – sendo que no User Pool, conforme explicado na Parte 1 deste BlogPost eles se tornam reutilizáveis em outros domínios e aplicações e não perdidos caso o domínio seja apagado. Portanto, assume-se aqui que se o usuário optou por Controle de Acesso Granular com Cognito ele está usando a opção de Master User.

Controle de acesso granular com master user e base de usuários no Cognito – esta é a opção que continuará sendo explicada neste blogpost:

No caso do controle de acesso granular com Cognito (master user) é possível associar roles diferentes do Kibana a roles diferentes da AWS,  permitindo assim um controle granular do que pode ser acessado por quem dentro do Kibana. Isso é feito através do AWS Identity and Access Management (IAM).

 No momento de criar o domínio do Elasticsearch, ao preencher o IAM ARN do usuário mestre de controle de acesso granular (seção da configuração apresentada na figura abaixo), deve ser usado o mesmo Authenticated role do Cognito Identity Pool.

Passo 4: Configurando a política de domínio no Elasticsearch

Ao criar o domínio do Elasticsearch e habilitar o Cognito basta selecionar o Pool de usuários e o pool de identidade que já devem estar criados e configurados conforme explicado acima. E caso queira configurar o controle de acesso granular, colocar o IAM ARN do role “authenticated role” como master user.

Para maior segurança, na configuração de política de acesso ao domínio do Elasticsearch é sugerido limitar acesso ao ARN do(s) role(s) do Cognito, que ficará conforme abaixo – note que o domínio não está aberto, uma vez que só usuários associados a estes roles podem acessar o domínio:

{

  "Version": "2012-10-17",

  "Statement": [

    {

      "Effect": "Allow",

      "Principal": {

        "AWS": [

          ["arn:aws:iam::123456789012:role/Cognito_identitypoolAuth_Role",

           "arn:aws:iam::123456789012:role/IAMLimitedUser"]

        ]

      },

      "Action": [

        "es:ESHttp*"

      ],

      "Resource": "arn:aws:es:region:123456789012:domain/domain-name/*"

    }

  ]

}

 Caso esteja usando o Cognito sem o Controle de Acesso Granular, basta autorizar na política de acesso o authenticated role do Cognito Identity Pool, pois, como explicado no início, não tem como controlar quem acessa o que dentro da aplicação Kibana, logo não faz sentido ter um usuário limitado, por exemplo. No passo 6 veremos como configurar um usuário limitado, que depende do controle de acesso granular habilitado.

Passo 5: Acessando o Dashboard do Kibana

Após a criação do domínio integrado com o Cognito, o master user terá acesso ao Dashboard do Kibana. O link para o Kibana se encontra na tela inicial do domínio Elasticsearch e estará acessível conforme configuração (a parte de acesso – por exemplo via VPC – é explicada na parte 1 deste blogpost).

O usuário mestre do controle de acesso granular terá acesso à seção de “Segurança” na interface do Kibana (note o cadeado no menu esquerdo abaixo):

Na seção de Segurança é possível associar roles do Kibana (foto abaixo) a roles da AWS (via IAM ARN do role).

Passo 6: Criando usuários com acesso limitado no Kibana

Para criar um usuário comum do Kibana, sem acesso à seção de configurações de Segurança, basta associar o role kibana_user do Kibana a um role da AWS e usar a associação específica de role do Cognito Identity Pool que será explicado abaixo.

Associação de usuários a roles específico no Cognito Identity Pool

No Cognito Identity Pool, configure a seção de Authentication Providers, onde você deve apontar para o Cognito User Pool, pois ele que irá prover a autenticação. Nesta parte é selecionado o Authenticated role, ou seja, aqui é possível associar usuários autenticados a roles específicos de acordo com regras pré-definidas (menu que aparece aberto na imagem abaixo). As regras são aplicadas na ordem em que são salvas. Elas podem ser reordenadas arrastando e reorganizando a ordem da regra. Se vários roles estiverem disponíveis para um usuário, seu aplicativo pode especificar a função com o parâmetro CustomRoleARN.

 Usando default role os usuários autenticados serão todos associados ao authenticated role (que no caso do controle granular é o role de administrador e terá acesso à seção de configurações de Segurança do Kibana):

 

Exemplo da associação de permissões usando regras

Na configuração padrão do Cognito User Pools, é atribuído um conjunto de atributos a todos os usuários, porém também podem ser adicionados atributos personalizados confome pode ser visto na imagem abaixo.

Usando estes atributos podemos criar regras para associar usuários a diferentes roles do IAM, e estes roles podem ser em seguida associados a roles do Kibana pelo administrador na seção de Segurança da interface do Kibana, como mostrado anteriormente. O usuário terá então dentro do Kibana as permissões que o role do Kibana definir. Caso o role do IAM não esteja associado a um role do Kibana, o usuário não terá acesso.

No caso mostrado abaixo, o usuário com o atributo Family_name “Ane” está sendo associado ao role do IAM chamado IAMLimitedUser. Este role é um role com a mesma trusted policy do Authenticated Role do lado AWS, mas ele foi associado pelo administrador do Kibana (na parte de segurança do Kibana) ao role kibana_user que é um usuário comum do Kibana sem acesso a parte de segurança.

No exemplo abaixo pode-se observar um usuário usando a role nativa do Kibana kibana_user em que é possível notar a ausência do cadeado no menu da esquerda.

Os grupos de usuários do Cognito User Pool não precisam ser utilizados, quem associa os usuários autenticados aos roles do IAM neste cenário é o Cognito Identity Pool.

 Ao excluir um pool do Cognito, verifique se ele está atrelado a um domínio do Elasticsearch e exclua primeiro o domínio do Elasticsearch e depois o Cognito pool.

Passo 7: Resolução de Problemas

Ao usar controle de aceso granular e autenticação com Cognito, se as configurações de role adequadas não forem feitas, o Kibana exibirá uma página de início de sessão não funcional ou uma página de missing role, dependendo do erro de configuração:

IAM ARN do usuário mestre de controle de acesso granular diferente do Authenticated role do Cognito Identity Pool:

Sugerimos seguir os passos para validar as configurações quando tiver problemas na autenticação do Kibana através do Cognito:

  • Revise a trusted policy dos roles utilizados.
  • Cheque se o Authenticated role do Cognito é o mesmo role do usuário mestre do Elasticsearch.
  • Revise a política de acesso do domínio do Elasticsearch.

Links Úteis:

 

Sobre a autora

Maria Ane Dias é arquiteta de soluções na AWS e gosta/atua bastante da área de Segurança, Desenvolvimento e IoT além da vertical de Manufatura. Atua auxiliando clientes iniciantes em suas jornadas para a nuvem. Tem 16 anos de experiência em desenvolvimento e arquitetura de software e 2 com arquitetura de soluções.

 

 

 

 

Agradecimento aos revisores: Daniel Garcia: Especialista em Segurança da AWS; Rafael Gumiero e Lucas Lins: Arquitetos de Solução da AWS.