What the Epok agent can and can't see

What it collects

• Container logs. Vector reads the stdout/stderr records your applications already write to CRI log files. This is standard log shipping through read-only host mounts. Vector also uses a writable local directory for its delivery buffer.
• Kubernetes events. The OpenTelemetry k8s_events receiver watches the Kubernetes API for events such as pod eviction, failed scheduling, and OOM kills, and sends them as log records.
• Network-flow metrics. The eBPF collector observes which workload talks to which, byte/packet counts, and Kubernetes owner and namespace metadata. These metrics build the service map. It does not capture packet payloads, decrypted traffic contents, or request bodies, and it does not inject application code.

The payload boundary applies to network observation. If your application already writes a request body or a secret into a log line, that content can be shipped as a log. The bundle does not make application logs free of sensitive data.

Log namespace exclusions apply only to logs. By default, logs exclude kube-system, kube-public, and kube-node-lease; the events watcher and eBPF flow observation cover the cluster. Excluding a namespace's logs does not hide its events or network flows.

eBPF privileges and what they allow

The eBPF pod runs with privileged: false and allowPrivilegeEscalation: false. It drops all Linux capabilities, then adds the four listed below. Kubernetes spells capability names without the CAP_ prefix.

# eBPF pod in epok-collector 0.2.0 (default security settings)
spec:
  hostPID: true
  hostNetwork: true
  containers:
    - name: beyla
      securityContext:
        privileged: false
        allowPrivilegeEscalation: false
        capabilities:
          drop: [ALL]
          add: [BPF, PERFMON, SYS_PTRACE, NET_RAW]

These are real host permissions, even with privileged mode off. They describe the access granted; the configured network collector uses it for flow metrics. See Beyla's capability reference for the underlying permission semantics.

Kernel and runtime policies can prevent eBPF from loading with capabilities alone. --set ebpf.privileged=true is an explicit fallback that grants broad host access and removes this hardened capability restriction. Pod Security Standards restrictedor OpenShift SCC may reject either setup; a policy exception may be needed. Logs and events can run without eBPF. The eBPF service map needs Linux kernel >=5.8 with BTF.

Read-only Kubernetes RBAC

The collectors' ClusterRole grants only get, list, and watch on pods, namespaces, nodes, and events. With eBPF enabled, it also reads services and workload owners: ReplicaSets, Deployments, DaemonSets, and StatefulSets. This attaches Kubernetes metadata to the collected signals.

The agent has no Kubernetes API write access: no create, update, patch, or delete verbs. It does not mutate cluster resources. Installing or upgrading the Helm release creates or changes its resources using the installer's permissions; those permissions are not granted to the running collectors.

Egress and what leaves the cluster

All collected telemetry goes only to ingest.getepok.dev over HTTPS/TLS, authenticated by your tenant's ingest-scoped API key from Settings → API Keys. Only container logs, Kubernetes events, and network-flow metrics with their metadata are exported.

Container logs:      https://ingest.getepok.dev/api/v1/ingest
Kubernetes events:   https://ingest.getepok.dev/v1/logs
Network-flow metrics: https://ingest.getepok.dev/v1/metrics

There is no configured external telemetry destination beyond this ingest endpoint. The collectors also need in-cluster Kubernetes API access and DNS resolution. This describes the chart's configuration; it does not install an egress-enforcing NetworkPolicy. Changing the chart's endpoint changes the destination.

What it does not do

• No application code or bytecode injection, SDK changes, or application instrumentation.
• No packet-content or payload capture, request-body inspection, or TLS decryption.
• No cluster mutation by the running agent.
• No telemetry egress beyond the configured ingest endpoint.

This bundle observes logs, events, and network relationships. It does not supply the per-request spans, method-level execution details, or request contents associated with deep APM agents. For application traces, see the separate OpenTelemetry traces guide.