Skip to main content
Inicia sesión
Comienza una prueba gratuitaComunícate con Ventas

Observabilidad y seguridad modernas en Kubernetes con Elastic y OpenTelemetry

By

Ty Bekiares

azure-kubernetes-720x420-2.png

La naturaleza estructurada de Kubernetes brinda un medio escalable y repetible de desplegar y gestionar servicios y aplicaciones. Esto ha llevado a una adopción generalizada en todas las verticales del mercado, tanto para modelos de despliegue en el cloud como en las instalaciones. La naturaleza autónoma de la operación de Kubernetes, sin embargo, requiere observabilidad y seguridad integrales y totalmente convergentes. Esto es exclusivamente posible en la actualidad con la plataforma de Elastic.

En este artículo, abordaremos las mejores prácticas para observar y asegurar los flujos de trabajo de servicios y aplicaciones en Kubernetes con Elasticsearch y OpenTelemetry. Aprenderás cómo hacer lo siguiente:

  • Desplegar y configurar Elastic Agent en tu cluster de Kubernetes
  • Ingestar rastreos, métricas y eventos de la aplicación de OpenTelemetry con Elastic Agent
  • Ingestar logs, métricas de cluster y patrones de tráfico de red de contenedores de Kubernetes con Elastic Agent
  • Usar Elastic Defend para agregar protección de amenazas y monitoreo centrado en la seguridad en tu cluster de Kubernetes
  • Familiarizarte con los dashboards listos para usar de Elastic a fin de observar, correlacionar y realizar análisis de causa raíz de problemas operativos

Los silos de datos presentan un desafío para solucionar problemas en los despliegues de Kubernetes

Históricamente, la industria ha considerado la observabilidad de aplicaciones, observabilidad de infraestructuras y seguridad de infraestructuras como dominios diferentes, cada uno gestionado en herramientas diferentes por distintos equipos. Este modelo, si bien suele ser conveniente en términos organizativos, expone rápidamente un punto débil y una barrera invisible:

Los analistas (humanos o máquinas) necesitan recurrir a los datos recopilados de la observabilidad de aplicaciones, observabilidad de infraestructuras y seguridad de infraestructuras a fin de determinar si un problema operativo dado es un problema de infraestructura, un defecto de una aplicación o una vulneración de seguridad. Además, los especialistas también necesitarán acceso a los datos de fidelidad total de estas tres fuentes para hallar la causa raíz de un problema dado.

Como solución alternativa, los clientes suelen encontrarse duplicando algunos datos de observabilidad en varias plataformas de datos. En el mejor de los casos, esto duplica o triplica el costo del almacenamiento de datos, soporte y capacitación. En el peor de los casos, los analistas se pierden datos esenciales necesarios para hallar adecuadamente la causa raíz de un problema. Esto se exacerba más por la naturaleza escalable y dinámica de Kubernetes. Podría decirse que separar las plataformas de seguridad y observabilidad es un antipatrón del modelo que de lo contrario sería integrado de despliegue de servicios que Kubernetes se permite. 

Un momento oportuno para la observabilidad

En última instancia, los desarrolladores, operadores y analistas de seguridad por igual necesitan una visión integral unificada de su sistema que abarque todas las aplicaciones e infraestructura. Los equipos de despliegue de infraestructura necesitan un patrón de despliegue unificado nativo de Kubernetes para brindar esta visibilidad y asegurar sus clusters.

Esto requiere tres facilitadores:

  1. Todos los datos de observabilidad y seguridad (incluidos los logs, rastreos, eventos y métricas de aplicaciones, servicios e infraestructura) deben almacenarse en una plataforma de datos unificada de modo que se optimicen tanto para la búsqueda (correlación y latencia) como para el almacenamiento (costo).
  2. La plataforma de datos unificada también debe ser capaz de correlacionar datos y presentarlos según su rol: por ejemplo, si un analista intenta encontrar la causa raíz de un problema, la plataforma debería guiarlo hasta el posible problema y permitirle interactuar sin inconvenientes con los datos, independientemente de su fuente o forma subyacente.
  3. La instrumentación de aplicaciones e infraestructura debería alinearse con el mantra de Kubernetes: despliegues repetibles y escalables sin una configuración a medida.

Elastic: Ya sabes, para Kubernetes

Un nexo tecnológico impulsado por Elastic, OpenTelemetry, Kubernetes y hardware moderno de computación ha hecho que la seguridad y la observabilidad de escala completa y nativos de Kubernetes estén a disposición en la actualidad:

  • OpenTelemetry es un catalizador para desarrolladores (tanto internos como de terceros) que permite instrumentar por completo todas sus aplicaciones y servicios desacoplando la selección de proveedores de APM de la implementación de APM.
  • El hardware moderno de computación con muchísima RAM y CPU hace que el rastreo "siempre activo" sea práctico sin afectar el rendimiento, incluso en aplicaciones en tiempo real.
  • La arquitectura más reciente de Elastic, que incluye snapshots buscables y el nuevo flujo de datos temporales, junto con el muestreo posterior de APM de Elastic, hace que el almacenamiento en línea multianual de datos de seguridad y observabilidad integral sea práctico y asequible.
  • El despliegue de Elastic Agent en el DaemonSet en cada nodo de Kubernetes permite el despliegue repetible y escalable de un recopilador de datos unificado controlado de forma remota. Una vez desplegados, las instancias de Elastic Agent pueden gestionarse en conjunto para agregar, configurar o eliminar de forma trivial integraciones de datos.
  • La plataforma de Elastic proporciona una solución de seguridad de Kubernetes completamente integrada, que abarca la gestión de posturas, observación y protección.
  • Elasticsearch permite la correlación y orientación en todas las fuentes de datos recopiladas mediante dashboards, detección de anomalías y alertas listos para usar.

Modelo de recopilación de datos

