Observabilidade e segurança modernas no Kubernetes com Elastic e OpenTelemetry

A natureza estruturada do Kubernetes proporciona um meio reproduzível e escalável de implantar e gerenciar serviços e aplicações. Isso levou à adoção generalizada em mercados verticais para modelos de implantação local e na nuvem. A natureza autônoma da operação do Kubernetes, no entanto, exige observabilidade e segurança abrangentes e totalmente convergentes. Hoje, isso é possível de forma exclusiva com o uso da plataforma da Elastic.

Neste artigo, discutimos as práticas recomendadas para observar e proteger fluxos de trabalho de aplicações e serviços no Kubernetes usando o Elasticsearch e o OpenTelemetry. Você aprenderá a:

• Implantar e configurar o Elastic Agent no seu cluster do Kubernetes
• Fazer a ingestão de traces, métricas e eventos de aplicação do OpenTelemetry usando o Elastic Agent
• Fazer a ingestão de logs de container do Kubernetes, métricas de cluster e padrões de tráfego de rede usando o Elastic Agent
• Usar o Elastic Defend para adicionar monitoramento centrado na segurança e proteção contra ameaças ao seu cluster do Kubernetes
• Familiarizar-se com os dashboards prontos para uso da Elastic para observar, correlacionar e realizar análises de causa raiz de problemas operacionais

Os silos de dados representam um desafio para solucionar problemas em implantações do Kubernetes

Historicamente, o setor considerava a observabilidade das aplicações, a observabilidade da infraestrutura e a segurança da infraestrutura como domínios distintos, cada um controlado por ferramentas distintas gerenciadas por equipes distintas. Esse modelo, embora muitas vezes conveniente do ponto de vista organizacional, expõe rapidamente um ponto problemático comum e um teto de vidro:

Analistas (humanos ou máquinas) precisam se basear em dados coletados na observabilidade das aplicações, na observabilidade da infraestrutura e na segurança da infraestrutura para determinar se um problema operacional é um problema com a infraestrutura, um defeito em uma aplicação ou uma falha de segurança. Além disso, os especialistas também precisarão de acesso a dados de total fidelidade de todas essas três fontes para identificar a causa raiz de um determinado problema.

Como solução alternativa, os clientes costumam duplicar dados selecionados de observabilidade em várias plataformas de dados. Na melhor das hipóteses, isso dobra ou triplica o custo de armazenamento de dados, suporte e treinamento. Na pior das hipóteses, faltam aos analistas dados cruciais necessários para identificar a causa raiz de um problema. Isso é ainda mais exacerbado pela natureza dinâmica e escalável do Kubernetes. Indiscutivelmente, separar as plataformas de observabilidade e segurança é um antipadrão para o modelo integrado de implantação de serviços que o Kubernetes oferece. 

Um momento oportuno para a observabilidade

Em última análise, desenvolvedores, operadores e analistas de segurança precisam de uma visão unificada de ponta a ponta de seu sistema, abrangendo aplicações e infraestrutura. As equipes de implantação de infraestrutura precisam de um padrão de implantação unificado e nativo do Kubernetes para fornecer essa visibilidade e proteger seus clusters.

Isso requer três elementos facilitadores:

1. Todos os dados de observabilidade e segurança, incluindo os de logs, traces, eventos e métricas de aplicações, serviços e infraestrutura, devem ser armazenados em uma plataforma de dados unificada de maneira otimizada tanto para busca (correlação e latência) quanto para armazenamento (custo).
2. A plataforma de dados unificada também deve ser capaz de correlacionar dados e apresentá-los de maneira específica para cada função: por exemplo, se um analista está tentando descobrir a causa raiz de um problema, a plataforma deve orientar o analista em direção ao provável problema e permitir que ele interaja perfeitamente com os dados sem se preocupar com sua forma ou fonte subjacente.
3. As aplicações e a infraestrutura de instrumentação devem estar alinhadas com o mantra do Kubernetes: implantações reproduzíveis e escaláveis sem configuração sob medida.

Elastic: você sabe, para o Kubernetes

Um nexo de tecnologia impulsionado pela Elastic, pelo OpenTelemetry, pelo Kubernetes e pelo hardware de computação moderno tornou a observabilidade e a segurança nativas do Kubernetes em escala real disponíveis hoje:

• O OpenTelemetry é um catalisador para desenvolvedores (tanto internos quanto terceirizados) para instrumentar totalmente todas as aplicações e serviços, dissociando a seleção de fornecedores de APM da implementação do APM
• O hardware de computação moderno com CPU e RAM abundantes torna o tracing “sempre ativo” e prático sem impacto no desempenho, mesmo para aplicações em tempo real
• A arquitetura mais recente da Elastic, incluindo os snapshots buscáveis e o novo fluxo de dados de séries temporais, combinados com a amostragem inteligente baseada na conclusão do trace do Elastic APM, faz com que o armazenamento online de dados abrangentes de observabilidade e segurança de vários anos se torne prático e acessível
• A implantação do Elastic Agent no DaemonSet em cada nó do Kubernetes permite a implantação reproduzível e escalável de um coletor de dados unificado controlado remotamente. Depois de implantados, os Elastic Agents podem ser gerenciados como uma frota para adicionar, configurar ou remover integrações de dados de maneira trivial.
• A plataforma da Elastic fornece uma solução de segurança do Kubernetes totalmente integrada, abrangendo proteção, observação e gerenciamento de postura
• O Elasticsearch permite correlação e orientação em todas as fontes de dados coletadas usando dashboards prontos para uso, detecção de anomalia e alertas

