Como manter seus Clusters Elasticsearch seguros com o Kerberos | Elastic Blog
Engineering

Como manter seus Clusters Elasticsearch seguros com o Kerberos

O cão de guarda dos seus dados

A Elasticsearch 6.4 adicionou suporte a autenticação do Kerberos para assinaturas Platinum, que é o primeiro passo em direção a uma Elastic Stack totalmente Kerberizada. O Kerberos é uma tecnologia robusta que permite a autenticação segura em sistemas distribuídos. Ele oferece acesso único a diferentes serviços sem que você precise repetidamente informar um nome de usuário e senha. Este post mostra como configurar a Elasticsearch para ser compatível com a autenticação do Kerberos para tráfego HTTP.

Visão Geral da Implantação

Vamos considerar um cenário simples no qual a usuária Alice tenha um cluster Elasticsearch de nodo único. Alice já tem um reino Kerberos, demo.local, e quer proteger o cluster da Elasticsearch usando a autenticação Kerberos. O servidor de autenticação Kerberos tem autoridade para autenticar um usuário, host ou serviço dentro do reino. Os comandos usados neste artigo se referem à implementação MIT Kerberos. Consulte a documentação do MIT Kerberos para saber mais.

Nessa situação simples, há três máquinas de host:

  • Host-1 (kdc.demo.local): O Kerberos Key Distribution Center (KDC), normalmente com as funções de Authentication Server e Ticket Granting Server.
  • Host-2 (es.demo.local): É aqui que fica o cluster de nodo único da Elasticsearch.
  • Host-3 (client.demo.local): É onde o cliente da Elasticsearch está.

SimpleESKerberosDeployment

Veja os passos para garantir uma autenticação de sucesso com o Kerberos:-

  1. Alice (alice@DEMO.LOCAL) acessa a máquina do cliente (client.demo.local) com suas credenciais.
  2. A máquina do cliente exige um Ticket Granting Ticket (TGT) do servidor KDC (kdc.demo.local).
  3. O cliente acessa o serviço Elasticsearch https://es.demo.local:9200, que devolve uma resposta com um código de status de HTTP de Unauthorized(401) e inclui o cabeçalho WWW-Authenticate: Negotiate.
  4. O cliente solicita um ticket de sessão do Ticket Granting Server (TGS) para o serviço Elasticsearch principal HTTP/es.demo.local@DEMO.LOCAL. O nome principal do serviço Elasticsearch é derivado do url usado para acessar o serviço.
  5. O cliente apresenta seu ticket para o serviço Elasticsearch para autenticação.
  6. O serviço Elasticsearch valida o ticket do Kerberos e concede acesso (se o ticket for válido).

Vamos configurar o reino Kerberos

Para habilitar o reino Elasticsearch Kerberos, você precisará da infraestrutura Kerberos:

  • Relógios sincronizados em todas as máquinas participantes no domínio.
  • Um domínio DNS funcionando para todas as máquinas participantes.
  • Um servidor KDC.
  • Os nodos de cliente instalados com as bibliotecas Kerberos e arquivos de configuração como kinit, klist.

Tendo a estrutura Kerberos, você precisará das seguintes informações:

  • Arquivo de configuração Kerberoskrb5.conf --- Esse arquivo contém as informações necessárias do seu ambiente Kerberos como o reino padrão, servidores KDC e mapas de reino do domínio. Em um sistema Linux, esse arquivo costuma estar localizado no diretório /etc. A propriedade do sistema JVM java.security.krb5.conf deve ser definida para o caminho completo desse arquivo de configuração. O JVM carregará essa configuração e a usará para encontrar as informações necessárias quando necessário.
  • Serviço Elasticsearch HTTPkeytab --- Um keytab é um arquivo que armazena pares de chaves principais e de criptografia. É a keytab usada pelo serviço Elasticsearch HTTP para validar tickets que chegam de clientes. Normalmente, os nomes do serviço do principal estariam no formato HTTP/es.demo.local@DEMO.LOCAL em que a classe do serviço é HTTP, es.demo.local é o nome de domínio totalmente qualificado para o host Elasticsearch e DEMO.LOCAL e o reino Kerberos. Esse arquivo precisa ser colocado no diretório config da Elasticsearch. *É importante proteger o arquivo usando permissões de somente leitura para os usuários que usam a Elasticsearch, porque o arquivo contém credenciais. O administrador do sistema Kerberos pode oferecer o arquivo keytab para o seu serviço.