Como puedes ver en el diagrama siguiente, recomendamos un modelo híbrido para la recopilación de datos de seguridad y observabilidad, que dependa de Elastic Agent para obtener métricas de infraestructura de Kubernetes y logs de contenedores de aplicaciones junto con el agente de APM de OpenTelemetry para obtener métricas, eventos de rastreo y rastreos de aplicaciones. La lógica de este enfoque se describe en detalle a continuación.

Datos de métricas, eventos y rastreos de aplicaciones

La generación de métricas y rastreos de aplicaciones por lo general requiere de la introducción directa de una biblioteca de APM en el código de la aplicación. Sin embargo, podemos eliminar el bloqueo de proveedores como barrera para la adopción de APM mediante los agentes de APM de OpenTelemetry. Hasta la fecha, OpenTelemetry ha concentrado sus esfuerzos en implementaciones de agentes sólidos y estandarizados para capturar eventos de rastreo y rastreos de aplicaciones, con soporte emergente para las métricas de aplicaciones. Actualmente existen agentes de una madurez razonable para casi todos los lenguajes de programación populares. En muchos casos, puedes usar la autoinstrumentación para instrumentar tus aplicaciones con poca codificación o sin ella. Si tus aplicaciones están escritas en .NET, Java, NodeJS o Python y hacen uso de marcos de trabajo típicos, puedes incluso inyectar bibliotecas de APM al momento de la ejecución con el operador de Kubernetes de OpenTelemetry.

El análisis de causa raíz requiere que los datos de APM se correlacionen con las métricas de infraestructura y los logs de aplicaciones. A fin de permitir esta correlación, necesitamos ciertos metadatos de identificación, o atributos de recursos, en común en todos los logs y rastreos de aplicaciones y métricas de infraestructura. La plataforma de Elastic usa service.name, pod.uid y container.id para vincular los datos de observabilidad de las aplicaciones que se ejecutan en Kubernetes. Históricamente, las bibliotecas de APM "espiaban" por fuera de sus límites para obtener estos metadatos. Algunas de las bibliotecas de APM de OpenTelemetry actualmente brindan soporte para esta funcionalidad (por ejemplo, Java), mientras que otras no lo hacen (Rust). Si bien este enfoque simplifica el despliegue, dista mucho de ser ideal: los agentes de APM (que se ejecutan en el contexto de una aplicación) no solo deben determinar su entorno de tiempo de ejecución (Docker, Kubernetes, etc.), sino que también requieren permisos suficientes para acceder a estos identificadores (por ejemplo, acceso a /proc/self/cgroup o a las API de Kubernetes). Lo último es claramente una potencial preocupación en materia de seguridad. Como tal, idealmente buscamos depender de entidades externas para introducir tales metadatos (como variables de entorno) o para anexar dichos metadatos una vez creados los datos de rastreo. Para anexar de forma confiable container.id para rastrear datos independientemente de la biblioteca de APM de OpenTelemetry en uso, desplegamos un recopilador de OpenTelemetry configurado con el procesador k8sattribute que se ejecuta en el DaemonSet del nodo.

Una vez etiquetados los datos de APM con los metadatos de Kubernetes correlacionados, se envían desde el recopilador de OpenTelemetry a un Elastic Agent que también se ejecuta en el DaemonSet del nodo. El Elastic Agent se configuró mediante Fleet con la integración de APM. Distribuir la integración de APM en el DaemonSet de cada nodo ayuda a distribuir la carga de ingesta de APM y vincula más estrechamente su disponibilidad con las aplicaciones para las que ofrece soporte. Además, mantiene el tráfico GRPC/HTTP2 local en el DaemonSet en sí y evita las complejidades de balanceo de carga de GRPC/HTTP2. Por último, se simplifica la seguridad: OTLP puede quedar inseguro en el nodo debido a la seguridad TLS del Elastic Agent gestionado por Fleet empleada entre el nodo y el cluster de Elasticsearch. La integración de APM de Elastic convierte los datos de eventos, métricas y rastreos de OpenTelemetry a Elasticsearch Common Schema (ECS). Los documentos resultantes se envían luego a Elasticsearch para su ingesta e indexación.

Logs de contenedores y métricas de infraestructura de Kubernetes

Mientras que el estándar de OpenTelemetry soporta el logging, las implementaciones aún están en borrador. Por eso, muchos de los agentes disponibles todavía no brindan soporte para la capacidad de enlazar marcos de trabajo de logging. En la práctica, ingestar archivos de log de contenedores es el único medio práctico de capturar los datos de logs de aplicaciones. Si bien esto es posible con el recopilador de OpenTelemetry filelogreceiver, actualmente es de calidad alfa y aún no se recomienda para los casos de uso de producción. Lo mismo aplica para k8sclusterreceiver, cuyo objetivo es capturar las métricas de infraestructura de Kubernetes.

En comparación, la integración Elastic Kubernetes es sólida, está demostrada y brinda una recopilación de fidelidad total de los logs de aplicaciones y las métricas de infraestructura de Kubernetes. Además, nuestra integración de Kubernetes puede gestionarse de forma remota en conjunto desde Kibana, lo que simplifica en gran medida la configuración. A diferencia de las métricas y los rastreos de aplicaciones, la integración Elastic Kubernetes opera fuera del código de tu aplicación, por lo que mitiga la preocupación por el bloqueo de proveedores.

Además, la presencia de un Elastic Agent en el DaemonSet de cada nodo tiene un valor que va mucho más allá de la integración de Kubernetes. Como verás más adelante en este artículo, aprovecharemos esta misma instancia de Elastic Agent para desplegar Elastic Defend a fin de monitorear y asegurar nuestros nodos de Kubernetes.

Eventos de seguridad y datos de host

