Skip to main content
This page is written to be forwarded to a security reviewer without editing. It states what the agent can see, what it sends, what privilege it holds and why, and what it never does. The agent is upstream OpenTelemetry eBPF Instrumentation, unmodified, Apache-2.0.
Availability. The zero-code agent is an early-access distribution. It is installable, upgradable and tested, and it is not yet an integrated part of the product: there is no dashboard page for it, no in-product installer and no self-service download. Ask your account contact for access.Its telemetry, once flowing, is ordinary OTLP and needs nothing special — it appears in Services, Traces and Metrics exactly like SDK telemetry does. That is the design rather than a shortcut.

​
Summary for a reviewer

​
Privilege

The agent holds a named capability profile rather than root. Full detail, including what each capability is for, is on Capability profiles.
CAP_SYS_ADMIN is near-equivalent to root, and is in no profile. It is refused outright for A and B, and on C requires an explicit opt-in flag. A flag that appeared to be accepted and quietly did nothing is how an operator comes to believe they granted less than they did, so refusal is loud.There is one trap worth naming. Upstream documents that on AKS and EKS, the straightforward path requires CAP_SYS_ADMIN unless the node sets kernel.perf_event_paranoid=1. That means the easy path on the two largest managed Kubernetes platforms grants near-root on every node.Set the sysctl instead. Preflight reports which situation you are in.

​
What the agent can see

It hooks TLS library functions, so at that boundary it observes plaintext: HTTP headers including Authorization, cookies, request and response bodies, and SQL statement text. This is the sharpest question in any review and it deserves a direct answer: the agent’s position lets it see credentials in flight. What follows is what stops that becoming data anyone holds.

​
What the agent sends

Metadata only.
Payload capture is off and there is no supported way to enable it here. That is a property of this distribution’s configuration, not of the upstream agent — which is exactly why the distribution exists. A reviewer should verify it rather than take it on faith: the generated configuration is a plain file, and the audit tool reports the running agent’s effective settings.

​
Where the credential lives

The license key is a bearer credential for your ingest surface, and is handled as one:
  • Never written into any generated configuration file, systemd unit, Compose file or Helm values file. This is asserted by tests, not by policy.
  • On Kubernetes it is a Secret, injected as an environment variable. It is never in the ConfigMap — so inspecting the ConfigMap remains a safe debugging step, which is also asserted by a test.
  • On Linux it is in a root-owned environment file with mode 0600.
  • Redacted in every diagnostic the tooling prints, including support bundles.
  • You can supply your own pre-existing Kubernetes Secret, in which case the chart never sees the value at all.
This is partly inherited from upstream: OBI reads OTLP headers only from the environment, and its configuration structure explicitly cannot carry them. There is no config path that could leak the credential even by mistake.

​
Scope the key

A DaemonSet places the credential on every node. That is a materially broader exposure than one application’s configuration, and it deserves its own key.Issue a license key restricted to traces and metrics, and revoke it independently of your primary ingest key. The receiver enforces the allowed signals per key, so a leaked agent key cannot be used to write logs or to read anything. See Create a license key.

​
Kubernetes posture

The rendered DaemonSet:
  • privileged: false
  • capabilities: drop: [ALL], then adds exactly the profile’s set
  • readOnlyRootFilesystem: true
  • hostPID: true — required. Without it the agent shares no PID namespace with the workloads it observes, sees only itself, and silently reports nothing.
  • hostNetwork — only on profile C
  • RBAC: list and watch on pods, services, nodes and replicasets. Read-only, cluster-scoped, used solely to decorate telemetry.
Everything above is inspectable before you install anything — see Inspect before you install. OpenShift. A minimal SecurityContextConstraints ships with the chart. It grants host PID access and the capability set, sets allowPrivilegedContainer: false, and is bound to that release’s ServiceAccount by name rather than to a group. The alternative — which is what happens without it — is attaching the workload to the cluster’s privileged SCC. See OpenShift.

​
Network

  • Exactly one outbound destination: your configured OTLP endpoint, over TLS.
  • No inbound listeners are opened by this distribution’s configuration.
  • Egress-restricted networks need that one host allowed, plus one-time access to the upstream release host at install time.

​
What has not been reviewed

No external security review has been performed. The agent holds kernel capabilities on every node it runs on. This distribution ships least-privilege defaults, an automated audit tool and this document — and nobody outside the engineering team that built it has reviewed the result.If your process requires third-party assurance before granting kernel capabilities in production, that requirement is not yet met. Raise it with your account contact rather than inferring an answer from this page’s thoroughness.
Two further limits worth stating to a reviewer:
  • TLS library coverage is unmeasured. The agent hooks OpenSSL. Statically linked TLS, BoringSSL, rustls, GnuTLS and NSS are each a potential gap. The consequence is not exposure but absence — those services are simply not observed. See Known limitations.
  • Scale validation is single-node. Behaviour has been exercised on a real cluster, but not across a large fleet or under a soak test.

​
Verifying it yourself

A reviewer should not have to take this page’s word for any of it:

Before installing

The preflight tool reads the host. It installs nothing, sends nothing and loads no eBPF program — it reports kernel, BTF, architecture, capabilities and the perf-event setting.

After installing

The audit tool reports the privilege the agent is actually running at, so “we intended profile B” can be checked rather than assumed.
On Kubernetes, render the chart and read the security context before applying anything. Nothing about the deployment is opaque.

​
Next

Capability profiles

The three levels and how to choose.

Known limitations

Everything the agent does not do, stated plainly.

Compatibility

Where it is validated, expected, limited and unsupported.