Com os dois arquivos, já podemos continuar a configuração do reino Kerberos na Elasticsearch.

1. Configure as opções de JVM

Primeiro, precisamos editar o arquivo de opções de JVM (jvm.options) para configurar a propriedade do sistema JVM para o arquivo de configuração do Kerberos:

# Kerberos configuration
-Djava.security.krb5.conf=/etc/krb5.conf

2. Configure a Elasticsearch para o Kerberos

Depois, precisamos adicionar um reino Kerberos ao arquivo elasticsearch.yml:

# Kerberos realm
xpack.security.authc.realms.kerb1:
type: kerberos
    order: 1
    keytab.path: es.keytab

Isso configura o reino Kerberos (kerb1) do tipo kerberos , realm order 1 e o keytab.path que aponta para o arquivo keytab do serviço Elasticsearch (es.keytab) no diretório de configuração. Para mais informações, consulte a documentação como configurar um reino Kerberos.

3. Reinicie a Elasticsearch

Depois que a configuração estiver feita, o nodo da Elasticsearch precisará ser reiniciado.

4. Mapear usuários em funções no Kerberos

O Kerberos é um protocolo de autenticação que não oferece detalhes da autorização. Para a autorização, podemos usar a API de mapeamento de funções para mapear usuários e funções. A opção a seguir cria um mapeamento de funções chamado kerbrolemapping, em que a função monitoring_user é atribuída ao usuário alice@DEMO.LOCAL:

$ curl -u elastic -H "Content-Type: application/json" -XPOST http://es.demo.local:9200/_xpack/security/role_mapping/kerbrolemapping -d 

{
    "roles" : [ "monitoring_user" ],
    "enabled": true,
    "rules" : {
    "field" : { "username" : "alice@DEMO.LOCAL" }
    }
}

Para saber mais sobre mapeamento de funções, consulte a documentação sobre mapear usuários e grupos em funções

E pronto!

Para verificar a autenticação na máquina do cliente, precisamos emitir o comando kinit para obter um Ticket Granting Ticket:

$ kinit alice@DEMO.LOCAL  
Password for alice@DEMO.LOCAL:  
$ klist  
Ticket cache: KEYRING:persistent:1000:krb_ccache_NvNtNgS  
Default principal: alice@DEMO.LOCAL  

Valid starting      Expires             Service principal
31/08/18 02:20:07   01/09/18 02:20:04   krbtgt/DEMO.LOCAL@DEMO.LOCAL

Depois, invocar curl com o parâmetro negotiate para que a autenticação do Kerberos do HTTP possa ser realizada:

$ curl --negotiate -u : -XGET http://es.demo.local:9200/

e pronto!

{
    "name" : "Lw7K29R",
    "cluster_name" : "elasticsearch",
    "cluster_uuid" : "qd3iafXORLy0VCfVD_Hp9w",
    "version" : {
    "number" : "6.4.0",
    "build_flavor" : "default",
    "build_type" : "tar",
    "build_hash" : "595516e",
    "build_date" : "2018-08-17T23:18:47.308994Z",
    "build_snapshot" : true,
    "lucene_version" : "7.4.0",
    "minimum_wire_compatibility_version" : "5.6.0",
    "minimum_index_compatibility_version" : "5.0.0"
    },
    "tagline" : "You Know, for Search"
}

Conclusão

Vimos como é fácil configurar um reino Kerberos depois que você tem acesso ao keytab principal do serviço e ao arquivo de configuração do reino Kerberos necessários para a Elasticsearch. A compatibilidade do Kerberos com a Elasticsearch é só o começo e vamos continuar lançando suporte a outros componentes da Elastic Stack nas próximas atualizações. Fique ligado!