Los flujos de trabajo de seguridad y observabilidad modernos de Kubernetes deben ir a la par a fin de permitir a los analistas encontrar la causa raíz de un problema dado. Las soluciones de seguridad de Elastic brindan soluciones de SIEM, SOAR y XDR completamente integradas, con todas las características y sensibles a Kubernetes, que incluyenprotección de endpoint.

En particular, la integración de Defend de Elastic proporciona de forma inherente una observabilidad de Kubernetes mucho mayor. Nuestra integración Gestión de postura de seguridad de Kubernetes puede alertar a tus equipos de desarrollo, DevOps y DevSecOps sobre potenciales problemas de configuración con aplicaciones antes de que los identifique tu equipo de seguridad. Nuestro dashboard de seguridad de Kubernetes permite a los analistas comprender exactamente qué procesos se ejecutaron en tus nodos de Kubernetes, cuándo, con qué parámetros de tiempo de ejecución y en qué cuenta. Este nivel sin precedentes de visibilidad del tiempo de ejecución permite detectar amenazas de seguridad imprevistas introducidas en capas de contenedores usadas como dependencias en tus aplicaciones en contenedores.

Como la integración de APM de Elastic, estas integraciones de seguridad se agregan, configuran y eliminan a través de Fleet, y se ejecutan dentro del Elastic Agent en el DaemonSet de cada nodo de tu cluster de Kubernetes.

¡Pongamos manos a la obra!

Requisitos

Necesitarás un cluster de Kubernetes en el cual desplegar tus aplicaciones, Elastic Agent y el recopilador de OpenTelemetry. Nos gusta usar kOps para crear, gestionar y eliminar con facilidad clusters de prueba en los hiperescaladores. A modo de referencia, un solo AWS EC2 t3.xlarge es suficiente para desplegar la demostración de OpenTelemetry y nuestro Elastic Agent. Estos ejemplos deberían funcionar con cualquier cluster de Kubernetes gestionado o autogestionado (por ejemplo, EKS, GKE) en cualquiera de los hiperescaladores principales o en las instalaciones (por ejemplo, OpenShift). Teóricamente, también deberían funcionar con clusters de Kubernetes de escritorio (como el motor de Kubernetes integrado de MicroK8s o Docker), suponiendo que le asignes a esos entornos suficiente RAM y CPU (por ejemplo, 4 vCPU y 16 GB de RAM). También necesitarás conocimientos administrativos de Kubernetes básicos (por ejemplo, desplegar yaml, comprobar el estado de pods y visualizar los archivos de logs de pods). Antes de comenzar, asegúrate de que tu contexto de Kubernetes apunte al cluster correcto.

Por supuesto, también necesitarás aplicaciones o servicios que puedas instrumentar con OpenTelemetry. Para comenzar, puedes usar nuestra bifurcación de la demostración de OpenTelemetry. Desde allí, puede seguir nuestras mejores prácticas para instrumentar tus propias aplicaciones y servicios.

Por último, necesitarás acceso a un despliegue de Elasticsearch moderno (8.5 o posterior) con el que puedas experimentar (puedes crear uno de forma gratuita en nuestro cloud) y al que puedas acceder desde tu cluster de aplicaciones de Kubernetes.

Herramientas

En este tutorial se asume que estás usando un host basado en Linux o MacOS para configurar el cluster de Kubernetes. Deberás asegurarte de tener instaladas las herramientas siguientes:

Crea tu cluster de Elasticsearch

Si ya tienes un despliegue de Elasticsearch moderno, puedes experimentar en él. ¡Estupendo! De lo contrario, configuremos uno creando un cluster de prueba gratis en cloud.elastic.co.

  1. Navega a cloud.elastic.co y regístrate para una prueba gratuita (no se requiere tarjeta de crédito).
  2. Asigna a tu cluster de Elasticsearch el nombre "o11y", por ejemplo, y mantén las demás configuraciones con sus valores predeterminados.
  3. Haz clic en [ Create Deployment ] (Crear despliegue)
  4. Espera que Elasticsearch Cloud reporte "Your deployment is ready!" (Tu despliegue está listo.).
  5. Haz clic en [ Continue ] (Continuar) para iniciar sesión en Kibana.

Despliega Elastic Agent en el DaemonSet

Usaremos Elastic Agent (con integraciones) instalado en el DaemonSet en cada nodo de tu cluster de Kubernetes para ingestar datos en Elasticsearch.

1. Descarga el siguiente YAML (mencionado aquí) en tu máquina local. Usaremos este YAML para desplegar Elastic Agent (con Elastic Defend) en el DaemonSet de tus nodos de Kubernetes.

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

2. Descarga el parche siguiente en tu máquina local. Este parche aumenta las asignaciones predeterminadas de CPU y RAM de contenedores de Elastic Agent para admitir sin problemas todas las integraciones que instalaremos. En producción, puedes decidir desplegar solo un subconjunto de las siguientes integraciones, por lo que esta modificación puede resultar irrelevante.

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

3. Aplica el parche en su lugar.

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

4. Asegúrate de tener sesión iniciada en Kibana en tu cluster de Elasticsearch.

5. Navega a [ Management / Fleet ] (Gestión/Fleet).

6. Haz clic en [ Add agent ] (Agregar agente).

7. Asigna el nombre "k8s-apps" a la nueva política, por ejemplo. 

  • La política "k8s-apps" se usará aquí para desplegar integraciones en el DaemonSet de los nodos en tu cluster de Kubernetes de aplicaciones.

8. En [ Advanced options ] (Opciones avanzadas), configura [ Unenrollment timeout ] (Tiempo de espera para cancelación de la inscripción) en "3600" segundos. 

  • Kubernetes puede crear y eliminar nodos de forma dinámica; esta configuración asegurará que las instancias de Elastic Agent desplegadas en nodos eliminados se quiten de forma automática.

9. Haz clic en [ Create policy ] (Crear política).

10. En [ Install Elastic Agent on your host ] (Instalar Elastic Agent en tu host), haz clic en "Kubernetes".

