TL;DR: Custom OpenTelemetry collector builds reduce binary size and unnecessary dependencies, but Bindplane’s tutorial shows they also shift governance into manifest design, GitHub Actions, and runtime management, according to Bindplane. The security issue is not convenience alone, but whether build-time component selection and remote configuration stay aligned with least-privilege operational control.
At a glance
What this is: This is a tutorial on building custom OpenTelemetry collectors, and its key finding is that narrowing the collector footprint also moves security control into build and runtime governance.
Why it matters: It matters because IAM, NHI, and platform teams need to treat collector build pipelines, configuration scope, and runtime management as part of the control surface, not just the telemetry stack.
Context
Custom OpenTelemetry collectors are a governance problem as much as a packaging choice. When teams trim receivers, processors, exporters, and extensions to reduce footprint, they also decide which capabilities exist, which configuration paths stay valid, and which runtime behaviours are allowed. That creates a direct control-plane connection between build definitions and operational access.
This matters because the collector often sits in Kubernetes, container, or edge environments where configuration can change frequently and remotely. In practice, the build manifest becomes a policy artefact, the CI pipeline becomes a release control, and the runtime manager becomes the enforcement layer. The identity angle is real here: collectors are machine components whose permissions, configuration scope, and lifecycle need explicit governance.
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: What breaks when a collector manifest is not tightly controlled?
A: The collector can accumulate hidden capability, drift from the approved build, or expose unsupported configuration paths that were never intended for production. That breaks least-privilege operation because the runtime ends up with more trust than the build record justifies.
Q: Why do remote collector management features increase governance needs?
A: Remote management turns the collector into a continuously controlled endpoint, so the question becomes who can change it, what they can change, and how those changes are audited. Without those controls, remote configuration becomes a privilege boundary that is easy to overextend.
Q: How can teams tell whether build and runtime controls are aligned?
A: The clearest signal is whether the running collector only exposes components and configuration paths that are present in the approved manifest and release artefact. If the live runtime can accept unsupported changes, build-to-runtime congruence has failed.
Technical breakdown
Why custom collector builds reduce attack surface
A custom OpenTelemetry collector is assembled from selected receivers, processors, exporters, and extensions instead of shipping the full upstream distribution. That matters because every excluded component removes code paths, dependencies, and configuration options that would otherwise be present at runtime. The security gain is not just smaller binaries. It is narrower functional scope, which reduces the number of behaviors an operator, attacker, or misconfiguration can activate. The risk shifts from broad package exposure to the correctness of the selection process itself, including what the manifest allows and what the deployment pipeline actually delivers.
Practical implication: treat component selection as a security decision, not just a build preference.
How manifest-driven builds become a control point
The manifest.yaml becomes the authoritative list of what the collector can do. That means the file functions like a policy document for build-time capability, not merely a build recipe. If the manifest includes authentication extensions, cloud observers, or additional exporters, those capabilities become part of the trusted runtime surface. If it omits them, the collector cannot support them later without a rebuild. In governance terms, this is a classic configuration-as-control pattern: what is allowed at build time shapes what is possible at runtime. For identity and machine governance, that makes the manifest part of the asset inventory and privilege boundary.
Practical implication: version, review, and approve the manifest with the same discipline as other privileged configuration files.
Why OpAMP increases the need for runtime governance
OpAMP gives the collector remote management and capability-aware configuration, which is useful but also expands the governance burden. Once a collector can be managed remotely, the security question is no longer only what was compiled in, but what can be pushed to it, when, and by whom. Bindplane’s capability-aware configuration model helps limit incompatible settings, yet that does not replace access control, configuration approval, or change traceability. Remote control channels are especially important for machine identities because they convert a packaged agent into a continuously managed endpoint with an ongoing trust relationship.
Practical implication: enforce approval, audit, and role separation around remote configuration of custom collectors.
NHI Mgmt Group analysis
Collector governance is becoming an identity control problem, not just an observability task. A custom collector is a machine component with compile-time privileges and runtime permissions, so its security model should be closer to software supply chain governance than to simple telemetry setup. The article shows that build selection, deployment automation, and remote management all influence the effective trust boundary. Practitioner conclusion: govern collectors as managed non-human identities with explicit lifecycle and configuration control.
Manifest files are policy artefacts in practice. Once a manifest defines which receivers, exporters, processors, and extensions exist, it also defines which behaviours are impossible without rebuilding. That makes manifest review a control over capability scope, not a developer convenience. For teams running complex Kubernetes or edge estates, this is where build-time least privilege is decided. Practitioner conclusion: require approval and traceability for every manifest change that expands capability.
Remote configuration only works safely when runtime entitlement is constrained by build provenance. Capability-aware tooling is useful because it prevents unsupported components from being configured, but it does not by itself answer who may change the configuration or under what governance. This is the same pattern seen in other machine-management domains: the runtime system is only as trustworthy as the identity and approval process behind it. Practitioner conclusion: tie remote control to strong authorization, change logging, and versioned release governance.
Custom collectors sharpen the need for a named control concept: build-to-runtime congruence. In this pattern, the security property is that the approved build contents and the live runtime configuration must remain aligned. Drift creates hidden capability, while overbroad builds create unnecessary exposure. The article is a reminder that observability stacks can drift into shadow capability if build manifests and runtime rollout are not linked. Practitioner conclusion: continuously reconcile what the collector can do with what it is actually allowed to do.
OWASP-NHI principles apply because the collector behaves like a managed machine identity. It has an installation lifecycle, configuration authority, and remote management path, all of which need ownership and scope control. The closer the collector gets to autonomous telemetry handling, the more important it is to define who can issue, modify, and retire its effective capabilities. Practitioner conclusion: apply machine-identity governance to the collector lifecycle, not just to its credentials.
What this signals
Build-to-runtime congruence: custom collectors are safe only when the approved manifest, packaged artefact, and live runtime configuration remain aligned. If those three drift apart, the collector becomes a quietly expanding control surface rather than a constrained telemetry component.
For identity and platform teams, the important shift is to manage collectors as governed machine identities. That means lifecycle ownership, remote-change authorization, and release traceability belong in the same control conversation as telemetry coverage.
The practical question is not whether custom builds are possible, but whether the organisation can prove that only approved capabilities are running after deployment.
For practitioners
- Define a minimal collector capability set Start with only the receivers, processors, exporters, and extensions the workload actually needs, then block unreviewed additions in the manifest.
- Treat manifest changes as controlled configuration Put manifest.yaml under code review, approval, and version control so every capability expansion is traceable and reversible.
- Lock down remote collector management Restrict who can push OpAMP or equivalent runtime changes, and log every configuration rollout as a privileged change.
- Reconcile build contents with live runtime state Compare the approved build manifest to the active collector configuration so unsupported or drifted components are detected quickly.
Key takeaways
- Custom OpenTelemetry collectors shrink the exposed surface, but they also move security responsibility into build selection and runtime governance.
- The manifest is not just a build file. It is the policy artefact that defines what the collector can and cannot do.
- Remote management only stays safe when runtime changes are tied back to approved build contents and privileged change control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Custom collectors become overprivileged when their manifests include more capabilities than production needs. |
| NHI-08 — Environment Isolation | Manifest-driven collectors should not leak capability across build, test, and production environments. | |
| Recommendation — Limit collector manifests to the smallest viable component set and remove unused capabilities before release. Separate collector builds and runtime policies by environment so capabilities do not cross trust boundaries. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Collector configuration and remote management should only allow the minimum necessary access and capability. |
| Recommendation — Apply least privilege to collector build approval, deployment, and remote configuration rights. | ||
| CIS Controls v8 | CIS-5 — Account Management | Remote collector administration depends on controlled ownership, assignment, and review of privileged accounts. |
| Recommendation — Review and restrict accounts that can modify collector manifests or push runtime changes. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | A poorly governed collector can become a foothold for credential abuse or movement into adjacent systems. |
| Recommendation — Map collector management paths to TA0006 and TA0008 and monitor for misuse of privileged access. | ||
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.
- Manifest-driven Build: A manifest-driven build uses a declarative file to define which modules, extensions, processors, and exporters are compiled into the final artefact. In security terms, the manifest becomes a control document because it determines the collector's effective capability and attack surface.
- OpAMP: Open Agent Management Protocol is a remote management protocol for OpenTelemetry collectors. It lets operators push configuration, monitor health, and manage lifecycle actions over an outbound connection rather than by opening inbound management ports.
- Build-to-runtime correlation: Build-to-runtime correlation links what happened in code, CI/CD, image creation, registry storage, and live execution into one security view. It helps teams decide whether a container finding is theoretical or operationally dangerous by showing the path from commit to deployed workload.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners translate machine and agent control problems into enforceable governance.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org