sean/tetragon

Tetragon runtime security (observe-only) for the seanfarm cluster. Argo CD Application tetragon syncs the vendored manifests and observe-only TracingPolicies.

Changes to this repository are built and released by Binjovi before Argo CD applies the development deployment. The release records remain the source of truth for the applied revision.

• Canonical home: Forgejo code.sean.farm/sean/tetragon (push here). Codeberg someara/tetragon is the private backup and rebuild seed. A Forgejo push mirror sends each main and trunk commit and every tag to that backup. The ForgejoRepository importSource restores it on a rebuild.
• Seed: seanfarm kubernetes/flux/infrastructure/tetragon-argocd/manifest.yaml (namespace, AppProject, repository Secret, Application, and webhook). Flux owns only that seed. Argo CD owns everything in this repository.
• Delivery: Binjovi owns the protected provider path and writes the required binjovi/ci check on pull requests against trunk. A Release merges the selected green Builds, validates their combined trunk, advances main, and verifies the Argo CD target. Builds use the native executor; they do not use Argo Workflows or a shadow check. The root kustomization.yaml is the direct Argo CD validation root. YAML below vendor/ can contain Helm values and does not have to be a Kubernetes object. The native task context contains the fixed validator bridge and typed task data only.
• Scope: workers only (nodeSelector: node-pool=platform). The control-plane node runs a pre-BTF kernel (seanfarm21) and Tetragon requires /sys/kernel/btf/vmlinux; it gains coverage when it rolls to ≥ seanfarm28.
• Vendor: see UPSTREAM.md for the checksum-verified re-render procedure. Never hand-edit vendor/tetragon-v1.7.0.yaml.

Policies (policies/)

All observe-only — every action is Post with a per-process rate limit; there is deliberately no enforcement (no Sigkill/Override) anywhere in this repo.

Policy	Scope	Watches
sensitive-file-reads	cluster	opens of /etc/shadow, /etc/rancher/, k3s server/agent credential paths
build-egress-connections	binjovi-builds, shipwright-build	TCP connects to non-RFC1918 destinations (true internet egress from the build surface)
fileless-or-tmpfs-exec	cluster	execs from /dev/shm/ or memfd (fileless payloads); /tmp excluded by design

Attribution caveat: a pod that execs and exits faster than the k8s informer can associate it (≲5 s pod lifetime) may export without pod attribution — its exec/exit then match the host ("") denylist entry and its kprobe events can be dropped by the event cache. Verified live 2026-08-05: a cat /etc/shadow in a ~2 s pod left no export trace; the same read from a pod alive ~30 s exported a fully-attributed process_kprobe. Pod creation is still visible to the cluster; treat sub-informer-lag pods as a known blind spot of the export stream, not of the kernel sensor (NPOST still counts).

Events flow: agent → export-stdout sidecar → Alloy → Loki ({namespace="tetragon", container="export-stdout"}); metrics are scraped by the olly vmagent via the prometheus.io/* pod annotations (agent :2112, operator :2113). Grafana dashboard uid tetragon ships in dashboard.yaml and is linked from the portal.

Exported events omit process.arguments and parent.arguments. A shell parent can contain its complete script in parent.arguments, which repeats tens of kilobytes for every child process. Arguments can also contain secrets. Tracing policies evaluate events before this export filter, so detection keeps its full kernel-side input while Loki receives bounded evidence.

The JSON exporter allows only PROCESS_KPROBE. All policies in policies/ use kprobes. Plain process start and exit events support Tetragon's internal process model, but they are not security-policy evidence. The agent still processes them; it does not send them to Loki. The contract in tests/ fails if a future policy needs another exported event type.

Event-volume knobs (in escalation order)

tetragon.fieldFilters (drop large or sensitive fields) → widen exportDenyList → per-policy rateLimit → exportRateLimit (global, currently 12000/min). Watch tetragon_export_rate_limit_dropped_total.

The build egress policy observes binjovi-builds, where native Binjovi tasks run. It reports network connections; it does not block them or trace commands inside remote IBM i systems or virtual machine guests.

Native pipeline timing

Binjovi uses native agents for this project's Build, Release, and Deploy tasks. The configured deployment target is tetragon-development. The deployment checks both the Tetragon agent and operator metrics endpoints.

Select an exact successful Build when you release:

binjovictl builds tetragon
binjovictl release tetragon --build BUILD_ID --wait
binjovictl status tetragon

Open the project dashboard and expand an execution attempt to inspect its task timeline and available profiles. The latest completed pipeline summary includes Build and Release time as well as deployment time. Check the Deploy result separately after Release completes. Telemetry explains execution; the stored revision and verification evidence establish completion.