11. Encuentra el valor de la variable "FLEET_URL" y cópialo como valor de "FLEET_URL" en el archivo "elastic-defend.yaml" que descargaste y al que le aplicaste el parche previamente.

12. Encuentra el valor de la variable "FLEET_ENROLLMENT_TOKEN" y cópialo como valor de "FLEET_ENROLLMENT_TOKEN" en el archivo "elastic-defend.yaml" que descargaste y al que le aplicaste el parche previamente.

13. Aplica elastic-defend.yaml en tu cluster a través de:

kubectl apply -f elastic-defend.yaml

14. Espera a que [ Confirm agent enrollment ] (Confirmar inscripción del agente) muestre "1 agent has been enrolled" (Se inscribió 1 agente).

15. Espera a que [ Incoming data confirmed ] (Datos entrantes confirmados) muestre "Incoming data received from 1 of 1 recently enrolled agent" (Datos entrantes recibidos de 1 de 1 agente inscrito recientemente).

16. Haz clic en "Close" (Cerrar).

Es posible que hayas notado que Elastic proporciona un YAML de despliegue de Elastic Agent preconfigurado cuando seleccionas la opción de host de Kubernetes. Este YAML de despliegue no incluye la imagen de Elastic Defend.

Configura las integraciones de Elastic Agent

Ahora llega la parte sencilla. Con un Elastic Agent gestionado por Fleet desplegado en tu DaemonSet, resulta trivial agregar/configurar/eliminar integraciones de forma remota con la interfaz de integraciones de Kibana.

APM

La integración de APM de Elastic se usa para importar datos de APM de OpenTelemetry en Elastic.

  1. Navega en Kibana hasta [ Management / Integrations ] (Gestión/Integraciones).
  2. Busca "APM".
  3. Haz clic en [ APM ].
  4. Haz clic en [ Manage APM integration in Fleet ] (Gestionar integración de APM en Fleet).
  5. Haz clic en [ Add Elastic APM ] (Agregar APM de Elastic).
  6. Configura [ General / Server configuration / Host ] (General/Configuración del servidor/Host) en "0.0.0.0:8200". (Esto expone la ingesta de integración de APM a otros pods —incluidos el recopilador de OpenTelemetry, que también se ejecuta en el DaemonSet— en el nodo).
  7. Deshabilita [ Agent authorization / Anonymous Agent access ] (Autorización de agente/Acceso de agente anónimo). (Esta simplificación permite que el recopilador de OpenTelemetry envíe datos OTEL a la integración de APM de Elastic sin un token de autorización —en particular, la integración de APM no se expone fuera del nodo—).
  8. Opcionalmente, habilita [ Tail-based sampling ] (Muestreo posterior). (Esto permite el submuestreo inteligente de datos de rastreo para capturar anomalías y el rendimiento general, además de reducir los requisitos de almacenamiento).
  9. Configura [ Where to add this integration ] (Dónde agregar esta integración) como "Existing hosts" (Hosts existentes) y [ Agent policy ] (Política de agente) como "k8s-apps".
  10. Haz clic en [ Save and continue ] (Guardar y continuar).
  11. Haz clic en [ Save and deploy changes ] (Guardar y desplegar cambios).

Kubernetes

Despliega kube-state-metrics

La integración de Kubernetes requiere que kube-state-metrics esté disponible en tu cluster de Kubernetes para permitir los dashboards de Kubernetes listos para usar.

1. Agrega el repositorio de helm kube-state-metrics.

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

helm repo update

2. Instala kube-state-metrics en tu cluster de Kubernetes en el mismo espacio de nombre que Elastic Agent (que, con el yaml de despliegue proporcionado para Elastic Agent, tiene el valor predeterminado “kube-system”).

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

Instala la integración de Kubernetes

La integración Elastic Kubernetes se usa para importar logs y métricas de Kubernetes en Elasticsearch.

  1. Navega en Kibana hasta [ Management / Integrations ] (Gestión/Integraciones).
  2. Busca "Kubernetes".
  3. Selecciona [ Kubernetes ].
  4. Haz clic en [ Add Kubernetes ] (Agregar Kubernetes).
  5. Habilita [ Collect Kubernetes metrics from kube-state-metrics ] (Recopilar métricas de Kubernetes de kube-state-metrics) si aún no está configurado.
  6. Configura [ Where to add this integration ] (Dónde agregar esta integración) como "Existing hosts" (Hosts existentes) y [ Agent policy ] (Política de agente) como "k8s-apps".
  7. Haz clic en [ Save and continue ] (Guardar y continuar).
  8. Haz clic en [ Save and deploy changes ] (Guardar y desplegar cambios).

Elastic Defend

