Nota:

• Este tutorial requiere acceso a Oracle Cloud. Para registrarse para obtener una cuenta gratuita, consulte Introducción al nivel gratuito de Oracle Cloud Infrastructure.
• Utiliza valores de ejemplo para las credenciales, el arrendamiento y los compartimentos de Oracle Cloud Infrastructure. Al finalizar el laboratorio, sustituya estos valores por otros específicos de su entorno en la nube.

Instale Tetragon y configure TracingPolicies en Oracle Container Engine for Kubernetes

Introducción

A medida que las herramientas basadas en eBPF se vuelven más populares para las aplicaciones nativas en la nube, este tutorial describe cómo ejecutar Tetragon, una herramienta basada en eBPF para la observabilidad y aplicación de la seguridad en Oracle Cloud Infrastructure (OCI).

¿Qué es eBPF y por qué es popular?

Un núcleo del sistema operativo suele ser el mejor lugar para observar e influir en un sistema, ya que hay muy pocas barreras entre la herramienta que realiza una función y las actividades que intenta observar e influir. La ejecución dentro del espacio del núcleo a menudo permite que un programa tenga una sobrecarga muy baja, pero a costa de la seguridad y el mantenimiento.

eBPF proporciona un método de introducción de nuevas funciones que se pueden ejecutar en un contexto con privilegios y sandbox sin cambiar el código fuente del núcleo ni cargar un módulo del núcleo. Básicamente funciona creando un paradigma similar a un lenguaje de programación basado en máquina virtual. De forma similar a cómo se compilan los programas Java modernos en código de byte que JVM (Java Virtual Machine) compila en código nativo mediante un compilador JIT para obtener el rendimiento nativo, los programas eBPF tienen una representación de código de byte. BPF está profundamente vinculado al núcleo de Linux y el compilador JIT del núcleo compila el código de byte eBPF en código nativo que se puede ejecutar en el espacio del núcleo.

eBPF utiliza un modelo basado en eventos para cargar programas y los programas eBPF se escriben para "enganchar" en eventos de red, llamadas a sistemas y mucho más. Cuando se ha llamado a un evento en el que un programa eBPF se conecta, el programa eBPF se carga en el núcleo después de la verificación y la compilación JIT. El paso de verificación garantiza que el programa sea seguro para ejecutarse, tenga los privilegios adecuados y se pueda ejecutar hasta su finalización, mientras que la compilación JIT garantiza el rendimiento nativo. En muchos casos, los programas eBPF se escriben en lenguajes de nivel superior y se compilan en la representación de código de byte. A continuación, se cargan en un núcleo en ejecución después de la compilación JIT en función de los eventos en los que se conectan los programas.

Tetragon - observabilidad y aplicación de la seguridad basada en eBPF

Tetragon es una herramienta nativa de la nube basada en eBPF que realiza observabilidad y aplicación de la seguridad. Es un componente del proyecto de cilio. Con eBPF, Tetragon puede filtrar y observar eventos y aplicar políticas en tiempo real sin enviar eventos a un agente que se ejecuta fuera del núcleo. Tetragon puede abordar numerosos casos de uso de seguridad y observabilidad filtrando para eventos como una carga de trabajo que abre una conexión de red, accede a un archivo o incluso inicia un proceso dentro de un contenedor. Por ejemplo, un proceso de shell que se inicia dentro de un contenedor de aplicaciones podría considerarse un evento de seguridad. Podría ser alguien que intenta solucionar un problema o podría ser una actividad maliciosa, de cualquier manera, algo que debería disparar una comprobación de seguridad para descartar un ataque al sistema. Lo mismo puede decirse sobre las conexiones de red que se abren o los archivos que se leen. Tetragon puede rastrear y filtrar estas actividades al tiempo que introduce poca o ninguna sobrecarga y generalmente en la primera etapa que estos eventos se pueden detectar en el software.

Tetragon es ideal para cargas de trabajo de Kubernetes y se ejecuta como daemonset en cada nodo del cluster. Tetragon puede extraer metadatos del servidor de API de Kubernetes y correlacionarlos con los eventos observados en el núcleo de cada nodo. Tetragon facilita la configuración de filtros en tiempo real para estas actividades y mucho más mediante TracingPolicies. TracingPolicy es un recurso personalizado creado por Tetragon que permite a los administradores y DevSecOps crear y desplegar filtros para eventos de núcleo como recursos de Kubernetes. Un TracingPolicy puede coincidir con llamadas del sistema, atributos de proceso y argumentos, y disparar una acción en las coincidencias.

Objetivo

