Apresentando chaves de API unificadas para Elastic Cloud Serverless e Elasticsearch

Imagine você um engenheiro de confiabilidade de sistemas (SRE) responsável por uma frota crescente de projetos do Elastic Cloud Serverless: Elastic Observability para sua infraestrutura de produção, Elastic Security para sua equipe do centro de operações de segurança (SOC) e Elasticsearch para sua aplicação voltada ao cliente. Cada projeto tem a própria chave de API do Elasticsearch. Seu pipeline de integração contínua e entrega contínua (CI/CD) precisa de uma chave separada da Cloud API para provisionar e gerenciar esses projetos. O dia de rotação chega todo trimestre: você passa por cada projeto, gera novas chaves, atualiza o state do Terraform, reimplanta os pipelines e torce para que nada fique para trás. Quando um incidente acontece às 2h e é preciso revogar o acesso rápido, você se vê comparando uma planilha de credenciais para saber qual chave pertence a qual projeto e a qual serviço.

Hoje, essa história fica muito mais simples. Chaves de API do Elastic Cloud agora podem ser usadas para autenticar diretamente em comparação a APIs do Elasticsearch e Kibana no Elastic Cloud Serverless. Agora você pode usar uma única credencial para gerenciar os recursos da sua organização e executar operações de dados, como a Elasticsearch Query Language (ES|QL), ingestão de dados e alertas.

Vamos ver por que construímos isso, como projetamos uma camada de identidade distribuída globalmente para possibilitar o recurso e como ele estabelece a base para a busca entre projetos.

O ônus da gestão de segredos

Construir pipelines confiáveis de CI/CD, fluxos de trabalho GitOps ou automação Terraform em plataformas de dados tem um custo oculto: a proliferação de segredos.

No modelo anterior, os desenvolvedores lidavam com uma história de autenticação desarticulada:

• Plano de controle (chaves da API do Elastic Cloud): chaves com escopo organizacional usadas para criar projetos, convidar usuários e gerenciar as cobranças via API do Elastic Cloud.
• Plano de dados (chaves da API do Elasticsearch): Chaves com escopo de projeto criadas dentro de um projeto Serverless específico para interagir com as APIs do Elasticsearch e do Kibana.

Nesse caso, seu script de implantação precisava se autenticar no Elastic Cloud, provisionar um projeto Serverless, extrair uma chave de API do Elasticsearch recém-criada desse projeto específico e, em seguida, inserir essa segunda chave na aplicação ou na ferramenta de automação mais adiante, o que resultava em pipelines complexos, logs de auditoria fragmentados e maior risco de vazamento de credenciais.

Autenticação unificada no Elastic Cloud Serverless

Com este lançamento, a separação para projetos Serverless foi eliminada. Agora você pode criar uma chave de API do Elastic Cloud explicitamente autorizada para nuvem, Elasticsearch e Kibana APIs.

• Antes: a chave de API do Elastic Cloud era estritamente um token do plano de controle. Ela podia criar projetos, gerenciar cobranças e convidar usuários, mas tinha um limite rígido; não podia ser usada para chamar as APIs do Elasticsearch nem Kibana dentro desses projetos. Você sempre precisava de uma segunda chave específica do projeto para operações de dados.
• Agora: ao ter acesso a nuvem, Elasticsearch e a API Kibana ao criar uma chave de API do Elastic Cloud, o limite rígido é retirado para o Serverless. Essa chave de API se torna uma credencial verdadeiramente unificada. Ela mantém a capacidade de gerenciar a infraestrutura da sua organização, ao mesmo tempo que ganha acesso nativo para consultar, ingerir e analisar dados em qualquer projeto Serverless autorizado.

Ao unificar tudo sob uma única chave de API do Elastic Cloud, você ganha uma única identidade que pode ter escopo definido, ser auditada, rotacionada e revogada como uma unidade. Cada chamada de API, seja para provisionar um novo projeto ou executar uma consulta ES|QL, aparece sob a mesma credencial nos seus logs de auditoria, fornecendo um único rastro a ser seguido durante investigações de incidentes ou revisões de conformidade. A rotação de credenciais agora é feita em uma etapa em vez de ser uma atualização coordenada em segredos separados do plano de controle e do plano de dados. E, como as alocações de função são por projeto, uma só chave pode abranger vários projetos, gerenciando a ingestão no seu projeto de observabilidade e executando consultas no seu projeto de segurança, sem precisar lidar com credenciais separadas para cada um.

Importante: unificado não significa todo-poderoso. Ao usar a carga útil role_assignments, você pode definir uma chave unificada estritamente para um único projeto e uma função específica (como somente leitura), garantindo que o raio de explosão continue totalmente contido caso uma credencial seja exposta. Se um desenvolvedor sair ou uma aplicação for desativada, você pode revogar uma única chave do console Elastic Cloud, encerrando imediatamente o acesso tanto no plano de controle quanto em todos os projetos Elasticsearch associados.

