Splunk telemetry routing with Bindplane shows the access-control gap

At a glance

What this is: This is a configuration guide for routing Splunk telemetry through a Bindplane collector to Splunk and Google Cloud Logging, with the key finding that the same data can be duplicated across destinations without replacing the Splunk estate.

Why it matters: It matters because telemetry pipelines carry access, token, and endpoint risk, so IAM and security teams need to understand where data can be forwarded, duplicated, and exposed across the logging path.

By the numbers:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems.

👉 Read Bindplane's full Splunk and Google Cloud Logging routing walkthrough

Context

Telemetry routing is an access problem as much as an observability problem. When a collector can receive, transform, and forward logs to multiple destinations, the security issue shifts from simple ingestion to control over credentials, endpoints, and data duplication. In identity-heavy environments, those forwarding paths often depend on service accounts, tokens, or certificates that must be governed like any other non-human identity.

This article describes a common logging architecture rather than a novel product capability: a Splunk Universal Forwarder sends data to a Bindplane collector, which can then send the same stream to Splunk and Google Cloud Logging. That pattern is operationally useful, but it also broadens the blast radius if tokens, ports, or collector access are not tightly scoped and monitored.

For teams running Splunk-heavy estates, the real question is whether telemetry transport is treated as a governed pipeline or an ad hoc relay. The starting position in this article is typical for hybrid infrastructure, where routing convenience often appears before identity and access controls are fully formalised.

Key questions

Q: How should security teams govern telemetry pipelines in a multi-tool SOC?

A: Security teams should treat the pipeline as a policy layer, not a transport utility. Define who owns schema normalization, enrichment, routing, and retention decisions, then make those rules independent from SIEM or MDR contracts. That preserves tool choice, reduces migration friction, and keeps the enterprise in control of how telemetry is transformed before analysts and AI systems consume it.

Q: Why do non-human secrets in logging pipelines increase security risk?

A: Because tokens, listener credentials, and service endpoints often outlive the configuration that created them. If they are reused across destinations or left broad in scope, a collector becomes a high-trust relay that can move data into places the original sender never intended. That is a governance issue, not just an integration detail.

Q: What breaks when telemetry forwarding paths are not tightly scoped?

A: Unscoped forwarding breaks accountability, because no one can prove which source sent which data to which destination. It also weakens containment when a token is exposed, since the same credential may provide access to multiple log sinks or indexes. Scope, audit, and revocation must all match the path design.

Q: How do teams decide whether to use a shared collector or separate logging paths?

A: Use a shared collector only when you can preserve clear ownership, strict destination scoping, and independent audit trails for each sink. If those controls cannot be separated cleanly, split the paths. The deciding factor is not convenience but whether the architecture keeps identity and access boundaries visible.

Technical breakdown

How Splunk forwarders hand off telemetry to a collector

Splunk Universal Forwarders normally send cooked data over Splunk-to-Splunk, but this pattern requires raw data delivery instead. Setting sendCookedData to false changes the payload from Splunk-processed events to raw log lines that a collector can receive on a TCP listener. That shift matters because the collector becomes the normalization and redistribution point, not just a pass-through. The architecture is useful when one upstream source must feed multiple downstream destinations, but it also centralizes trust in the collector endpoint and its listening port.

Practical implication: treat the collector listener as a controlled ingestion boundary and restrict who can reach the TCP endpoint.

Why the Heavy Forwarder and HEC token matter

The Heavy Forwarder in this pattern provides an HTTP Event Collector endpoint for data returning into Splunk. That means the Bindplane configuration depends on a token, an enabled global HEC setting, and a reachable HTTP port. From a security perspective, the token behaves like a non-human secret, while the HEC endpoint becomes a network-exposed service that must be authenticated and monitored. If either is overexposed, the collector can become a convenient relay for unintended ingestion rather than a bounded integration point.

Practical implication: inventory HEC tokens as secrets and bind them to the narrowest possible index and host scope.

Why multi-destination telemetry increases governance complexity

Bindplane can forward the same telemetry stream to Splunk and Google Cloud Logging at the same time. That is an example of controlled duplication, but it complicates retention, access review, and data classification because the same event now exists in multiple administrative domains. The important governance issue is not whether duplication is allowed, but whether each destination has its own authentication, authorization, and audit trail. In practice, every added sink increases the number of places where logs can be exposed, misrouted, or retained beyond policy.

Practical implication: require separate access review and retention controls for each telemetry destination.

NHI Mgmt Group analysis

Telemetry pipelines are now identity systems by another name. Once a collector can accept logs from one source and deliver them to multiple destinations, it becomes a control plane for data access, not just an observability component. That means the same governance questions used for workload identity apply here: who can authenticate, what can they send, where can they forward, and how is misuse detected. Practitioners should stop treating log transport as neutral infrastructure and manage it as a privileged integration path.