Modelo de coleta de dados

Como você pode ver no diagrama a seguir, estamos recomendando um modelo híbrido para coleta de dados de observabilidade e segurança, contando com o Elastic Agent para obter métricas de infraestrutura do Kubernetes e logs de container de aplicações em conjunto com o agente de APM do OpenTelemetry para obter traces de aplicações, eventos de trace e métricas. A justificativa para essa abordagem é descrita em detalhes abaixo.

Dados de traces, eventos e métricas de aplicações

A geração de traces e métricas de aplicações geralmente requer a infusão direta de uma biblioteca de APM no código da aplicação. No entanto, podemos remover a dependência de um determinado fornecedor como barreira à adoção do APM usando agentes de APM do OpenTelemetry. Até o momento, o OpenTelemetry dedicou a maior parte de seus esforços a implementações de agente robustas e padronizadas para capturar traces de aplicações e eventos de trace, com suporte emergente para métricas de aplicações. Agentes razoavelmente maduros existem hoje para quase todas as linguagens de programação populares. Em muitos casos, você pode usar a instrumentação automática para instrumentar suas aplicações com pouco ou nenhum esforço de codificação. Se suas aplicações foram escritas em .NET, Java, NodeJS ou Python e fazem uso de frameworks típicos, você pode até mesmo injetar bibliotecas de APM em tempo de execução usando o operador de Kubernetes do OpenTelemetry!

A análise de causa raiz exige que os dados de APM sejam correlacionados com logs de aplicações e métricas da infraestrutura. Para habilitar essa correlação, precisamos que certos metadados de identificação, ou atributos de recursos, sejam comuns nos logs e tracing de aplicações e nas métricas de infraestrutura. A plataforma da Elastic usa service.name, pod.uid e container.id para vincular dados de observabilidade de aplicações em execução no Kubernetes. Historicamente, as bibliotecas de APM “espiavam” fora de seus limites para obter esses metadados. Algumas das bibliotecas de APM do OpenTelemetry atualmente oferecem suporte para essa funcionalidade (Java, por exemplo), enquanto outras não (Rust). Embora simplifique a implantação, essa abordagem está longe de ser ideal: os agentes de APM (executados no contexto de uma aplicação) precisam não apenas determinar seu ambiente de tempo de execução (Docker, Kubernetes etc.), mas também exigir permissão suficiente para acessar esses identificadores (por exemplo, acesso a /proc/self/cgroup ou às APIs do Kubernetes). O último é, obviamente, uma preocupação de segurança em potencial. Como tal, queremos idealmente contar com entidades externas para passar esses metadados (como variáveis de ambiente) ou para anexar esses metadados após a criação dos dados de trace. Para anexar o container.id de maneira confiável aos dados de trace independentemente da biblioteca de APM do OpenTelemetry em uso, implantamos um OpenTelemetry Collector configurado com o processador k8sattribute em execução no DaemonSet do nó.

Depois que os dados do APM foram marcados com metadados correspondentes do Kubernetes, eles são encaminhados do OpenTelemetry Collector para um Elastic Agent também em execução no DaemonSet do nó. O Elastic Agent foi configurado via Fleet com a integração de APM. Distribuir a integração do APM em cada DaemonSet do nó ajuda a distribuir a carga de ingestão do APM e vincula mais estreitamente sua disponibilidade às aplicações às quais ele dá suporte. Além disso, ele mantém o tráfego de GRPC/HTTP2 local para o próprio DaemonSet, evitando as complexidades de balanceamento de carga do GRPC/HTTP2. Por fim, a segurança é simplificada: o OTLP pode ficar sem segurança no nó, com a segurança TLS do Elastic Agent gerenciada pelo Fleet empregada entre o nó e o cluster do Elasticsearch. A integração de APM da Elastic converte os dados de traces, métricas e eventos do OpenTelemetry para o Elasticsearch Common Schema (ECS). Os documentos resultantes são então enviados ao Elasticsearch para serem ingeridos e indexados.

Logs de container e métricas de infraestrutura do Kubernetes

Embora o padrão do OpenTelemetry seja compatível com logging, as implementações ainda estão sendo elaboradas. Como tal, muitos dos agentes disponíveis ainda não oferecem suporte para a capacidade de conectar frameworks de logging. Na prática, a ingestão de arquivos de log de container é o único meio prático de capturar dados de log das aplicações. Embora isso seja possível com o fileloreceiver do OpenTelemetry Collector, atualmente é de qualidade alfa e ainda não é recomendado para casos de uso de produção. O mesmo argumento se aplica ao k8sclusterreceiver destinado a capturar métricas de infraestrutura do Kubernetes.

