Continuous profiling is now GA

Last updated:

Profiling Security

Understand why eBPF profilers need privileged access, what they do with it, and what data profiles and debuginfo uploads contain.

Host-wide eBPF profilers, such as the Parca Agent and the OpenTelemetry eBPF Profiler, need privileged access to the nodes they profile. This page explains why, and what data leaves the node.

Why the profiler needs privileges

The operator-managed Parca Agent uses these privileges:

PrivilegeWhy the agent needs it
Privileged container that runs as rootThe Linux kernel only lets a privileged process load the eBPF programs that sample call stacks.
hostPID: trueDiscover the processes on the node and attribute samples to their processes, containers, and pods. Without it, profiles would only carry process IDs.
Read-only host /procRead process metadata and memory mappings to find the binary behind each frame.
Read-only host /sysUse the kernel's BPF and cgroup interfaces, and discover container metadata.
/tmp volume, local to the podStage debuginfo files before upload.

The agent's pod does not mount a service account token and has no Kubernetes API permissions. The operator restricts access to its debuginfo proxy with a NetworkPolicy, which your cluster's CNI must enforce.

The agent can see every process visible from the node's PID namespace, not only workloads in namespaces monitored by Dash0. If your cluster enforces Pod Security Admission, the operator namespace must allow privileged pods. See Security and namespace ownership.

To profile without privileged access, scrape pprof endpoints with Parca or use a runtime profiler.

What profiles contain

Profiles describe how code runs, not the data it processes. A profile contains:

  • Call stacks: Function names, source file paths, line numbers, binary names, build IDs, and memory addresses.
  • Sample values: The measurement for each stack, such as CPU time.
  • Resource attributes: Workload identity, such as the Kubernetes namespace, pod, and container, and the process ID and executable.
  • Profiling labels: Labels your application attaches to its own profiling data, such as Go pprof labels.

Profiles are not designed to capture request payloads, personal data, or credentials. Your code can still put such values into profiling labels, so do not attach sensitive values to them.

Memory contents

eBPF profilers unwind call stacks inside the kernel. Only the addresses of the stack's frames pass from the kernel to the agent, not the contents of the stack. For interpreted and JIT-compiled runtimes, the profiler reads only the runtime structures that identify functions and files. It also reads the profiling labels your application sets.

The agent does not copy arbitrary stack or heap memory of your processes into profiles. Values held in memory, such as private keys, do not leak into profiling data through stack unwinding.

Debuginfo uploads

To symbolize compiled code, the operator-managed agent uploads debuginfo to the Dash0 exports in the operator configuration. By default, it uploads only the information needed for symbolization and removes the executable code of the binary.

Dash0 has no source code view and does not need your source code. To stop uploads, set uploadEnabled: false under spec.profiling.ebpfProfiler.debuginfo on the Dash0OperatorConfiguration. Profiles of compiled code then appear unsymbolized unless you upload debuginfo from CI.

Further Reading