(Atenção: nas implantações Elastic Cloud Hosted/gerenciadas, as chaves da API da nuvem ainda gerenciam apenas o plano de controle. O suporte para estender isso às APIs de pilha hospedada está planejado para uma versão futura.)

Automatizando seus fluxos de trabalho

Começar é simples. Você pode configurar inteiramente no console Elastic Cloud ou automatizar usando a API do Elastic Cloud.

O processo da IU não muda, mas agora você pode selecionar Nuvem, Elasticsearch e API Kibana na alocação de função do projeto.

Veja como criar uma chave unificada programaticamente usando a API do Elastic Cloud. Observe o application_roles conjunto, pois é o que concede ao principal acesso nativo ao plano de dados do Elasticsearch:

Uma vez criado, você passa exatamente essa mesma chave no cabeçalho Authorization: ApiKey tanto para api.elastic-cloud.com quanto para seus endpoints específicos do Serverless Elasticsearch.

Nos bastidores: construindo uma camada de identidade distribuída

Fazer uma chave da API da nuvem funcionar tanto no plano de controle quanto no plano de dados não é tão simples como passar um token. É preciso resolver um desafio fundamental nos sistemas distribuídos.

Historicamente, as chaves de API da nuvem ficavam em um cluster de segurança global centralizado. Isso funciona nas operações de plano de controle cuja latência mais alta é aceitável. No entanto, requisições de dados do Elasticsearch exigem latência ultrabaixa. Não podemos viajar pelo globo até um plano de controle central para validar cada busca ou solicitação de ingestão.

Para resolver, introduzimos uma nova arquitetura de autenticação apoiada por um datastore distribuído globalmente. O diagrama sequencial a seguir mostra um cliente enviando uma consulta Elasticsearch, usando uma chave API do Elastic Cloud, ilustrando como a autenticação ocorre inteiramente dentro da região, sem a viagem por todo o plano de controle global. O Elasticsearch delega a autenticação ao Serviço IAM Regional, que valida a chave e resolve as alocações de função em uma réplica local do banco de dados distribuído globalmente. Uma vez autorizado, o Elasticsearch executa a consulta e retorna os resultados ao cliente.

Persistência distribuída globalmente

Em vez de depender exclusivamente de um cluster de segurança centralizado, as chaves de API do Elastic Cloud e as respectivas definições de função agora ficam em um banco de dados globalmente distribuído e de alta disponibilidade. Esse banco de dados sincroniza os dados de gerenciamento de identidade e acesso (IAM) no plano de controle global e nos planos de dados regionais onde seus projetos Serverless são executados.

Validação local com IAM regional

Quando seu cliente envia uma requisição para o Elasticsearch usando uma chave API do Elastic Cloud, a solicitação não retorna ao plano de controle global. Em vez disso, ela é encaminhada para o novo serviço regional IAM. Ele valida a chave em relação à réplica do banco de dados local, garantindo que a autenticação ocorra com latência quase zero e completamente isolada de interrupções no plano de controle global.

Mapeamento dinâmico de funções

A autenticação é metade do caminho; o sistema também precisa autorizar a solicitação. O serviço IAM regional traduz na hora suas alocações de função no nível da nuvem, por exemplo, application_roles), em privilégios nativos do Elasticsearch. O Elasticsearch pode então autorizar e executar a solicitação no local, sem precisar de um .security índice local.

A base para a busca entre projetos

Essa arquitetura de identidade distribuída é um elemento fundamental para o futuro da plataforma Elastic.

Como a identidade e o acesso agora estão unificados e sincronizados globalmente, temos o framework necessário para transmitir sua identidade com segurança entre diferentes projetos. Isso possibilita as futuras capacidades de Busca Cruzada por Projetos (CPS) para Serverless.

Com o CPS, você poderá consultar dados que abrangem vários projetos Serverless remotos, como combinar cargas de trabalho de segurança e observabilidade, como se fossem um único conjunto de dados. Ao depender de chaves de API unificadas, o sistema pode avaliar automaticamente suas permissões simultaneamente em todos os projetos, sem exigir que você configure relacionamentos de confiança complexos, certificados ou credenciais duplicadas em cada projeto-alvo.

Saiba mais

Pronto para simplificar sua pilha?

• Leia a documentação das chaves de API do Elastic Cloud para aprender como atribuir acesso ao stack.
• Confira a referência Criar chave de API (Elastic Cloud API) para automatizar a geração de chaves.
• Consulte Chaves de API Elastic para uma comparação completa dos tipos de chave em toda a plataforma Elastic.

Comece ou continue construindo no Elastic Cloud hoje.

Aviso de isenção

O lançamento e o tempo de amadurecimento de todos os recursos ou funcionalidades descritos neste artigo permanecem a exclusivo critério da Elastic. Os recursos ou funcionalidades não disponíveis no momento poderão não ser entregues ou não chegarem no prazo previsto.