Em comparação, a integração de Kubernetes da Elastic é robusta, comprovada e fornece coleta de logs de aplicações e métricas de infraestrutura do Kubernetes com total fidelidade. Além disso, nossa integração para Kubernetes pode ser gerenciada remotamente no Kibana no nível da frota, simplificando bastante a configuração. Ao contrário dos traces e métricas de aplicação, a integração de Kubernetes da Elastic opera fora do código da aplicação, reduzindo assim a preocupação com a dependência do fornecedor.

Além disso, a presença de um Elastic Agent no DaemonSet de cada nó tem valor muito além da integração de Kubernetes. Como você verá posteriormente neste artigo, aproveitaremos essa mesma instância do Elastic Agent para implantar o Elastic Defend a fim de monitorar e proteger nossos nós do Kubernetes.

Eventos de segurança e dados do host

Os fluxos de trabalho modernos de observabilidade e segurança do Kubernetes precisam estar em sintonia para permitir que os analistas identifiquem a causa raiz de um determinado problema. As soluções de segurança da Elastic fornecem soluções de SIEM, SOAR e XDR totalmente integradas e com recursos completos, incluindo proteção de endpoint.

Notavelmente, a integração do Elastic Defend fornece inerentemente uma observabilidade do Kubernetes muito maior. Nossa integração para Gerenciamento da Postura de Segurança do Kubernetes pode alertar suas equipes de desenvolvimento, DevOps e DevSecOps sobre possíveis problemas de configuração com as aplicações antes que eles sejam identificados pela sua equipe de segurança. Nosso dashboard de segurança do Kubernetes possibilita que os analistas entendam exatamente quais processos foram executados nos seus nós do Kubernetes, quando, com quais parâmetros de tempo de execução e sob qual conta! Esse nível sem precedentes de visibilidade do tempo de execução permite detectar ameaças de segurança imprevistas, introduzidas em camadas de container usadas como dependências nas suas aplicações em container.

Assim como a integração de APM da Elastic, essas integrações de segurança são adicionadas, configuradas e removidas via Fleet e executadas dentro do Elastic Agent no DaemonSet em cada nó do seu cluster do Kubernetes.

Vamos ao trabalho!

Requisitos

Você precisará de um cluster do Kubernetes no qual implantar seus apps, o Elastic Agent e o OpenTelemetry Collector. Gosto de usar o kOps para criar, gerenciar e excluir facilmente clusters de teste nos hiperescaladores. Para referência, um único t3.xlarge do AWS EC2 é suficiente para implantar a demonstração do OpenTelemetry e nosso Elastic Agent. Os exemplos aqui devem funcionar com qualquer cluster do Kubernetes autogerenciado ou gerenciado (por exemplo, EKS, GKE) em qualquer um dos principais hiperescaladores ou em ambiente local (por exemplo, OpenShift). Eles também devem teoricamente funcionar com clusters do Kubernetes de desktop (como MicroK8s ou o mecanismo do Kubernetes integrado do Docker), pressupondo que você conceda a esses ambientes RAM e CPU suficientes (por exemplo, 4 vCPUs e 16 GB de RAM). Você também precisará de conhecimento administrativo básico do Kubernetes (por exemplo, implantar yaml, verificar o status do pod e visualizar os arquivos de log do pod). Antes de começar, verifique se o contexto do Kubernetes está apontando para o cluster correto.

É claro que você também precisará de aplicações ou serviços que possam ser instrumentados com o OpenTelemetry. Para começar, você pode usar nossa bifurcação da demonstração do OpenTelemetry. A partir daí, você pode seguir nossas práticas recomendadas para instrumentar suas próprias aplicações e serviços.

Finalmente, você precisará de acesso a uma implantação moderna (8.5 ou superior) do Elasticsearch (você pode criar uma gratuitamente na nossa nuvem!), que seja acessível do seu cluster de aplicações do Kubernetes.

Ferramentas

Este tutorial pressupõe que você esteja usando um host baseado em Linux ou MacOS para configurar seu cluster do Kubernetes. Você precisará garantir que as seguintes ferramentas estejam instaladas:

• Helm
• curl
• patch

Criar seu cluster do Elasticsearch

Se você já tem uma implantação moderna do Elasticsearch para usar, ótimo! Caso contrário, vamos configurar uma criando um cluster de avaliação gratuita em cloud.elastic.co!

1. Navegue até cloud.elastic.co e inscreva-se para fazer uma avaliação gratuita (não é necessário cartão de crédito)
2. Dê o nome “o11y” ao seu cluster do Elasticsearch, por exemplo, e mantenha os valores padrão para as outras configurações
3. Clique em [ Create Deployment ] (Criar implantação)
4. Aguarde o Elasticsearch Cloud relatar que “Your deployment is ready!” (Sua implantação está pronta!)
5. Clique em [ Continue ] (Continuar) para fazer login no Kibana

