Nota:

• Questa esercitazione richiede l'accesso a Oracle Cloud. Per iscriversi a un account gratuito, consulta Inizia a utilizzare Oracle Cloud Infrastructure Free Tier.
• Utilizza valori di esempio per le credenziali, la tenancy e i compartimenti di Oracle Cloud Infrastructure. Al termine del laboratorio, sostituisci questi valori con quelli specifici del tuo ambiente cloud.

Installa Tetragon e configura TracingPolicies su Oracle Container Engine for Kubernetes

Introduzione

Poiché gli strumenti basati su eBPF diventano più popolari per le applicazioni cloud native, questa esercitazione descrive come eseguire Tetragon, uno strumento basato su eBPF per l'osservabilità della sicurezza e l'applicazione su Oracle Cloud Infrastructure (OCI).

Che cos'è eBPF e perché è popolare?

Un kernel del sistema operativo è solitamente il posto migliore per osservare e influenzare un sistema in quanto ci sono pochissimi ostacoli tra lo strumento che esegue una funzione e le attività che sta cercando di osservare e influenzare. L'esecuzione all'interno dello spazio kernel spesso consente a un programma di avere costi generali molto bassi, ma a costo di sicurezza e manutenzione.

eBPF offre un metodo per introdurre nuove funzionalità che possono essere eseguite in un contesto sabbiato e privilegiato senza modificare il codice sorgente del kernel o caricare un modulo kernel. Funziona essenzialmente creando un paradigma simile a un linguaggio di programmazione basato su virtual machine. In modo simile al modo in cui i programmi Java moderni vengono compilati in byte-code compilato da JVM (Java Virtual Machine) nel codice nativo utilizzando un compilatore JIT per ottenere prestazioni native, i programmi eBPF dispongono di una rappresentazione byte-code. BPF è profondamente legato al kernel Linux e il compilatore JIT in-kernel compila il byte-code eBPF nel codice nativo che può essere eseguito nello spazio kernel.

eBPF utilizza un modello basato su eventi per caricare programmi e i programmi eBPF vengono scritti su "hook" in eventi di rete, chiamate di sistema e altro ancora. Quando un evento in cui un programma eBPF si collega è stato richiamato, il programma eBPF viene caricato nel kernel dopo la verifica e la compilazione JIT. Il passo di verifica garantisce che il programma sia sicuro da eseguire, disponga dei privilegi giusti e possa essere eseguito fino al completamento, mentre la compilazione JIT garantisce prestazioni native. In molti casi, i programmi eBPF sono scritti in lingue di livello superiore e compilati nella rappresentazione byte-code. Questi vengono quindi caricati in un kernel in esecuzione dopo la compilazione JIT in base agli eventi in cui i programmi sono collegati.

Tetragon - Osservabilità e applicazione della sicurezza basata su eBPF

Tetragon è uno strumento basato su eBPF cloud nativo che esegue l'osservabilità e l'applicazione della sicurezza. È una componente del progetto cilium. Utilizzando eBPF, Tetragon è in grado di filtrare e osservare gli eventi e applicare i criteri in tempo reale senza inviare eventi a un agente in esecuzione al di fuori del kernel. Tetragon può risolvere numerosi casi d'uso legati alla sicurezza e all'osservabilità filtrando eventi come un carico di lavoro che apre una connessione di rete, accede a un file o addirittura avvia un processo all'interno di un contenitore. Ad esempio, un processo shell avviato all'interno di un container di applicazioni potrebbe essere considerato un evento di sicurezza. Potrebbe trattarsi di un tentativo da parte di qualcuno di risolvere un problema o di un'attività dannosa, in entrambi i casi, che deve attivare un controllo di sicurezza per escludere un attacco al sistema. Lo stesso dicasi per le connessioni di rete aperte o per i file in lettura. Tetragon può tracciare e filtrare queste attività introducendo allo stesso tempo un sovraccarico minimo e, di solito, al primo stadio, che questi eventi possono essere rilevati nel software.

Tetragon è particolarmente adatto per i carichi di lavoro Kubernetes ed viene eseguito come daemonset in ogni nodo del cluster. Tetragon può quindi estrarre i metadati dal server API Kubernetes e correlare tali metadati agli eventi osservati nel kernel di ogni nodo. Tetragon semplifica l'impostazione di filtri in tempo reale per queste attività e altro ancora utilizzando TracingPolicies. TracingPolicy è una risorsa personalizzata creata da Tetragon che consente agli amministratori e a DevSecOps di creare e distribuire filtri per eventi kernel come risorse Kubernetes. Un TracingPolicy può corrispondere alle chiamate di sistema, agli attributi del processo e agli argomenti, nonché attivare un'azione sulle corrispondenze.