La integración Elastic Defend se usa para proteger tus nodos de Kubernetes y recopilar datos adicionales de observabilidad centrados en la seguridad.

  1. Navega en Kibana hasta [ Management / Integrations ] (Gestión/Integraciones).
  2. Busca "Elastic Defend".
  3. Selecciona [ Elastic Defend ].
  4. Haz clic en [ Add Elastic Defend ] (Agregar Elastic Defend).
  5. Configura [ Integration name ] (Nombre de la integración) como "defend-1".
  6. Navega a [ Select configuration settings ] (Seleccionar ajustes de configuración), configura [ Select the type of environment you want to protect ] (Seleccionar el tipo de entorno que deseas proteger) como "Cloud Workloads (Linux servers or Kubernetes environments)" (Cargas de trabajo en el cloud [servidores Linux o entornos de Kubernetes]) y configura [ To reduce data ingestion volume, select Interactive only ] (Para reducir el volumen de ingesta de datos, seleccionar Solo interactivo) como "All events" (Todos los eventos).
  7. Configura [ Where to add this integration ] (Dónde agregar esta integración) como "Existing hosts" (Hosts existentes) y [ Agent policy ] (Política de agente) como "k8s-apps".
  8. Si tu cluster de Kubernetes no se ejecuta en GKE o EKS, en [ Advanced options ] (Opciones avanzadas) configura [ Namespace ] (Espacio de nombre) como "k8sapps", por ejemplo, donde "k8sapps" identifica tu cluster de Kubernetes de aplicaciones. (Esto es necesario para etiquetar la telemetría de Elastic Defend con el nombre del cluster de Kubernetes al que aplica.)
  9. Haz clic en [ Save and continue ] (Guardar y continuar).
  10. Selecciona [ Settings ] (Configuración).
  11. Navega a [ Elastic Defend version ] (Versión de Elastic Defend) y habilita "Keep integration policies up to date automatically" (Mantener políticas de integración actualizadas de forma automática).
  12. Selecciona [ Integration policies ] (Políticas de integración) y haz clic en [ defend-1 ].
  13. Navega a [ Type: Operating system / Event Collection: Linux ] (Tipo: Sistema operativo/Recopilación de eventos: Linux) y habilita [ Capture terminal output ] (Capturar salida de terminal).
  14. Haz clic en [ Save and continue ] (Guardar y continuar).
  15. Haz clic en [ Save and deploy changes ] (Guardar y desplegar cambios).

Ciertos dashboards de Kubernetes de Elasticsearch requieren conocer tu ID y nombre del cluster de Kubernetes. Si tu cluster se ejecuta en GKE o EKS, Elastic Agent obtendrá automáticamente estos metadatos. Si ejecutas un cluster de Kubernetes autogestionado, puedes crear un pipeline de ingesta para ornamentar los eventos de seguridad con los campos orchestrator.cluster.name y orchestrator.cluster.id de forma automática, configurados en el espacio de nombre de la política que definiste previamente.

  1. Navega a [ Management / Dev Tools ] (Gestión/Herramientas de desarrollo).
  2. Ejecuta lo siguiente:
PUT _ingest/pipeline/logs-endpoint.events.process@custom
{
  "processors": [
    {
      "set": {
        "field": "orchestrator.cluster.name",
        "copy_from": "data_stream.namespace",
        "ignore_empty_value": true,
        "ignore_failure": true
      }
    },
    {
      "set": {
        "field": "orchestrator.cluster.id",  		
        "copy_from": "data_stream.namespace",
        "ignore_empty_value": true,
        "ignore_failure": true
      }
    }
  ]
}

Gestión de postura de seguridad de Kubernetes

La integración Gestión de postura de seguridad de Elastic Kubernetes se usa para validar tu cluster de Kubernetes y aplicaciones contra las mejores prácticas para asegurar la configuración de Kubernetes, tal como se define en el Centro de seguridad de Internet (CIS). Esto permite a tus equipos de desarrollo y despliegue identificar errores de configuración antes de que den como resultado una vulneración de seguridad.

  1. Navega en Kibana hasta [ Management / Integrations ] (Gestión/Integraciones).
  2. Busca "Kubernetes Security Posture Management". (Gestión de postura de seguridad de Kubernetes)
  3. Selecciona [ Kubernetes Security Posture Management ] (Gestión de postura de seguridad de Kubernetes).
  4. Haz clic en [ Add Kubernetes Security Posture Management ] (Agregar gestión de postura de seguridad de Kubernetes).
  5. Configura [ Kubernetes Deployment ] (Despliegue de Kubernetes) como "Unmanaged Kubernetes" (Kubernetes no gestionados), en el caso de los Kubernetes autogestionados, o como "EKS (Elastic Kubernetes Service)" (EKS, servicio de Elastic Kubernetes), si tu cluster de aplicaciones de Kubernetes se ejecuta específicamente en un EKS de AWS.
  6. Configura [ Where to add this integration ] (Dónde agregar esta integración) como "Existing hosts" (Hosts existentes) y [ Agent policy ] (Política de agente) como "k8s-apps".
  7. Haz clic en [ Save and continue ] (Guardar y continuar).
  8. Haz clic en [ Save and deploy changes ] (Guardar y desplegar cambios).

Captura de paquetes de red

La integración Captura de paquetes de red de Elastic se usa para obtener información del tráfico de red que ingresa a tus nodos de Kubernetes y egresa de ellos.

  1. Navega en Kibana hasta [ Management / Integrations ] (Gestión/Integraciones).
  2. Busca "Network Packet Capture" (Captura de paquetes de red).
  3. Selecciona [ Network Packet Capture ] (Captura de paquetes de red).
  4. Haz clic en [ Add Network Packet Capture ] (Agregar captura de paquetes de red).
  5. Configura [ Where to add this integration ] (Dónde agregar esta integración) como "Existing hosts" (Hosts existentes) y [ Agent policy ] (Política de agente) como "k8s-apps".
  6. Haz clic en [ Save and continue ] (Guardar y continuar).
  7. Haz clic en [ Save and deploy changes ] (Guardar y desplegar cambios).

Instrumentación con OpenTelemetry

Optimizamos la demostración de OpenTelemetry y los gráficos de Helm de OpenTelemetry para la observabilidad de Elastic (consulta cómo instrumentar tus propias aplicaciones para comprender qué se modificó y por qué). Si deseas solo usar las aplicaciones en la demostración de OpenTelemetry para comprender el valor que aporta Elastic a la seguridad y observabilidad de Kubernetes, comienza por Configurar la demostración de OpenTelemetry. De lo contrario, si deseas observar tus propias aplicaciones y servicios, comienza por la orientación descrita en cómo instrumentar tus propias aplicaciones.

Configurar la demostración de OpenTelemetry

En esta sección se asume que quieres desplegar y observar las aplicaciones ya instrumentadas en la demostración de OpenTelemetry. Usaremos un gráfico de Helm de OpenTelemetry modificado que despliega tanto las aplicaciones de demostración como una instancia del recopilador de OpenTelemetry.