Implantar o Elastic Agent no DaemonSet

Usaremos o Elastic Agent (com integrações) instalado no DaemonSet em cada nó do seu cluster do Kubernetes para fazer a ingestão dos dados no Elasticsearch.

1. Baixe o YAML a seguir (referenciado aqui) na sua máquina local. Usaremos esse YAML para implantar o Elastic Agent (com o Elastic Defend) no DaemonSet dos seus nós do Kubernetes.

curl -L -O https://raw.githubusercontent.com/elastic/endpoint/main/releases/8.5.0/kubernetes/deploy/elastic-defend.yaml 

2. Baixe o patch a seguir na sua máquina local. Esse patch aumenta as alocações padrão de RAM e CPU do container do Elastic Agent para acomodar confortavelmente todas as integrações que instalaremos. Em produção, você pode decidir implantar apenas um subconjunto das integrações abaixo, o que pode tornar essa modificação discutível.

curl -L -O https://raw.githubusercontent.com/ty-elastic/elastic-otel-k8s/main/agent/8.5.0/elastic-defend.yaml.patch 

3. Aplique o patch no local

patch elastic-defend.yaml elastic-defend.yaml.patch 

4. Verifique se você fez login no Kibana no seu cluster do Elasticsearch

5. Navegue até [ Management / Fleet ] (Gerenciamento/Fleet)

6. Clique em [ Add agent ] (Adicionar agente)

7. Nomeie a nova política como “k8s-apps”, por exemplo 

• A política “k8s-apps” será usada aqui para implantar integrações no DaemonSet de nós do cluster do Kubernetes da sua aplicação

8. Em [ Advanced options ] (Opções avançadas), defina [ Unenrollment timeout ] (Tempo limite de cancelamento de inscrição) como “3600” segundos 

• O Kubernetes pode criar e excluir nós dinamicamente; esta configuração garantirá que os Elastic Agents implantados em nós excluídos sejam removidos automaticamente

9. Clique em [ Create policy ] (Criar política)

10. Em [ Install Elastic Agent on your host ] (Instalar o Elastic Agent no seu host), selecione “Kubernetes”

11. Encontre o valor da variável “FLEET_URL” e copie-o para o valor de “FLEET_URL” no arquivo “elastic-defend.yaml” que você baixou e corrigiu anteriormente

12. Encontre o valor da variável “FLEET_ENROLLMENT_TOKEN” e copie-o para o valor de “FLEET_ENROLLMENT_TOKEN” no arquivo “elastic-defend.yaml” que você baixou e corrigiu anteriormente

13. Aplique elastic-defend.yaml ao cluster via:

kubectl apply -f elastic-defend.yaml 

14. Aguarde [ Confirm agent enrollment ] (Confirmar inscrição do agente) mostrar que “1 agent has been enrolled” (1 agente foi inscrito)

15. Aguarde [ Incoming data confirmed ] (Dados de entrada confirmados) mostrar "Incoming data received from 1 of 1 recently enrolled agent" (Dados de entrada recebidos de 1 de 1 agente inscrito recentemente)

16. Clique em “Close” (Fechar)

Você deve ter notado que a Elastic fornece o YAML de implantação do Elastic Agent pré-configurado quando você seleciona a opção de host do Kubernetes. Esse YAML de implantação ainda não inclui a imagem do Elastic Defend.

Configurar integrações do Elastic Agent

Agora vem a parte fácil! Com um Elastic Agent gerenciado pelo Fleet implantado no seu DaemonSet, é trivial adicionar/configurar/excluir integrações remotamente usando a interface de integrações do Kibana.

APM

A integração de APM da Elastic é usada para importar dados de APM do OpenTelemetry para o Elastic.

1. Navegue no Kibana até [ Management / Integrations ] (Gerenciamento/integrações)
2. Faça uma busca por “APM”
3. Clique em [ APM ]
4. Clique em [ Manage APM integration in Fleet ] (Gerenciar integração de APM no Fleet)
5. Clique em [ Add Elastic APM ] (Adicionar APM da Elastic)
6. Defina [ General / Server configuration / Host ] (Configuração geral/do servidor/host) como “0.0.0.0:8200”. Isso expõe a ingestão da integração de APM para outros pods (incluindo o OpenTelemetry Collector, também em execução no DaemonSet) no nó.
7. Desabilite [ Agent authorization / Anonymous Agent access ] (Autorização do agente/acesso de agente anônimo). Essa simplificação permite que o OpenTelemetry Collector envie dados do OTEL para a integração de APM da Elastic sem um token de autorização (principalmente, a integração de APM não é exposta fora do nó).
8. Opcionalmente, habilite [ Tail-based sampling ] (Amostragem baseada na conclusão do trace). Isso permite que a subamostragem inteligente de dados de trace capture anomalias e o desempenho geral, reduzindo os requisitos de armazenamento.
9. Defina [ Where to add this integration ] (Onde adicionar esta integração) como “Existing hosts” (Hosts existentes) e defina [ Agent policy ] (Política do agente) como “k8s-apps”
10. Clique em [ Save and continue ] (Salvar e continuar)
11. Clique em [ Save and deploy changes ] (Salvar e implantar alterações)