Obiettivo

• Scopri come impostare Tetragon su un cluster OKE in OCI.
• Scopri come utilizzare TracingPolicies per osservare e articolare gli eventi.

Prerequisiti

• Registrati o accedi al tuo account Oracle Cloud

• Creare un cluster OKE

  Nota: è possibile distribuire Tetragon in cluster Kubernetes come Oracle Container Engine for Kubernetes (OKE) utilizzando il grafico di controllo pubblicato dal progetto Tetragon. Una volta installata, la CRD TracingPolicy viene creata e Tetragon viene eseguito sui nodi cluster come daemonset.

Prerequisiti per Oracle Linux

OKE utilizza Oracle Linux e Tetragon si basa sul supporto BTF (BPF Type Format) nel kernel. I kernel Oracle Linux recenti includono questa funzionalità integrata, pertanto gli utenti devono utilizzare un kernel 5.4.17-2136.305.3.el7uek o più recente. Tetragon inoltre non fornisce supporto per l'architettura Arm (linux/arm64) e al momento della scrittura fornisce solo il supporto x86 (linux/amd64). Se nel cluster OKE sono presenti nodi braccio, il set di daemon rimarrà in stato Init:CrashLoopBackOff.

Nota: le versioni recenti delle immagini dei nodi OKE si basano su kernel che includono il supporto BTF. Questo avvertimento per il supporto BTF è applicabile solo ai cluster in cui il sistema operativo del nodo non è stato aggiornato in un determinato momento e non ai nuovi cluster creati. In caso di dubbi, il modo migliore per verificare se si dispone del supporto BTF è SSH al nodo ed eseguire ls /sys/kernel/btf, dovrebbe essere visualizzato il kernel (vmlinux) e i moduli elencati qui. Come nota generale, per questa distribuzione sono preferiti i nodi basati su Oracle Linux 8.

Per controllare la versione del kernel in esecuzione, eseguire uname -a sul nodo. Se si esegue una versione precedente del kernel, è possibile aggiornare la versione nella configurazione del pool di nodi. Ciò influisce solo sui nodi appena creati e i nodi esistenti non vengono aggiornati automaticamente per garantire la continuità dei carichi di lavoro che potrebbero essere in esecuzione. È possibile seguire il processo di aggiornamento del pool di nodi per portare i nodi esistenti alle versioni del kernel più recenti.

• Una volta assicurata l'esecuzione di una versione recente del kernel sui nodi, è possibile iniziare con l'installazione di Tetragon utilizzando il grafico di riferimento di Tetragon. Puoi seguire anche le istruzioni della pagina github di 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
  
  

• Quando il set di daemon è pronto e i pod di tetragon sono in esecuzione, è possibile iniziare ad ascoltare gli eventi sui nodi. È ora in grado di monitorare l'esecuzione dei processi. Tetragon emette gli eventi corrispondenti in formato JSON e i log possono essere osservati con il seguente comando (a condizione che sia installato jq)

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

• A seconda dell'attività che si verifica sul cluster, verrà visualizzato un flusso di oggetti JSON che rappresentano questi eventi. Lo snippet di codice seguente è un output di esempio del cluster in cui è in esecuzione ArgoCD, in cui è stata clonata un repository 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"
  }
  

Il flusso di eventi come output JSON è dettagliato e difficile da comprendere, ma è denso di informazioni. Esistono diversi modi per includere questi dati JSON e ricavare informazioni analitiche da essi. L'ovvio consiste nell'utilizzare lo strumento CLI tetragon. Isovalent, l'azienda dietro Cilium e Tetragon offre anche un prodotto commerciale completo che può analizzare e visualizzare questi dati per renderli più fruibili e più facili da assimilare.

Task 1: installare l'interfaccia CLI tetra

• Il cli di Tetragon toll tetra è utile per filtrare gli eventi per pod, host, spazio di nomi o processo. È possibile scaricare l'interfaccia CLI dalla pagina delle release di Github. È possibile scaricare lo strumento in base all'architettura del sistema operativo e della CPU e untar in una posizione standard, ad esempio /usr/local/bin, oppure aggiungere il percorso del file binario alla variabile PATH per la shell.

• In alternativa, se nella workstation in cui si desidera eseguire il cli è installato go, è possibile scaricarlo e installarlo con i seguenti comandi:

  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}
  