Non-human secrets are the hidden dependency in routing architectures. The HEC token, listener port, and forwarding configuration all rely on machine credentials or machine-reachable services that can be abused if they are not tightly scoped. This is where NHI governance intersects directly with telemetry architecture: the collector may be simple, but the trust chain is not. Security teams should map every forwarding hop to an owned identity and a revocation path.

Multi-destination delivery creates identity sprawl in the logging stack. The more places telemetry can land, the more authorization domains must be governed, reviewed, and monitored. That increases the chance that access reviews become stale, tokens remain valid after architecture changes, or duplicated data escapes intended retention boundaries. Practitioners need to treat each sink as a separate control surface, not as a copy of the same risk.

Configuration convenience should not outrank auditability. The article shows how easy it is to preserve existing Splunk workflows while adding a second destination, but convenience can obscure where data is actually controlled. In security terms, this is a governance problem of distributed trust, not a tooling problem. Teams should insist that every forwarding decision leaves an audit trail that can be tied back to an accountable owner and a review cycle.

Signed-off-by logging is the next governance gap. As telemetry becomes programmable and multi-home, the field needs clearer ownership of who approved each sink, token, and route. The operational lesson is straightforward: if no one owns the path, no one owns the risk.

What this signals

Telemetry routing is becoming part of the identity estate. As organizations add collectors, forwarders, tokens, and cloud log sinks, they also add machine trust relationships that need lifecycle management, access review, and revocation. The governance pattern here is telemetry identity sprawl: each new sink creates a new administrative boundary that can fail independently.

For practitioners, the next step is to align logging architecture with control ownership. If a collector can forward data to multiple destinations, then the collector, its tokens, and its destination permissions should appear in the same governance register that tracks service accounts and workload identities. That is especially relevant when the environment already depends on NIST SP 800-53 Rev 5 Security and Privacy Controls for access control and audit.

The practical signal is simple: if a team cannot state who owns each telemetry path, it probably cannot state who can revoke it. That is where logging design, NHI governance, and operational resilience meet.

For practitioners

• Map every telemetry hop to an owning identity Assign an accountable owner to the Universal Forwarder, collector listener, HEC token, and each destination so every hop has a reviewable trust boundary.
• Classify HEC tokens as high-value machine secrets Store, rotate, and scope HTTP Event Collector tokens like privileged non-human credentials, with explicit index binding and revocation procedures.
• Restrict collector exposure to approved source networks Limit the TCP listener on port 8779, or the equivalent port in your environment, to known forwarder sources and monitor for unexpected connection attempts.
• Separate access reviews for each telemetry destination Review Splunk and cloud logging permissions independently so duplicated telemetry does not inherit unchecked access across administrative domains.

Key takeaways

• Telemetry forwarding is not just an observability design choice, because each hop introduces machine credentials, endpoints, and audit boundaries that must be governed.
• The article’s architecture shows how easily the same log stream can be duplicated across destinations, which expands the number of places access can be mis-scoped or left behind.
• Security teams should manage collectors, tokens, and sinks as part of the non-human identity estate, with separate ownership and revocation paths for each destination.

Key terms

• Telemetry pipeline: A telemetry pipeline is the path security data follows from collection to analysis and retention. In mature environments it must preserve context, maintain throughput, and avoid introducing blind spots as sources, formats, and volumes change over time.
• HTTP Event Collector: HTTP Event Collector is a Splunk ingestion mechanism that receives structured events over HTTP using a service token. In practice, it is the bridge that lets another system stream security and audit data into the SOC’s main analytical environment without building a custom pipeline.
• Non-Human Secret: A non-human secret is a credential used by software, services, or infrastructure instead of a person. Examples include tokens, API keys, certificates, and service credentials. These secrets require lifecycle controls because they often provide persistent, high-trust access to systems and data.
• Telemetry Identity Sprawl: Telemetry identity sprawl is the accumulation of collectors, forwarders, tokens, and destination permissions across logging paths. It becomes a governance problem when each added route creates another machine trust relationship that must be reviewed, revoked, and monitored independently.

What's in the full article

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

• Exact Splunk forwarder and HEC configuration values for reproducing the pipeline in a lab
• Step-by-step collector rollout settings for binding raw TCP input to Splunk destinations
• The dual-destination setup for sending the same stream to Splunk and Google Cloud Logging
• Part 2 references for extending the pipeline with additional sources and destinations

👉 Bindplane's full post shows the configuration sequence, endpoint settings, and data-flow validation steps.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader infrastructure and security systems their programmes depend on.