Kubernetes

Implantar o Kube State Metrics

A integração do Kubernetes requer que o kube-state-metrics esteja disponível no seu cluster do Kubernetes para habilitar os dashboards do Kubernetes prontos para uso.

1. Adicione o repositório do Helm kube-state-metrics

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts 

helm repo update 

2. Instale o kube-state-metrics no seu cluster do Kubernetes no mesmo espaço de nome do Elastic Agent (que, usando o yaml de implantação fornecido para o Elastic Agent, assume como padrão “kube-system”)

helm install --set namespaceOverride=kube-system kube-state-metrics prometheus-community/kube-state-metrics 

Instale a integração do Kubernetes

A integração de Kubernetes da Elastic é usada para importar métricas e logs do Kubernetes para o Elasticsearch.

1. Navegue no Kibana até [ Management / Integrations ] (Gerenciamento/integrações)
2. Faça uma busca por “Kubernetes”
3. Selecione [ Kubernetes ]
4. Clique em [ Add Kubernetes ] (Adicionar Kubernetes)
5. Habilite [ Collect Kubernetes metrics from kube-state-metrics ] (Coletar métricas do Kubernetes de kube-state-metrics) se ainda não estiver definido
6. Defina [ Where to add this integration ] (Onde adicionar esta integração) como “Existing hosts” (Hosts existentes) e defina [ Agent policy ] (Política do agente) como “k8s-apps”
7. Clique em [ Save and continue ] (Salvar e continuar)
8. Clique em [ Save and deploy changes ] (Salvar e implantar alterações)

Elastic Defend

A integração do Elastic Defend é usada para proteger seus nós do Kubernetes e coletar dados adicionais de observabilidade centrados na segurança.

1. Navegue no Kibana até [ Management / Integrations ] (Gerenciamento/integrações)
2. Faça uma busca por “Elastic Defend”
3. Selecione [ Elastic Defend ]
4. Clique em [ Add Elastic Defend ] (Adicionar Elastic Defend)
5. Defina o [ Integration name ] (Nome da integração) como “defend-1”
6. Navegue até [ Select configuration settings ] (Selecionar definições de configuração), defina [ Select the type of environment you want to protect ] (Selecione o tipo de ambiente que você quer proteger) como “Cloud Workloads (Linux servers or Kubernetes environments)” (Cargas de trabalho de nuvem (servidores Linux ou ambientes do Kubernetes)) e defina [ To reduce data ingestion volume, select Interactive only ] (Para reduzir o volume de ingestão de dados, selecione Somente interativo) como “All events” (Todos os eventos)
7. Defina [ Where to add this integration ] (Onde adicionar esta integração) como “Existing hosts” (Hosts existentes) e defina [ Agent policy ] (Política do agente) como “k8s-apps”
8. Se o cluster do Kubernetes não estiver em execução no GKE ou EKS, em [ Advanced options ] (Opções avançadas), defina [ Namespace ] (Espaço de nome) como “k8sapps”, por exemplo, onde “k8sapps” identifica o cluster do Kubernetes da sua aplicação. Isso é necessário para marcar a telemetria do Elastic Defend com o nome do cluster do Kubernetes ao qual ela se aplica.
9. Clique em [ Save and continue ] (Salvar e continuar)
10. Selecione [ Settings ] (Configurações)
11. Navegue até [ Elastic Defend version ] (Versão do Elastic Defend) e habilite “Keep integration policies up to date automatically” (Manter as políticas de integração atualizadas automaticamente)
12. Selecione [ Integration policies ] (Políticas de integração) e clique em [ defend-1 ]
13. Navegue até [ Type: Operating system / Event Collection: Linux ] (Tipo: sistema operacional/Coleta de evento: Linux) e habilite [ Capture terminal output ] (Capturar saída do terminal)
14. Clique em [ Save and continue ] (Salvar e continuar)
15. Clique em [ Save and deploy changes ] (Salvar e implantar alterações)

Alguns dashboards do Kubernetes do Elasticsearch exigem conhecimento do nome e do ID do cluster do Kubernetes. Se seu cluster estiver em execução no GKE ou EKS, o Elastic Agent obterá automaticamente esses metadados. Se você estiver executando um cluster do Kubernetes autogerenciado, poderá criar um pipeline de ingestão para adornar eventos de segurança com os campos orchestrator.cluster.name e orchestrator.cluster.id definidos automaticamente do espaço de nome da política que você definiu anteriormente.

1. Navegue até [ Management / Dev Tools ] (Ferramentas de gerenciamento/desenvolvimento)
2. Execute o seguinte:

Gerenciamento da Postura de Segurança do Kubernetes

A integração do Gerenciamento da Postura de Segurança do Kubernetes da Elastic é usada para validar seu cluster do Kubernetes e as aplicações em relação às práticas recomendadas para configuração segura do Kubernetes, conforme definido pelo Center for Internet Security (CIS). Isso permite que suas equipes de desenvolvimento e implantação detectem configurações incorretas antes que resultem em uma violação de segurança.