1. Agrega nuestro repositorio de helm.

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

2. Instala las aplicaciones de la demostración y el recopilador en tu cluster de Kubernetes.

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

3. Verifica la instalación enumerando los pods en ejecución.

kubectl get pods

Deberías ver todos los pods de demostración de OpenTelemetry además de una instancia del recopilador de OpenTelemetry:

> kubectl get pods
NAME                                                  READY   STATUS    RESTARTS   AGE
elastic-otel-adservice-86b5b4f779-8lsgf               1/1     Running   0          3h28m
elastic-otel-cartservice-55659bd5f4-lvtjx             1/1     Running   0          3h28m
elastic-otel-checkoutservice-88bfcf745-42nvt          1/1     Running   0          3h28m
elastic-otel-currencyservice-659dd55fc8-pcrrx         1/1     Running   0          3h28m
elastic-otel-emailservice-64df788455-mkb56            1/1     Running   0          3h28m
elastic-otel-featureflagservice-6dcf49d84c-n5jtk      1/1     Running   0          3h28m
elastic-otel-ffspostgres-67dcd7596d-htbpm             1/1     Running   0          3h28m
elastic-otel-frontend-674c8fdc74-zmv8r                1/1     Running   0          3h28m
elastic-otel-frontendproxy-5bd757dc89-r2728           1/1     Running   0          3h28m
elastic-otel-loadgenerator-5b98bd9656-8z8hz           1/1     Running   0          3h28m
elastic-otel-otelcol-agent-kbb54                      1/1     Running   0          3h28m
elastic-otel-paymentservice-5c4b5c57bd-wkbqj          1/1     Running   0          3h28m
elastic-otel-productcatalogservice-6995496975-7wm46   1/1     Running   0          3h28m
elastic-otel-quoteservice-849797dfdd-bkj29            1/1     Running   0          3h28m
elastic-otel-recommendationservice-6cb4476f-zpqqv     1/1     Running   0          3h28m
elastic-otel-redis-5698bf675b-dl2xv                   1/1     Running   0          3h28m
elastic-otel-shippingservice-6b9fdcc467-knlxb         1/1     Running   0          3h28m

4. Avanza a Validación y observación para validar que tus eventos, métricas y rastreos de aplicaciones fluyan a Elasticsearch.

Instrumentar tus propias aplicaciones con OpenTelemetry

En esta sección se asume que instrumentarás tus propias aplicaciones con OpenTelemetry. Para que tus aplicaciones funcionen con el modelo de despliegue presentado en este artículo, deberán cumplir lo siguiente:

  1. Estar instrumentadas con una versión de Agente de APM de OpenTelemetry estable
  2. Estar instanciadas con variables específicas del entorno de OpenTelemetry
  3. En caso de usar instrumentación manual, tener ciertas propiedades de intervalo configuradas correctamente
  4. Agregar, opcionalmente, ciertos metadatos a las líneas de logs
  5. Emitir datos de logs a stdout y stderr para que los capture la integración Elastic Kubernetes

Variables de entorno de contenedor

A fin de habilitar los dashboards de APM listos para usar de Elastic, necesitamos asegurarnos de que los eventos, métricas y rastreos de las aplicaciones lleven los metadatos contextuales adecuados. Podemos obtener estos metadatos de la API Downward de Kubernetes, pasándola a la aplicación a través de la variable de entorno OTEL_RESOURCE_ATTRIBUTES.

También debemos configurar OTEL_EXPORTER_OTLP_ENDPOINT para dirigir las aplicaciones a enviar sus datos de OpenTelemetry a través de OTLP a la instancia del recopilador de OpenTelemetry que luego desplegaremos en el DaemonSet del nodo.

El siguiente fragmento de configuración del contenedor de Kubernetes prepara las variables del entorno que necesitarás aplicar a tus aplicaciones en su YAML de despliegue.

---
apiVersion: apps/v1
kind: Deployment
...
spec:
  ...
  template:
    ...
    spec:
      containers:
        ...
        env:
          - name: OTEL_K8S_CONTAINER_NAME
            valueFrom:
              fieldRef:
                apiVersion: v1
                fieldPath: "metadata.labels['app.kubernetes.io/component']"
          - name: OTEL_K8S_NODE_IP
            valueFrom:
              fieldRef:
                fieldPath: status.hostIP
          - name: OTEL_K8S_POD_UID
            valueFrom:
              fieldRef:
                apiVersion: v1
                fieldPath: metadata.uid
          - name: OTEL_K8S_POD_IP
            valueFrom:
              fieldRef:
                apiVersion: v1
                fieldPath: status.podIP
          - name: OTEL_SERVICE_NAME
            valueFrom:
              fieldRef:
                apiVersion: v1
                fieldPath: "metadata.labels['app.kubernetes.io/component']"
          - name: OTEL_K8S_NAMESPACE
            valueFrom:
              fieldRef:
                apiVersion: v1
                fieldPath: metadata.namespace
          - name: OTEL_K8S_NODE_NAME
            valueFrom:
              fieldRef:
                apiVersion: v1
                fieldPath: spec.nodeName
          - name: OTEL_K8S_POD_NAME
            valueFrom:
              fieldRef:
                apiVersion: v1
                fieldPath: metadata.name
          - name: OTEL_EXPORTER_OTLP_ENDPOINT
            value: '$(OTEL_K8S_NODE_IP):4317'
          - name: OTEL_RESOURCE_ATTRIBUTES
            value: service.name=$(OTEL_SERVICE_NAME),k8s.namespace.name=$(OTEL_K8S_NAMESPACE),k8s.node.name=$(OTEL_K8S_NODE_NAME),k8s.pod.name=$(OTEL_K8S_POD_NAME),k8s.pod.uid=$(OTEL_K8S_POD_UID),k8s.pod.ip=$(OTEL_K8S_POD_IP),k8s.container.name=$(OTEL_K8S_CONTAINER_NAME),k8s.container.restart_count=0

