Custom OpenTelemetry collectors need tighter build and runtime governance

At a glance

What this is: This is a tutorial on building and packaging a custom OpenTelemetry Collector distribution with Bindplane’s OpenTelemetry Distribution Builder, manifest.yaml, and GitHub Actions, with the key finding that slimmer collectors reduce unnecessary surface area but increase the importance of build governance.

Why it matters: It matters because observability agents, collectors, and their pipelines can become privileged operational components, so IAM, PAM, and platform teams need clear control over what is built, what runs, and what can be remotely reconfigured.

👉 Read Bindplane's tutorial on building a custom OpenTelemetry collector with GitHub Actions

Context

A custom OpenTelemetry collector is a scoped telemetry pipeline built from only the components a team actually needs. That approach can reduce attack surface, but it also creates a governance problem: the manifest, build pipeline, and runtime management layer become part of the security boundary, especially when collectors are deployed across Kubernetes, edge, and container estates.

For identity and access practitioners, the relevant question is who can change collector composition, who can approve the build, and how remote configuration is constrained once the agent is running. That intersects with workload identity, secrets handling, and operational privilege, because telemetry infrastructure often sits close to production data and control planes.

Key questions

Q: How should teams govern custom OpenTelemetry collector builds in production?

A: Treat the manifest, build workflow, and release artifact as one control chain. Review component changes through code governance, separate build and runtime privileges, and verify that deployed capabilities match the approved manifest. This prevents collector sprawl from becoming an unmanaged control plane and keeps observability agents inside a clearly defined security boundary.

Q: Why do custom collectors change the risk profile of observability pipelines?

A: Because the collector is no longer a generic distribution with known behaviour. It becomes a tailored workload whose security depends on the exact modules included, the integrity of the CI/CD process, and the permissions behind remote configuration. That increases the need for provenance, least privilege, and change accountability.

Q: What do security teams get wrong about trimming collector components?

A: They often focus on performance and binary size while underestimating governance impact. Removing unused modules helps reduce attack surface, but it also creates a new dependency on disciplined manifest management. If the build pipeline is weak, a smaller collector can still be a poorly governed one.

Q: How do teams keep remote collector management from becoming overpowered?

A: Limit OpAMP or similar management access to tightly scoped administrative roles, and map those roles to approved change processes. Remote management should let operators configure what has already been authorised, not expand collector capability after deployment. That keeps runtime control aligned with the build-time policy boundary.

Technical breakdown

Why component minimisation changes collector risk

The OpenTelemetry Collector Contrib distribution is broad by design, which is useful for experimentation but unnecessary for many production deployments. A custom distribution narrows the binary to the receivers, processors, exporters, and extensions a team chooses, which reduces dependency volume and can shrink the operational blast radius. The trade-off is that security posture now depends on what the manifest includes, how builds are reproducible, and whether unsupported components are truly excluded rather than merely hidden.

Practical implication: treat manifest composition as a controlled build artifact, not a convenience file.

How manifest-driven builds turn governance into code

In this model, manifest.yaml becomes the source of truth for collector capabilities. GitHub Actions then compiles that declaration into platform-specific binaries and packages, which means build integrity depends on repository controls, workflow permissions, and review discipline. This is a classic shift from implicit trust in a standard distribution to explicit trust in a governed pipeline. For security teams, the key issue is whether the repository, workflow, and release process are protected well enough to prevent unauthorised component drift.

Practical implication: protect the manifest and workflow with code review, branch controls, and release approval gates.

What OpAMP adds to the runtime control plane

OpAMP lets the collector be discovered, configured, and monitored remotely, which is useful for fleet management but also turns the runtime control path into a privileged channel. If configuration changes can be pushed centrally, then authentication, authorisation, and component compatibility become part of the security model. The tutorial’s emphasis on UI-aware capabilities shows why runtime governance matters: only approved modules should be exposable, and remote control should not become an unchecked path to broaden collector function after deployment.

Practical implication: restrict remote configuration rights and bind them to approved collector capabilities.

NHI Mgmt Group analysis

Collector minimisation is a governance pattern, not just a build optimisation. The article is right to frame smaller collector binaries as a production requirement, but the deeper security value is control reduction. Fewer components mean fewer dependencies, fewer hidden behaviours, and a narrower review surface. For identity and platform teams, that shifts attention toward least function, not just least privilege. The practitioner conclusion is that every added receiver, exporter, or extension should carry an explicit governance justification.