• Dopo l'installazione dell'interfaccia CLI, gli eventi possono essere stampati passando l'output JSON a tetra getevents.

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

  L'opzione -o compact visualizza un output compatto anziché JSON. Lo strumento consente inoltre di limitare la visualizzazione dell'output a determinati spazi di nomi, processi e altro ancora. Di seguito è riportato l'elenco completo dei flag.

  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")
  

Task 2: Configurare TracingPolicies per FileAccess e l'osservabilità della rete

TracingPolicies sono risorse personalizzate che semplificano l'impostazione di filtri in tempo reale per gli eventi kernel. Un TracingPolicy corrisponde e filtra le chiamate di sistema per l'osservabilità, nonché attiva un'azione su queste corrispondenze. Tetragon offre alcuni esempi che mostrano questa capacità e possono essere utilizzati come punto di partenza per configurare il tuo TracingPolicies.

• Applicare i criteri di trace di esempio per FileAccess e 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 questi TracingPolicies aggiuntivi abilitati, Tetragon inizia a tenere traccia dell'accesso ai file e dell'attività di rete. L'output riportato di seguito mostra l'attività visualizzata dal kernel quando viene richiamato un comando curl. Mostra il programma curl che accede a file come etc/hosts e /etc/resolv.conf e che apre connessioni TCP e trasferisce i dati.

  $ 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]
  

Poiché questi eventi sono monitorati direttamente dall'interno del kernel, aggiunge pochissimo sovraccarico all'atto di rintracciare queste chiamate e molto poco può essere offuscato o mascherato da un attore maligno.

Il primo inconveniente di questo approccio è che le azioni che puoi intraprendere come dire, uccidere un processo che legge un file è reazionario, in quanto sappiamo dell'evento come sta accadendo, e non prima. Tuttavia, è estremamente potente poter disporre di una soluzione di sovraccarico ridotto per filtrare e abbinare eventi a livello kernel e riuscire a creare criteri che possano aiutarci a osservare e agire su di essi.

Risoluzione dei problemi

Errore: se vedi che i pod Tetragon sono in stato CrashLoopBackOff, questo potrebbe essere causato da due motivi.

Possibile motivo: il motivo più probabile è che questo si verifica sui nodi basati su Arm, se li hai nel tuo cluster. Tetragon non funziona ancora su Arm.

Risoluzione problemi:

• Per confermare, utilizzare

  kubectl describe pod
  

• Per visualizzare il contenitore di inizializzazione denominato tetragon-operator. Si tratta probabilmente di un errore e in uno stato terminato con un codice di uscita 1. È possibile utilizzare

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

• Per visualizzare i log del contenitore di inizializzazione, è possibile che venga visualizzato il motivo per cui il contenitore di inizializzazione termina come standard_init_linux.go:228: exec user process caused: exec format error, a indicare che il file binario non deve essere utilizzato nell'architettura della CPU Arm.

Il secondo motivo potrebbe essere che si dispone di un vecchio kernel nel nodo e il supporto BTF non è incluso. Per verificare se questo è in realtà il problema, richiedi i log del container per il container in cui si è verificato l'errore nel pod come descritto in precedenza. Se il problema è causato dalla mancanza di supporto BTF nel kernel, è possibile visualizzare un messaggio di errore simile 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

Ciò è previsto nei nodi in cui il sistema operativo non è stato aggiornato di recente o in versioni precedenti del sistema operativo. Per risolvere questo problema, puoi passare alle immagini OKE o della piattaforma più recenti basate su Oracle Linux 8 per i nodi di lavoro. È necessario aggiornare la configurazione del pool di nodi con questa scelta e i nodi aggiornati in base al processo di aggiornamento del pool di nodi standard.

Collegamenti correlati

• Documentazione OKE
• Documentazione di Tetragon
• Livello gratuito Oracle Cloud
• Accedere all'account Oracle Cloud

Approvazioni

• Autore - Jeevan Joseph (principal Product Manager senior)

Altre risorse di apprendimento

Esplora altri laboratori su docs.oracle.com/learn o accedi a contenuti di formazione gratuiti sul canale YouTube di Oracle Learning. Inoltre, visitare education.oracle.com/learning-explorer per diventare Explorer di Oracle Learning.

Per la documentazione sul prodotto, visitare il sito Oracle Help Center.

---

Titolo e informazioni sul copyright

Install Tetragon and configure TracingPolicies on Oracle Container Engine for Kubernetes

F74876-01

December 2022

Copyright © 2022, Oracle and/or its affiliates.