1. Navegue no Kibana até [ Management / Integrations ] (Gerenciamento/integrações)
2. Faça uma busca por “Kubernetes Security Posture Management”
3. Selecione [ Kubernetes Security Posture Management ] (Gerenciamento da Postura de Segurança do Kubernetes)
4. Clique em [ Add Kubernetes Security Posture Management ] (Adicionar Gerenciamento da Postura de Segurança do Kubernetes)
5. Defina [ Kubernetes Deployment ] (Implantação do Kubernetes) como “Unmanaged Kubernetes” (Kubernetes não gerenciado) (para Kubernetes autogerenciado) ou “EKS (Elastic Kubernetes Service)” se o cluster de aplicações do Kubernetes estiver sendo executado especificamente no AWS EKS
6. Defina [ Where to add this integration ] (Onde adicionar esta integração) como “Existing hosts” (Hosts existentes) e defina [ Agent policy ] (Política do agente) como “k8s-apps”
7. Clique em [ Save and continue ] (Salvar e continuar)
8. Clique em [ Save and deploy changes ] (Salvar e implantar alterações)

Captura de Pacotes de Rede

A integração da Captura de Pacotes de Rede da Elastic é usada para obter informações sobre o tráfego de rede que entra e sai dos seus nós do Kubernetes.

1. Navegue no Kibana até [ Management / Integrations ] (Gerenciamento/integrações)
2. Faça uma busca por “Network Packet Capture”
3. Selecione [ Network Packet Capture ] (Captura de Pacotes de Rede)
4. Clique em [ Add Network Packet Capture ] (Adicionar Captura de Pacotes de Rede)
5. Defina [ Where to add this integration ] (Onde adicionar esta integração) como “Existing hosts” (Hosts existentes) e defina [ Agent policy ] (Política do agente) como “k8s-apps”
6. Clique em [ Save and continue ] (Salvar e continuar)
7. Clique em [ Save and deploy changes ] (Salvar e implantar alterações)

Instrumentação com o OpenTelemetry

Eu otimizei a demonstração do OpenTelemetry e os gráficos do Helm do OpenTelemetry para o Elastic Observability (consulte Instrument your own applications (Instrumentar suas próprias aplicações) para entender o que foi alterado e por quê). Se quiser apenas usar as aplicações da demonstração do OpenTelemetry para entender o valor que a Elastic proporciona para a observabilidade e a segurança do Kubernetes, comece com Setup the OpenTelemetry demo (Configurar a demonstração do OpenTelemetry). Caso contrário, se quiser observar suas próprias aplicações e serviços, comece com a orientação descrita em Instrument your own applications (Instrumentar suas próprias aplicações).

Configurar a demonstração do OpenTelemetry

Esta seção pressupõe que você gostaria de implantar e observar as aplicações já instrumentadas na demonstração do OpenTelemetry. Usaremos um gráfico do Helm do OpenTelemetry modificado que implanta as aplicações de demonstração e uma instância do OpenTelemetry Collector.

1. Adicione nosso repositório do Helm

helm repo add elastic-open-telemetry https://ty-elastic.github.io/opentelemetry-helm-charts 

helm repo update 

2. Instale os apps de demonstração e o Collector no seu cluster do Kubernetes

helm install elastic-otel elastic-open-telemetry/opentelemetry-demo 

3. Verifique a instalação listando os pods em execução

kubectl get pods 

Você deve ver todos os pods da demonstração do OpenTelemetry, além de uma instância do OpenTelemetry Collector:

4. Pule para Validation and observation (Validação e observação) para validar se os traces, métricas e eventos da sua aplicação estão fluindo para o Elasticsearch

Instrumentar suas próprias aplicações com o OpenTelemetry

Esta seção pressupõe que você estará instrumentando suas próprias aplicações com o OpenTelemetry. Para fazer suas aplicações funcionarem com o modelo de implantação apresentado neste artigo, elas precisarão:

1. Ser instrumentadas com uma versão estável do OpenTelemetry APM Agent
2. Ser instanciadas com variáveis de ambiente do OpenTelemetry específicas
3. Se estiverem usando instrumentação manual, ter certas propriedades de span definidas adequadamente
4. Opcionalmente, adicionar determinados metadados às linhas de log
5. Emitir dados de log para stdout e stderr para serem capturados pela integração de Kubernetes da Elastic

Variáveis de ambiente do container

Para habilitar os dashboards de APM prontos para uso da Elastic, precisamos garantir que os traces, métricas e eventos da aplicação carreguem os metadados contextuais apropriados. Podemos obter esses metadados da Kubernetes Downward API, passando-os para a aplicação por meio da variável de ambiente OTEL_RESOURCE_ATTRIBUTES.

Também precisamos definir o OTEL_EXPORTER_OTLP_ENDPOINT para direcionar as aplicações para enviar seus dados do OpenTelemetry via OTLP para a instância do OpenTelemetry Collector que implantaremos posteriormente no DaemonSet do nó.