Manifest-driven telemetry pipelines create a new control point for supply-chain risk. Once collector capabilities are declared in code and compiled through CI/CD, the manifest becomes a security-critical configuration object. That makes workflow permissions, artifact signing, and release integrity central to control assurance. In NHI terms, the collector itself behaves like a workload identity with capabilities defined by policy and build inputs. The practitioner conclusion is to treat build provenance as part of runtime trust.

Build provenance debt: When the same repository defines capabilities, packages artifacts, and publishes releases, teams accumulate a hidden trust dependency on the pipeline. That debt is easy to miss because the collector appears operationally simple once deployed. In reality, the build chain is now the policy layer. NHI Mgmt Group sees this pattern repeatedly in agentic and workload environments: if you cannot prove what was built, you cannot fully trust what is running. The practitioner conclusion is to put provenance, approvals, and artifact integrity under the same governance regime.

OpAMP widens the management plane, which increases the importance of scoped delegation. Remote collector control is useful only if the organisation can prove which operators may change which capabilities and under what conditions. That is an identity problem as much as an observability problem, because the management plane needs strong operator authentication, role separation, and audited configuration change paths. The practitioner conclusion is to align collector administration with PAM-style controls and explicit change ownership.

What this signals

Custom collectors fit the broader shift toward narrower, purpose-built operational agents, but they also expose a recurring governance gap: teams often secure the workload and forget the build chain that defined it. The practical signal is that collector control belongs in the same governance conversation as workload identity, artifact integrity, and configuration change management.

Build provenance debt: the more capability is encoded in a manifest and released through automation, the more the organisation must prove that the running collector still matches the approved intent. That is especially relevant where telemetry paths touch sensitive logs, credentials, or production metadata. Practitioners should expect build integrity to become a routine audit question, not a niche engineering concern.

For practitioners

• Lock down the collector manifest as a controlled asset Require review and approval for every change to manifest.yaml, including receiver, exporter, processor, and extension additions or removals. Store it in a protected branch and tie release generation to approved commits only.
• Separate build permissions from runtime administration Ensure the identity that can trigger GitHub Actions builds cannot also push remote configuration changes through OpAMP or the management UI. Use distinct roles for engineering, release management, and operations.
• Restrict remote configuration to approved capabilities Expose only the collector functions included in the build, and verify that unsupported components remain unavailable in the UI and API. Reconcile declared capabilities against deployed artifacts after every release.
• Apply provenance checks to collector releases Sign artifacts, verify checksums before deployment, and preserve build metadata so operators can trace each package back to the commit and workflow that produced it.

Key takeaways

• Custom OpenTelemetry collectors reduce surface area, but they also turn manifest governance and build provenance into security controls.
• The main risk is not the collector itself, but the trust chain spanning GitHub Actions, release artefacts, and remote runtime administration.
• Teams should separate build and operator privileges, restrict runtime capability drift, and verify that deployed collectors match approved manifests.

Key terms

• OpenTelemetry Collector: A configurable service that receives telemetry, processes it, and exports it to one or more back ends. It acts as the central routing layer for metrics, logs, and traces in a vendor-neutral observability pipeline.
• OpAMP: The Open Agent Management Protocol is a remote management layer for observability agents and collectors. It enables discovery, configuration, and monitoring from a central control plane, which makes authentication, authorization, and capability scoping critical security requirements.
• Manifest.yaml: A declarative file that defines which modules go into a custom collector build. In security terms, it functions like a policy document for collector capability, because the contents determine what the runtime can do and what it cannot do after deployment.
• Build provenance: Build provenance is the evidence chain showing where a software artefact came from, how it was assembled, and which identities and keys were used. It is essential when teams need to prove that an embedded release was produced from trusted source and controlled inputs.

What's in the full article

Bindplane's full tutorial covers the operational detail this post intentionally leaves for the source:

• Step-by-step manifest.yaml examples for building a custom OpenTelemetry Collector distribution
• GitHub Actions workflow details for producing multi-platform packages and release artifacts
• Installation and service management output for running the collector as a systemd service
• Bindplane UI configuration steps showing how supported collector capabilities are discovered and applied

👉 Bindplane's full post shows the manifest, workflow, and runtime management steps in detail

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It helps practitioners connect workload and agent governance to the access model their broader security programme depends on.