• Descubra cómo configurar Tetragon en un cluster de OKE en OCI.
• Descubra cómo utilizar TracingPolicies para observar y corelar eventos.

Requisitos

• Conexión o conexión a la cuenta de Oracle Cloud

• Crear un cluster de OKE

  Nota: Tetragon se puede desplegar en clusters de Kubernetes como Oracle Container Engine for Kubernetes (OKE) mediante el gráfico de helm publicado por el proyecto Tetragon. Una vez instalada, se crea la CRD TracingPolicy y Tetragon se ejecuta en los nodos del cluster como daemonset.

Requisitos previos para Oracle Linux

OKE utiliza Oracle Linux y Tetragon depende de que la compatibilidad con BTF (formato de tipo BPF) en el núcleo. Los núcleos de Oracle Linux recientes incluyen esta lista para usar; por lo tanto, los usuarios deben usar un núcleo que sea 5.4.17-2136.305.3.el7uek o posterior. Tetragon tampoco proporciona soporte para la arquitectura de Arm (linux/arm64) y en el momento de la escritura sólo proporciona soporte x86 (linux/amd64). Si tiene nodos de brazo en el cluster de OKE, el conjunto de daemon permanecerá en el estado Init:CrashLoopBackOff.

Nota: Las versiones recientes de las imágenes de nodo de OKE se basan en núcleos que incluyen compatibilidad con BTF. Esta advertencia para el soporte de BTF sólo se aplica a los clusters en los que el sistema operativo del nodo no se ha actualizado en un momento y no a los clusters recién creados. Si no está seguro, la mejor manera de comprobar si tiene compatibilidad con BTF es utilizar SSH en el nodo y ejecutar ls /sys/kernel/btf, debe ver el núcleo (vmlinux) y los módulos que se muestran aquí. Como nota general, se prefieren los nodos basados en Oracle Linux 8 para este despliegue.

Para comprobar la versión del núcleo que los nodos están ejecutando, ejecute uname -a en el nodo. Si ejecuta una versión anterior del núcleo, puede actualizar la versión en la configuración del pool de nodos. Sin embargo, esto sólo afecta a los nodos recién creados y los nodos existentes no se actualizan automáticamente para garantizar la continuidad de las cargas de trabajo que se pueden ejecutar en ellos. Puede seguir el proceso de actualización del pool de nodos para actualizar los nodos existentes a las versiones más recientes del núcleo.

• Una vez que se haya asegurado de que se está ejecutando en una versión reciente del núcleo en los nodos, puede comenzar con la instalación de Tetragon mediante el gráfico helm de Tetragon. También puedes seguir las instrucciones de la página de github de Tetragon.

  helm repo add cilium https://helm.cilium.io
  helm repo update
  helm install tetragon cilium/tetragon -n kube-system
  kubectl rollout status -n kube-system ds/tetragon -w
  
  

• Una vez que el conjunto de daemon esté listo y los pods de tetragon tengan el estado Running, puede empezar a recibir eventos en los nodos. Inicialmente, puede supervisar la ejecución de procesos. Tetragon emite los eventos coincidentes en formato JSON y los logs se pueden observar con el siguiente comando (suponiendo que tenga instalado jq).

  kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon -c export-stdout -f | jq
  

• Según la actividad que se produzca en el cluster, verá un flujo de objetos JSON que representan estos eventos. El siguiente fragmento de código es una salida de ejemplo del cluster que estaba ejecutando ArgoCD, donde estaba clonando un repositorio de git.

  {
    "process_exec": {
      "process": {
        "exec_id": "MTAuMC4xMC4yMTg6OTE0MTQ2NjAzODU0MDcwOjEwNDA4Ng==",
        "pid": 104086,
        "uid": 999,
        "cwd": "/tmp/_argocd-repo/83c509d8-f9ba-48c3-a217-a9278134963e/",
        "binary": "/usr/bin/git",
        "arguments": "rev-parse HEAD",
        "flags": "execve clone",
        "start_time": "2022-06-07T17:03:42.519Z",
        "auid": 4294967295,
        "pod": {
          "namespace": "argocd",
          "name": "argocd-repo-server-7db4cc4b45-cpvlt",
          "container": {
            "id": "cri-o://1c361244fcb1d89c02ef297e69a13bd80fd4d575ae965a92979deec740711e17",
            "name": "argocd-repo-server",
            "image": {
              "id": "quay.io/argoproj/argocd@sha256:85d55980e70f8f7073e4ce529a7bbcf6d55e51f8a7fc4b45d698f0a7ffef0fea",
              "name": "quay.io/argoproj/argocd:v2.3.4"
            },
            "start_time": "2022-05-31T16:57:53Z",
            "pid": 319
          }
        },
        "docker": "1c361244fcb1d89c02ef297e69a13bd",
        "parent_exec_id": "MTAuMC4xMC4yMTg6MzA4OTk3NTAyODQyMTEzOjExMjQ3",
        "refcnt": 1
      }
    },
    "node_name": "10.0.10.218",
    "time": "2022-06-07T17:03:42.519Z"
  }
  