O snippet de configuração do container do Kubernetes a seguir configura as variáveis de ambiente que você precisará aplicar às suas aplicações no YAML de implantação.

Você pode estar se perguntando por que estamos definindo k8s.container.restart_count=0 como um atributo de recurso. O atual processador k8sattrribute do OpenTelemetry Collector requer esta dica para corresponder um container (via k8s.container.name ) a uma instância em execução de um container para obter um container.id. Definir k8s.container.restart_count=0 é uma simplificação: manter um controle de quantas vezes um determinado container foi reiniciado pelo Kubernetes em um pod e, de alguma forma, colocar isso em uma variável de ambiente seria complicado. Em cenários típicos, um container geralmente é iniciado apenas uma vez durante o ciclo de vida de um determinado pod. No entanto, se um container for reiniciado pelo pod, essa simplificação falhará.

Propriedades do span

O Elastic APM precisa que determinadas propriedades de span sejam definidas explicitamente para caracterizar, classificar e visualizar dados de span de forma adequada. A maioria das bibliotecas de instrumentação automática de APM do OpenTelemetry definirá esses campos para você. No entanto, se você estiver instrumentando sua aplicação manualmente, precisará definir explicitamente as seguintes propriedades:SpanKind: para que o Elastic APM classifique os spans adequadamente, ele precisa saber o SpanKind (por exemplo, INTERNAL, SERVER , CLIENT). A maioria das bibliotecas de instrumentação automática de APM do OpenTelemetry definirá esse campo para você. No entanto, se você estiver instrumentando sua aplicação manualmente, deverá definir SpanKind como SERVER para spans que aceitam chamadas RPC ou REST, CLIENT para spans que iniciam chamadas RPC ou REST ou de banco de dados e INTERNAL (padrão) para chamadas de função dentro de um serviço. No Java, por exemplo, você definiria SpanKind como SERVER para um span que recebe uma chamada gRPC usando algo como:

RpcSystem/DbSystem: para que o Elastic APM classifique corretamente os spans, ele precisa saber se o span representa uma transação de RPC ou uma transação de banco de dados e, além disso, que tipo de sistema RPC ou de banco de dados está em uso. A maioria das bibliotecas de instrumentação automática de APM do OpenTelemetry definirá esse campo para você. Se você estiver instrumentando sua aplicação manualmente, deverá definir o atributo de span RpcSystem ou DbSystem. No Rust, por exemplo, você definiria RpcSystem como 'grpc' para um span que recebe uma chamada gRPC usando algo como:

NetPeerHost e NetPeerPort: para que o Elastic APM mapeie corretamente as dependências entre os serviços, quando SpanKind é definido como CLIENT (ou seja, uma chamada gRPC ou de banco de dados de saída), os atributos de span NetPeerName e NetPeerPort devem ser definidos para indicar o destinatário pretendido da chamada. Algumas das bibliotecas de instrumentação automática de APM do OpenTelemetry definirão esse campo para você. Se você estiver instrumentando sua aplicação manualmente, deverá definir esses atributos explicitamente. No JavaScript, por exemplo, você definiria NetPeerName e NetPeerPort para um span que envia uma chamada gRPC usando algo como:

Atributos de log

O Elastic APM pode correlacionar linhas de log específicas a traces específicos. Para habilitar essa funcionalidade, as linhas de log provenientes da sua aplicação precisam ser marcadas com pares de chave/valor span.id e trace.id onde aplicável. Alguns dos agentes do Elastic APM (por exemplo, o agente Java) modificarão automaticamente seu modelo de logging para adicionar esses metadados contextuais.

Implantar o OpenTelemetry Collector no DaemonSet

Se você está trabalhando com a demonstração do OpenTelemetry e nossos gráficos do Helm do OpenTelemetry modificados, um OpenTelemetry Collector otimizado já foi instalado no DaemonSet em cada nó para você.

Se você está instrumentando suas próprias aplicações, pode usar o YAML a seguir como base para configurar e implantar o OpenTelemetry Collector no DaemonSet nos nós do seu cluster. A configuração exemplar (implantada usando um ConfigMap) ingere dados de traces, métricas e eventos do OTLP de aplicações na porta TCP 4317 (grpc) e 4318 (http). Como o Collector está em execução no DaemonSet, essa porta pode ser acessada de outros pods em execução no mesmo nó por meio do IP do nó. Os dados do OTLP recebidos são executados por meio do processador k8sattributes para anexar o container.id. Descartamos todos os dados de log que possam estar chegando (lembre-se de que estamos obtendo esses dados por meio da integração de Kubernetes da Elastic) e passamos pelo tracing, eventos e métricas até a integração do Elastic APM também em execução no DaemonSet. A integração do Elastic APM está escutando na porta 8200, também acessível por meio do IP do nó (passado aqui como uma variável de ambiente obtida da Kubernetes Downward API).

1. Baixe este YAML exemplar de implantação do OpenTelemetry Collector