Quizá te preguntes por qué configuramos k8s.container.restart_count=0 como un atributo de recursos. El procesador k8sattrribute del recopilador de OpenTelemetry actual requiere esta sugerencia para vincular un contenedor (a través dek8s.container.name) con una instancia en ejecución de un contenedor a fin de obtener un container.id. Configurar k8s.container.restart_count=0 es una simplificación: realizar un seguimiento de cuántas veces Kubernetes reinició un contenedor dado en un pod e introducir eso en una variable de entorno sería complicado. En situaciones típicas, un contenedor por lo general solo se inicia una vez durante la vida útil de un pod dado. Sin embargo, si el pod reinicia el contenedor, esta simplificación fallará.

Propiedades de intervalo

APM de Elastic necesita que ciertas propiedades de intervalo se configuren de forma explícita para caracterizar, clasificar y visualizar correctamente los datos de intervalo. La mayoría de las bibliotecas de autoinstrumentación de APM de OpenTelemetry configurarán estos campos por ti. Sin embargo, si instrumentas tu aplicación de forma manual, tendrás que configurar de forma explícita las propiedades siguientes:SpanKind: A fin de que APM de Elastic clasifique correctamente los intervalos, debe conocer el SpanKind (por ejemplo, INTERNAL, SERVER, CLIENT). La mayoría de las bibliotecas de autoinstrumentación de APM de OpenTelemetry configurarán este campo por ti. Sin embargo, si instrumentas manualmente tu aplicación, debes configurar SpanKind como SERVER para los intervalos que aceptan llamadas de RPC o REST, como CLIENT para los intervalos que inician llamadas de RPC o REST o base de datos, y como INTERNAL (predeterminado) para las llamadas de funciones dentro de un servicio. En Java, por ejemplo, configurarías SpanKind como SERVER para un intervalo que recibe una llamada de gRPC con algo así:

Span span = tracer.spanBuilder("testsystem.TestService/TestFunction").setSpanKind(SpanKind.SERVER).startSpan();

RpcSystem/DbSystem: A fin de que APM de Elastic clasifique correctamente los intervalos, necesita saber si el intervalo representa una transacción de RPC o una transacción de base de datos, y qué tipo de sistema de RPC o DB se está usando. La mayoría de las bibliotecas de autoinstrumentación de APM de OpenTelemetry configurarán este campo por ti. Si instrumentas tu aplicación manualmente, deberías configurar el atributo de intervalo RpcSystem o DbSystem. En Rust, por ejemplo, configurarías RpcSystem como 'grpc' para un intervalo que recibe una llamada de gRPC con algo así:

span.set_attribute(semcov::trace::RPC_SYSTEM.string("grpc"));

NetPeerHost y NetPeerPort: A fin de que APM de Elastic mapee correctamente las dependencias entre servicios, cuando SpanKind esté configurado como CLIENT (es decir, una llamada de base de datos o gRPC saliente), los atributos de intervalo NetPeerName y NetPeerPort deben configurarse para indicar el destinatario objetivo de la llamada. Algunas de las bibliotecas de autoinstrumentación de APM de OpenTelemetry configurarán este campo por ti. Si instrumentas manualmente tu aplicación, debes configurar explícitamente estos atributos. En JavaScript, por ejemplo, configurarías NetPeerName y NetPeerPort para un intervalo enviando una llamada de gRPC con algo así:

// this => grpcJs.Client, this.getChannel().getTarget() => "dns:elastic-otel-productcatalogservice:8080"
const URI_REGEX = /(?:([A-Za-z0-9+.-]+):(?:\/\/)?)?(?<name>[A-Za-z0-9+.-]+):(?<port>[0-9+.-]+)$/;
const parsedUri = URI_REGEX.exec(this.getChannel().getTarget());        
if (parsedUri != null && parsedUri.groups != null) {
    span.setAttribute(SemanticAttributes.NET_PEER_NAME, parsedUri.groups['name']);
    span.setAttribute(SemanticAttributes.NET_PEER_PORT, parseInt(parsedUri.groups['port']));
}

Atributos de logs

El APM de Elastic APM puede correlacionar líneas de log específicas con rastreos específicos. A fin de habilitar esta funcionalidad, las líneas de log que surgen de tu aplicación deben etiquetarse con pares de clave/valor span.id y trace.id donde corresponda. Algunos de los agentes de APM de Elastic (por ejemplo, el agente Java) modificarán automáticamente tu plantilla de logging para agregar estos metadatos contextuales.

Despliega el recopilador de OpenTelemetry en el DaemonSet

Si estás trabajando con la demostración de OpenTelemetry y nuestros gráficos de Helm de OpenTelemetry modificados, ya se instaló un recopilador de OpenTelemetry optimizado en el DaemonSet de cada nodo por ti.

Si estás instrumentando tus propias aplicaciones, puedes usar el YAML siguiente como base para configurar y desplegar el recopilador de OpenTelemetry en el DaemonSet en los nodos de tu cluster. La configuración ilustrativa (desplegada con un ConfigMap) ingesta los datos de rastreo, métricas y eventos de OTLP desde las aplicaciones en el puerto TCP 4317 (grpc) y 4318 (http). Como el recopilador se ejecuta en el DaemonSet, es posible llegar a ese puerto desde otros pods que se ejecutan en el mismo nodo a través de la IP del nodo. Los datos de OTLP entrantes se pasan por el procesador k8attributes para anexar container.id. Descartamos cualquier dato de log que pueda estar ingresando (recuerda que obtenemos estos datos a través de la integración Elastic Kubernetes) y pasamos los rastreos, eventos y métricas a la integración de APM de Elastic que también se ejecuta en el DaemonSet. La integración de APM de Elastic escucha en el puerto 8200, también se puede llegar a través de la IP del nodo (que se pasa aquí como una variable de entorno obtenida de la API Downward de Kubernetes).