El flujo de eventos como salida de JSON es detallado y difícil de entender, pero es información densa. Hay varias formas de ingerir estos datos JSON y derivar información analítica de ellos. Lo obvio es utilizar la herramienta de CLI tetragon. Isovalente, la empresa detrás de Cilium y Tetragon también ofrece un producto comercial completo que puede analizar y visualizar estos datos para hacerlo más práctico y fácil de asimilar.

Tarea 1: Instalación de la CLI tetra

• Tetragon cli tol tetra es útil para filtrar eventos por pod, host, espacio de nombres o proceso. La CLI se puede descargar desde la página de versiones de github. Puede descargar la herramienta en función de la arquitectura del sistema operativo y de la CPU, y untar en una ubicación estándar como /usr/local/bin o agregar la ruta al binario a la variable PATH del shell.

• Como alternativa, si tiene go instalado en la estación de trabajo donde desea ejecutar la cli, puede descargarla e instalarla con los siguientes comandos:

  GOOS=$(go env GOOS)
  GOARCH=$(go env GOARCH)
  curl -L --remote-name-all https://github.com/cilium/tetragon/releases/latest/download/tetra-${GOOS}-${GOARCH}.tar.gz{,.sha256sum}
  sha256sum --check tetra-${GOOS}-${GOARCH}.tar.gz.sha256sum
  sudo tar -C /usr/local/bin -xzvf tetra-${GOOS}-${GOARCH}.tar.gz
  rm tetra-${GOOS}-${GOARCH}.tar.gz{,.sha256sum}
  

• Una vez instalada la CLI, los eventos se pueden imprimir con bastante facilidad transfiriendo la salida de JSON a tetra getevents.

  kubectl logs -n kube-system ds/tetragon -c export-stdout -f | tetra getevents -o compact
  

  La opción -o compact muestra una salida compacta en lugar de JSON. La herramienta también permite restringir la visualización de salida a determinados espacios de nombres, procesos, etc. La lista completa de indicadores se muestra a continuación

  Usage:
    tetra getevents [flags]
  
  Flags:
        --color string        Colorize compact output. auto, always, or never (default "auto")
    -h, --help                help for getevents
        --host                Get host events
    -n, --namespace strings   Get events by Kubernetes namespaces
    -o, --output string       Output format. json or compact (default "json")
        --pod strings         Get events by pod name regex
        --process strings     Get events by process name regex
        --timestamps          Include timestamps in compact output
  
  Global Flags:
    -d, --debug                   Enable debug messages
        --server-address string   gRPC server address (default "localhost:54321")
  

Tarea 2: Configurar TracingPolicies para FileAccess y observación de red

TracingPolicies son recursos personalizados que facilitan la configuración de filtros en tiempo real para eventos de núcleo. Un TracingPolicy coincide y filtra las llamadas del sistema para la observabilidad y también dispara una acción en estas coincidencias. Tetragon ofrece algunos ejemplos que muestran esta capacidad y se pueden utilizar como punto de partida para configurar TracingPolicies.

• Aplicar las políticas de rastreo de ejemplo para FileAccess y Observability

  kubectl apply -f https://raw.githubusercontent.com/cilium/tetragon/main/crds/examples/sys_write_follow_fd_prefix.yaml
  kubectl apply -f https://raw.githubusercontent.com/cilium/tetragon/main/crds/examples/tcp-connect.yaml
  

