Skip to main content
OpenShift is Kubernetes plus an admission layer that will refuse the agent’s DaemonSet unless something grants it the privilege it needs. The chart ships that something.
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.
Read Install on Kubernetes first. Everything there applies. This page covers only what OpenShift adds.

Install

openshift.enabled=true creates a minimal SecurityContextConstraints and binds it to this release’s ServiceAccount.

What the constraints grant

Bound to a ServiceAccount, not to a group. A constraints object attached to a group applies to every workload that lands in it, now and in future. Binding by ServiceAccount name means this grant covers this agent and nothing else — including nothing you deploy next year.

Why not just use the privileged SCC

Without the shipped constraints, OpenShift denies the DaemonSet. The usual workaround is to attach the workload to the cluster’s built-in privileged SCC, and it does make the error go away.
privileged grants far more than the agent needs, and permanently. It allows privileged containers, host namespaces, arbitrary volume types and any capability — a superset of the six the agent asks for, with no relationship to what it actually uses.The shipped constraints exist precisely so that “make it start” and “grant it root-equivalent access on every node” stop being the same action. If your cluster administrator is going to review one thing, this is it.

Review it before applying

Render everything the chart would create and read the constraints object directly:
Nothing about the deployment is opaque, and a cluster administrator should not have to take a documentation page’s word for the grant. See Security model.

Profiles on OpenShift

The same constraint as ordinary Kubernetes applies: profile A is not available, because it cannot be expressed through the upstream chart. Use B, which is the default and is designed to be sufficient on its own. Profile C additionally needs host networking, which is a materially larger ask on OpenShift than elsewhere — raise it with your cluster administrator before planning around it. See Capability profiles.

Node prerequisites

The kernel.perf_event_paranoid requirement applies to OpenShift nodes as it does everywhere. On a cluster where you do not manage node sysctls directly, this is a machine-config change and is worth arranging before the install rather than after — the failure it produces is silent, so it costs an afternoon to diagnose from the symptom. See How eBPF works.

Next

Security model

The document to forward to whoever approves this.

Verification

Confirm data is arriving.

Troubleshooting

Symptom to cause to fix.