1. Descarga este YAML de despliegue de recopilador de OpenTelemetry ilustrativo.

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

2. Edítalo como apropiado para tu despliegue.

3. Aplícalo a tu cluster de Kubernetes.

kubectl apply -f otel-collector.yaml

Validación y observación

En esta sección, validaremos que los datos de observabilidad y seguridad que configuramos antes estén ingresando en nuestro cluster de Elasticsearch como esperábamos. Este ejercicio también servirá como una breve visión general de algunos de los dashboards de seguridad y observabilidad listos para usar que están a tu disposición dentro de Elasticsearch. Te alentamos a usar esto como punto de partida para explorar nuestras completas ofertas de visualización y analíticas.

Mapa de servicios de APM

El mapa de servicios de APM proporciona una visualización de tus servicios y su relación entre sí. Se resaltarán ciertos tipos de alertas y errores de servicio en este mapa, según corresponda. Desde este mapa, puedes cambiar a una vista detallada de cualquier servicio instrumentado con OpenTelemetry (o el propio agente de APM de Elastic).

  1. En la barra lateral de navegación de Kibana, selecciona [ APM ] en [ Observability ] (Observabilidad).
  2. Selecciona [ Service Map ] (Mapa de servicios) en [ APM ].
Video thumbnail

Servicio de APM

La vista APM Service (Servicio de APM) brinda una visión general de un servicio dado. Desde este dashboard, puedes explorar con facilidad rastreos, logs y métricas de infraestructura relacionadas. Históricamente, una correlación primitiva entre estas fuentes de datos requeriría la traducción manual de las marcas de tiempo y los identificadores de servicio en todas las plataformas de observabilidad en silos. Con Elastic y OpenTelemetry, esta correlación se realiza de forma automática, lo que permite a los analistas, operadores y desarrolladores enfocarse en el análisis de causa raíz en lugar de en los matices de las herramientas de observabilidad.

  1. En la barra lateral de navegación de Kibana, selecciona [ APM ] en [ Observability ] (Observabilidad).
  2. Selecciona [ Service Map ] (Mapa de servicios) en [ APM ].
  3. Haz clic derecho sobre cualquier servicio en el mapa.
  4. Selecciona [ Service Details ] (Detalles del servicio).
Video thumbnail

Desde esta misma vista, puedes cambiar con facilidad al examen de transacciones e intervalos que conectan a tus usuarios con los servicios y a los servicios entre sí.

  1. Selecciona [ Transactions ] (Transacciones) en el encabezado.
  2. Selecciona una transacción que te interese desde la subsección [ Transactions ] (Transacciones).
Video thumbnail

Métricas de cluster de Kubernetes

Los dashboards de Elastic Kubernetes proporcionan tanto una visión general como una vista detallada de las operaciones en tu cluster de Kubernetes. Desde adentro, puedes monitorear las métricas de todos los clusters, nodos, pods, DaemonSets, servicios y más.

  1. En la barra lateral de navegación de Kibana, selecciona [ Dashboard ] en [ Analytics ] (Analíticas).
  2. Selecciona [ Kubernetes ] en el menú [ Tags ] (Etiquetas).
  3. Selecciona el dashboard [ Cluster Overview ] (Visión general del cluster).
Video thumbnail

Monitoreo de procesos de Kubernetes

La integración Elastic Defend proporciona observabilidad centrada en la seguridad en todos tus recursos de Kubernetes. El dashboard de seguridad de Kubernetes permite a los analistas comprender exactamente qué procesos se ejecutaron en tus nodos de Kubernetes, cuándo, con qué parámetros de tiempo de ejecución y en qué cuenta.

  1. En la barra lateral de navegación de Kibana, selecciona [ Dashboard ] en [ Security ] (Seguridad).
  2. Selecciona [ Kubernetes ].

Video thumbnail

Gestión de postura de seguridad de Kubernetes

El dashboard Kubernetes Security Posture Management (Gestión de postura de seguridad de Kubernetes, KSPM) proporciona recomendaciones de análisis y corrección automáticas en toda una gama de mejores prácticas de Kubernetes para un despliegue seguro. Para los desarrolladores y el personal de DevOps, este dashboard puede proporcionar avisos invaluables sobre potenciales problemas de configuración antes de que se conviertan en un problema en producción.

  1. En la barra lateral de navegación de Kibana, selecciona [ Dashboard ] en [ Security ] (Seguridad).
  2. Seleccione [ Cloud Posture ] (Postura en el cloud).
Video thumbnail

Análisis del tráfico de red

La integración Captura de paquetes de red te permite profundizar en el tráfico de IP que ingresa a tus nodos de Kubernetes y egresa de ellos, y buscar servicios con un mal comportamiento o una vulneración de seguridad.

  1. En la barra lateral de navegación de Kibana, selecciona [ Explore ] (Explorar) en [ Security ] (Seguridad).
  2. Selecciona [ Network ] (Red).

Video thumbnail

Elastic: Observabilidad y seguridad creadas para Kubernetes

Kubernetes representa un modelo de despliegue de aplicaciones completamente nuevo para muchas empresas. Un modelo de despliegue completamente nuevo requiere de un enfoque igual de integral, moderno y abierto respecto de la observabilidad y la seguridad. Como se muestra aquí, la plataforma de Elastic tiene una posición única en la industria para proporcionar una observabilidad y seguridad totalmente integradas, con todas las características y de fidelidad total para Kubernetes.

¿Te interesa? Ponte en contacto con nuestro equipo de preventa para comenzar a crear con Elastic.

Sign up for Elastic Cloud free trial

Spin up a fully loaded deployment on the cloud provider you choose. As the company behind Elasticsearch, we bring our features and support to your Elastic clusters in the cloud.

Start free trial