Tuesday's Tip: Securing the Bindplane Pipeline into Google SecOps

Tuesday 11/10/2026

Audience: SecOps engineers and platform owners who use Bindplane to collect logs for Google SecOps.

Summary: The Bindplane server decides what every managed collector reads, where it sends data, and which binary it runs. Whoever controls the server controls every host with a managed collector. This tip covers how that trust works, what an attacker could do with it, and the controls that reduce the risk.

The legacy SecOps forwarder reaches end of life on January 1, 2027, and Google blocks ingestion from it on April 1, 2027. Most teams will depend on Bindplane by then, so harden it first.

1. How Bindplane manages collectors

• Bindplane server: the web app and API that store pipeline configurations and manage collectors. You can host it yourself or use Bindplane Cloud. The UI, API and collector connections all use port 3001 by default.
• Collector (BDOT): the Bindplane Distro for OpenTelemetry Collector. It runs on each host, reads logs, and sends them on. On Linux it runs as root by default.
• OpAMP: the protocol the collector uses to connect out to the server over a websocket. The server never opens connections to collectors. It sends configurations and upgrade instructions back over the collector’s connection.
• Secret key: a shared value that every collector presents when it connects.
• Rollout: pushing a new configuration version to a group of collectors.
• Gateway: a collector that receives data from other collectors and forwards it to SecOps.

The collector applies whatever configuration or upgrade the server sends. Bindplane has no built-in approval step for rollouts.

2. What someone with control of the server can do

3. How upgrades are checked

Based on the collector source code as of November 10, 2026 (v1.112.0):

1. When someone starts an upgrade, the server sends the collector a download URL and a SHA-256 hash.
2. The collector downloads the file from that URL and compares it to the hash.
3. The updater installs the package, restarts the collector, and rolls back if the collector does not report healthy. It runs as root on Linux and macOS and as administrator on Windows.

The URL and the hash both come from the server. The hash proves the download was not corrupted. It does not prove the package came from Bindplane.

Signatures exist, but the remote upgrade path does not use them:

• Every release file has a cosign signature (.sig) that you can check by hand.
• The install script checks the package’s GPG signature by default. If the gpg tools are missing, it warns and installs anyway unless you pass --require-gpg-check.

Offline mode adds another path. It is available in Bindplane Enterprise and Bindplane for Google:

• The server hosts upgrade packages in /var/lib/bindplane/agent-upgrades.
• Packages are uploaded with bindplane upload agent-upgrade using normal UI credentials.
• The documentation does not describe any verification of uploaded packages.

Dynatrace completed its acquisition of Bindplane in April 2026, and the collector’s management code now lives in a Dynatrace repository. Watch the release notes for changes to this behavior.

4. Hardening controls

5. Use cases

A. Keep upgrades in your own verified channel (Linux)

1. Before the first install, create the pre-install file: /etc/default/observiq-otel-collector on Debian and Ubuntu, or /etc/sysconfig/observiq-otel-collector on RHEL. It must be owned by root with mode 0644.
2. Put BDOT_UNPRIVILEGED=true in that file (v1.82 or later). The collector then runs as the bdot user.
3. Give bdot read access only to the logs you collect. On Debian and Ubuntu, for example, add it to the adm group for /var/log.
4. In a lab, confirm that an upgrade started from the Bindplane UI does not go through for that collector.
5. For each new release, upgrade with the install script and --require-gpg-check. As an alternative, verify the package with cosign verify-blob and deploy it through your patching tool.
6. For hosts that still run as root, add file integrity monitoring on /opt/observiq-otel-collector. Alert when the binary changes outside a patch window.

B. Catch a pipeline change that hides activity

1. Confirm the Audit Trail is on (gear icon, then Audit Logs). It is not available in the Free edition and keeps 30 days of events by default.
2. Create a Bindplane API key for reading audit events.
3. Create a dedicated configuration with the Bindplane Audit Logs source and your SecOps destination. Attach a collector to it, because the server does not send these logs itself. Each source covers one project.
4. In SecOps, alert on collector upgrade requests, new or changed destinations, API key creation, and rollouts outside your change window.
5. Someone who controls the server could turn this pipeline off. Add a Cloud Monitoring absence alert on ingested log count for the audit log type.
6. Add silent host alerts for your critical sources. A filter that drops one host’s events then still raises an alert.

C. Block data theft through a pushed configuration

1. List what each collector must reach: the Bindplane server (port 3001 by default) and your gateway collectors.
2. Gateways also need the SecOps ingestion endpoint and nothing else. For HTTPS ingestion, Google says to allow *.chronicle.googleapis.com on port 443.
3. On Linux collectors running as bdot, add an owner-match firewall rule (iptables -m owner --uid-owner bdot) that allows only those destinations for that user.
4. On Windows, use Windows Firewall outbound rules scoped to the collector program.
5. In a lab, add a destination that points to an outside endpoint and confirm the connection is blocked.
6. Alert on blocked outbound attempts from the collector. They point to a configuration sending data somewhere unexpected.

6. Example detection

A collector reads files and sends network traffic. It has no reason to start a shell, a script interpreter or a download tool. If it does, someone may have pushed a malicious configuration or package.

The rule needs EDR process telemetry parsed to UDM PROCESS_LAUNCH events, for example from CrowdStrike, Defender for Endpoint or Sysmon. The updater is a separate binary, so normal upgrades do not match.

rule bindplane_collector_spawns_shell_or_downloader {
  meta:
    author = "Tuesday Tip of the Week"
    description = "Bindplane collector process starts a shell, script interpreter, or download tool"
    severity = "High"
    priority = "High"
    technique = "T1059"

  events:
    $e.metadata.event_type = "PROCESS_LAUNCH"
    re.regex($e.principal.process.file.full_path, `(?i)(observiq-otel-collector|bindplane-otel-collector)(\.exe)?$`)
    re.regex($e.target.process.file.full_path, `(?i)(/(ba|da|z)?sh|/python[0-9.]*|/pwsh|/curl|/wget|\\(cmd|powershell|pwsh|curl)\.exe)$`)

  outcome:
    $risk_score = 80
    $hostname = $e.principal.hostname
    $parent_path = $e.principal.process.file.full_path
    $child_path = $e.target.process.file.full_path
    $child_command_line = $e.target.process.command_line

  condition:
    $e
}

7. Action checklist

• List every collector. Note which run as root and which use skip-verify or ws://.
• Move the Bindplane server into a management subnet with SSO, MFA and a short admin list.
• Turn on TLS verification and client certificates for OpAMP.
• Switch Linux collectors to unprivileged mode, and move upgrades to your own verified channel.
• Restrict collector egress, and keep SecOps credentials on gateways only.
• Replace Chronicle Editor on the ingestion service account with a custom ingest-only role.
• Send the Bindplane Audit Trail to SecOps. Alert on upgrade requests, changes outside the change window, and a quiet feed.
• Deploy the collector process rule and file integrity monitoring on collector install directories.
• Decide which Tier 0 hosts should run unmanaged collectors.