• Con estos TracingPolicies adicionales activados, Tetragon inicia el rastreo del acceso a archivos y la actividad de red. La siguiente salida muestra la actividad que se ve desde el núcleo cuando se llama a un comando curl. Muestra el programa curl que accede a archivos como etc/hosts y /etc/resolv.conf, y abre conexiones TCP y transfiere datos.

  $ kubectl logs -n kube-system ds/tetragon -c export-stdout -f | tetra getevents -o compact
  
  ...[output truncated]
  🚀 process default/xwing /usr/bin/curl -Lv https://cloud.oracle.com
  📬 open    default/xwing /usr/bin/curl /etc/ssl/openssl.cnf
  📪 close   default/xwing /usr/bin/curl
  📬 open    default/xwing /usr/bin/curl /etc/hosts
  📪 close   default/xwing /usr/bin/curl
  📬 open    default/xwing /usr/bin/curl /etc/resolv.conf
  📪 close   default/xwing /usr/bin/curl
  🔌 connect default/xwing /usr/bin/curl tcp 10.244.1.152:65175 -> 23.212.250.69:443
  📬 open    default/xwing /usr/bin/curl /etc/ssl/certs/ca-certificates.crt
  📪 close   default/xwing /usr/bin/curl
  📤 sendmsg default/xwing /usr/bin/curl tcp 10.244.1.152:65175 -> 23.212.250.69:443 bytes 517
  📤 sendmsg default/xwing /usr/bin/curl tcp 10.244.1.152:65175 -> 23.212.250.69:443 bytes 126
  📤 sendmsg default/xwing /usr/bin/curl tcp 10.244.1.152:65175 -> 23.212.250.69:443 bytes 109
  📤 sendmsg default/xwing /usr/bin/curl tcp 10.244.1.152:65175 -> 23.212.250.69:443 bytes 31
  🧹 close   default/xwing /usr/bin/curl tcp 10.244.1.152:65175 -> 23.212.250.69:443
  💥 exit    default/xwing /usr/bin/curl -Lv https://cloud.oracle.com 0
  💥 exit    default/xwing /bin/bash  0
  ...[output truncated]
  

Como estos eventos se supervisan directamente desde el núcleo, agrega muy poca sobrecarga al acto de rastrear estas llamadas y muy poco puede ser ofuscado o enmascarado por un actor malicioso.

La desventaja principal de este enfoque es que las acciones que puede tomar como, por ejemplo, matar un proceso que lee un archivo es reaccionario, en que sabemos sobre el evento como está sucediendo, y no antes. Aún así, es extremadamente potente poder tener una solución de baja sobrecarga para filtrar y confrontar eventos en el nivel del núcleo y poder crear políticas que puedan ayudarnos a observarlos y actuar sobre ellos.

Resolución de problemas

Error: si ve que los pods de Tetragon están en estado CrashLoopBackOff, esto podría deberse a dos motivos.

Posible motivo: el motivo más probable es que esto ocurra en nodos basados en Arm, si los tiene en el cluster. Tetragon aún no se ejecuta en Arm.

Solución de problemas:

• Para confirmar, utilice

  kubectl describe pod
  

• Para ver el contenedor de inicialización denominado tetragon-operator. Probablemente esto esté fallando y en un estado terminado con un código de salida de 1. Puede utilizar

  kubectl logs <pod_name> -c tetragon-operator -n kube-system
  

• Para ver los logs de contenedor de inicialización y es posible que vea el motivo por el que el contenedor de inicialización termina como standard_init_linux.go:228: exec user process caused: exec format error, lo que indica que el binario no está pensado para su uso en la arquitectura de CPU de Arm.

El segundo motivo podría ser que tiene un núcleo antiguo en el nodo y la compatibilidad con BTF no está incluida. Para verificar si, de hecho, este es el problema, obtenga los logs del contenedor con fallos en el pod como se describe anteriormente. Si la falta de compatibilidad de BTF en el núcleo es el problema, puede ver un mensaje de error similar al

aborting. kernel autodiscovery failed: Kernel version BTF search failed kernel is not included in supported list.
Use --btf option to specify BTF path and/or '--kernel' to specify kernel version

Esto se espera en nodos que no hayan actualizado su sistema operativo recientemente o en versiones anteriores del sistema operativo. Para resolver esto, puede cambiar a las últimas imágenes de plataforma o OKE basadas en Oracle Linux 8 para los nodos de trabajador. La configuración del pool de nodos se debe actualizar con esta opción y los nodos se deben actualizar después del proceso de actualización del pool de nodos estándar.

Enlaces relacionados

• Documentación de OKE
• Documentación de Tetragon
• Cuenta gratuita de Oracle Cloud
• Conectarse a la cuenta de Oracle Cloud

Agradecimientos

• Autor: Jeevan Joseph (mánager de productos principal sénior)

Más recursos de aprendizaje

Explore otros laboratorios en docs.oracle.com/learn o acceda a más contenido de aprendizaje gratuito en el canal YouTube de Oracle Learning. Además, visite education.oracle.com/learning-explorer para convertirse en un explorador de Oracle Learning.

Para obtener documentación sobre los productos, visite Oracle Help Center.

---

Título e Información de Copyright

Install Tetragon and configure TracingPolicies on Oracle Container Engine for Kubernetes

F74876-01

December 2022

Copyright © 2022, Oracle and/or its affiliates.