curl -L -O https://raw.githubusercontent.com/ty-elastic/elastic-otel-k8s/main/collector/otel-collector.yaml 

2. Edite conforme apropriado para sua implantação

3. Aplique-o ao seu cluster do Kubernetes

kubectl apply -f otel-collector.yaml 

Validação e observação

Nesta seção, validaremos se os dados de observabilidade e segurança que configuramos acima estão entrando no nosso cluster do Elasticsearch conforme o esperado. Este exercício também servirá como uma breve visão geral de alguns dos dashboards de observabilidade e segurança prontos para uso disponíveis no Elasticsearch. Sugerimos que você use isso como incentivo para explorar nossas soluções de visualização e analítica.

Service Map do APM

O Service Map do APM fornece uma visualização dos seus serviços e a relação entre eles. Certos tipos de erros e alertas de serviço serão destacados neste mapa conforme apropriado. Deste mapa, você pode ir para uma visão detalhada de qualquer serviço instrumentado com o OpenTelemetry (ou o próprio agente de APM da Elastic).

1. Na barra lateral de navegação do Kibana, selecione [ APM ] em [ Observability ]
2. Selecione [ Service Map ] em [ APM ]

APM Service

A visualização APM Service fornece uma visão geral de um determinado serviço. Deste dashboard, você pode detalhar facilmente traces, logs e métricas de infraestrutura relacionadas. Historicamente, uma correlação bruta entre essas fontes de dados exigiria uma tradução manual de carimbos de data/hora e identificadores de serviço em plataformas de observabilidade isoladas. Com a Elastic e o OpenTelemetry, essa correlação ocorre automaticamente, permitindo que analistas, operadores e desenvolvedores se concentrem na análise da causa raiz, em vez de se preocuparem com nuances das ferramentas de observabilidade.

1. Na barra lateral de navegação do Kibana, selecione [ APM ] em [ Observability ]
2. Selecione [ Service Map ] em [ APM ]
3. Clique com o botão direito do mouse em qualquer serviço no mapa
4. Selecione [ Service Details ] (Detalhes do serviço)

Dessa mesma visualização, você pode facilmente passar ao exame das transações e spans que conectam seus usuários aos seus serviços e os serviços uns aos outros.

1. Selecione [ Transactions ] (Transações) no cabeçalho
2. Selecione uma transação de interesse na subseção [ Transactions ] (Transações)

Métricas do cluster do Kubernetes

Os dashboards do Kubernetes da Elastic fornecem uma visão geral e uma visão detalhada das operações do seu cluster do Kubernetes. Você pode monitorar métricas em clusters, nós, pods, DaemonSets, serviços e muito mais.

1. Na barra lateral de navegação do Kibana, selecione [ Dashboard ] em [ Analytics ] (Analítica)
2. Selecione [Kubernetes] no menu [Tags]
3. Selecione o dashboard [ Cluster Overview ] (Visão geral do cluster)

Monitoramento de processos do Kubernetes

A integração do Elastic Defend fornece observabilidade centrada na segurança nos seus recursos do Kubernetes. O dashboard de segurança do Kubernetes possibilita que os analistas entendam exatamente quais processos foram executados nos seus nós do Kubernetes, quando, com quais parâmetros de tempo de execução e sob qual conta.

1. Na barra lateral de navegação do Kibana, selecione [ Dashboards ] em [ Security ]
2. Selecione [ Kubernetes ]

Gerenciamento da Postura de Segurança do Kubernetes

O dashboard Kubernetes Security Posture Management (KSPM) (Gerenciamento da Postura de Segurança do Kubernetes) fornece análises automatizadas e recomendações de remediação em uma gama de práticas recomendadas do Kubernetes para implantação segura. Para desenvolvedores e pessoal de DevOps, esse dashboard pode fornecer um aviso valioso sobre possíveis problemas de configuração antes que eles se tornem um problema na produção.

1. Na barra lateral de navegação do Kibana, selecione [ Dashboards ] em [ Security ]
2. Selecione [ Cloud Posture ] (Postura na nuvem)

Análise de tráfego de rede

A integração da Captura de Pacotes de Rede permite que você analise detalhes sobre o tráfego IP de entrada e saída dos nós do Kubernetes em busca de serviços com mau comportamento ou uma violação de segurança.

1. Na barra lateral de navegação do Kibana, selecione [ Explore ] (Explorar) em [ Security ]
2. Selecione [ Network ] (Rede)

Elastic: observabilidade e segurança desenvolvidas para o Kubernetes!

O Kubernetes representa um modelo de implantação de aplicações totalmente novo para muitas empresas. Um modelo de implantação totalmente novo requer uma abordagem igualmente aberta, moderna e holística para observabilidade e segurança. Conforme mostramos aqui, a plataforma da Elastic está posicionada de forma única no setor para fornecer observabilidade e segurança totalmente integradas, com todos os recursos e fidelidade total para o Kubernetes.

Tem interesse? Entre em contato com nossa equipe de pré-vendas para começar a montar seu ambiente com a Elastic!