Google SecOps Pipelines

Natively configure telemetry processing on your Google SecOps data

Overview

Bindplane's SecOps Pipelines let you create, configure, and manage Data Processing Pipelines directly in Bindplane. These pipelines apply custom OpenTelemetry processors to your log data after it reaches Google SecOps but before parsing and ingestion. You can easily transform, enrich, filter, and redact your SecOps data through Bindplane's interface, all without the need to write raw OTel configurations or manage agent deployments.

Key Benefits

• No agent management: Pipelines automatically run on your Google SecOps data

• Simplified configuration: Use Bindplane's visual interface instead of editing raw OTel configurations and OTTL statements

• Native integration: Access your pipelines directly from your Google SecOps instance via "Open in Bindplane" links

• Pre-ingestion processing: Transform data before it's fully ingested into SecOps

Important Limitations

SecOps Pipelines have some constraints compared to traditional Bindplane configurations:

• Single destination only: All data is exclusively sent to SecOps

• 10 processor limit: Maximum of 10 processors per pipeline

• Limited processor types: Only the Bindplane processors built on OpenTelemetry's transform, filter, and redaction processors are supported at this time

  • See the list of supported processors here

  • See the list of all Bindplane processors here

• No connector support: Connectors are not supported in SecOps Pipelines at this time

When to Use SecOps Pipelines vs. a Bindplane Configuration

SecOps Pipelines are a streamlined subset of Bindplane's full capabilities, scoped specifically for in-flight processing on data already flowing into Google SecOps. A full Bindplane configuration extends beyond that, enabling collection from any source, delivery to any destination, and access to the complete set of processors, routing logic, and more.

Use SecOps Pipelines when:

• You want to configure processing on data being sent to Google SecOps

• Your processing requirements do not require complex processors or connectors (transformations, filtering, redaction)

• You want to avoid managing agents and infrastructure

Use Bindplane configurations when:

• You need to send data to multiple destinations (e.g., Google SecOps + Cloud Storage + ClickHouse)

• You require advanced processors like resource detection, batching, or sampling

• You need complex routing logic with multiple processor nodes

• You need more than 10 processors in your pipeline

Connecting the Google SecOps Integration

It is highly recommended to setup the Google SecOps Pipelines for a given tenant with only 1 Bindplane Project

Prerequisites

• An Google SecOps instance with the "Data Processing Pipeline Preview" enabled

  • Contact your Google SecOps Account Manager for more information and to get enabled for this preview

• A supported Bindplane Plan

  • Bindplane Enterprise

  • Bindplane (Google Edition)

  • Bindplane Enterprise (Google Edition)

Setup

1. Navigate to your Bindplane Project Settings page

2. Scroll down to the Integrations section and click Connect

3. Provide details about your SecOps instance:

   • Customer ID

   • GCP Project Number

4. Configure an Authentication Method

   1. Service Account JSON The Service Account JSON authentication method requires providing the JSON key to a service account residing in the same GCP Project as your Google SecOps Instance. The service account must have permissions according to Google's Documentation.

   2. Workload Identity Federation (WIF) WIF authentication allows you to authenticate the Google SecOps Integration without providing raw credentials. This authentication method is only supported in Bindplane Cloud. The following documentation provides instructions on how to set up WIF auth. How to Connect the Google SecOps Integration with WIF Auth

5. Once connected, the SecOps Pipelines tab will appear in Bindplane

Working with SecOps Pipelines

Creating a Pipeline

Create a new SecOps Pipeline by going to the SecOps Pipelines page, clicking the Create SecOps Pipeline button, and filling out your desired name and description.

Managing Sources

SecOps Pipelines work with data sources (log types, ingestion methods, feeds) in your SecOps instance. Each data source is referred to as a "Stream" and can be configured by clicking the Add Stream button and following the dialog accordingly.

Clicking the node of an existing stream in your pipeline will allow you to edit or delete the stream as you see fit.

In order to save the changes you've made to your pipeline. Click the Start Rollout button.

Configuring Processors

Not all Bindplane processors are supported in SecOps Pipelines. Read more

Configure processors as you normally would in Bindplane by clicking the processor node in the center of your pipeline.

In order to save the changes you've made to your pipeline. Click the Start Rollout button.

Managing Multiple Log Types

If you need different processing for different log types, you must create a separate SecOps Pipeline. Each pipeline can only have one processor configuration that applies to all sources within that pipeline.

Accessing from Google SecOps

From your Google SecOps instance, you can access your pipelines directly:

1. Navigate to Settings -> Data Processing

2. Click a Data Pipeline

3. Click Open in Bindplane to open the associated SecOps Pipeline in Bindplane

Common Pitfalls

SecOps Pipelines behave differently from standard Bindplane configurations under the hood. Even if the interface feels familiar, there are a few differences that can be confusing at first.

Logs Ingested through the Backstory API (gRPC) are not processed by SecOps Pipelines

If you want to process logs being ingested through the Backstory Ingestion API (gRPC) with SecOps Pipelines, you will need to import the logs using the new Chronicle API Ingestion Methods.

Sample Logs May Not Reflect Active Pipeline Data

When viewing a snapshot of a pipeline's logs, only logs that have been ingested from the configured sources after the pipeline was created will be displayed. If no matching logs have been ingested yet, Bindplane will automatically fall back to displaying a sample of logs with the same log types from your existing Google SecOps logs so you can still build and test your processor configuration.

Importantly, logs ingested through the Backstory API (gRPC) may be displayed in this fall back sample, but are not being processed by the pipeline as described above.

Note: When this fallback is active, an info banner will appear at the top of the snapshot experience to let you know. These sample logs are not being actively processed by the pipeline, they are provided solely to help you validate your processor logic before live data begins flowing.

Keep this in mind when testing early: the logs visible in the UI may not be the ones your pipeline is actually acting on yet.

---

Bindplane Displays Google SecOps-Formatted Logs, Not OTel Fields

SecOps Pipelines process data using OpenTelemetry processors behind the scenes. As a result, logs pass through a conversion layer: from SecOps format → OTel format → back to SecOps format after processing.

The Bindplane UI always shows the final Google SecOps-formatted log, which includes:

• Log Entry Time

• Collection Time

• Namespace

• Body (string)

• Labels

  • A map of keys to Label objects

    • Label objects consist of a string value, and a boolean rbacEnabled

OTel-specific fields, such as structured key-value map bodies, attributes, and resource attributes, are not visible in the UI. However, processing that reads or modifies these fields does work correctly. The results just won't be directly visible in the log preview; you'll see the downstream effect once the data has been converted back into SecOps format.

For example, if a user sets the attribute myKey using the Add Fields processor, the attribute will not be visible in the log snapshot. However, any processing logic performed on the myKey attribute (filtering, transformation, redaction) will still happen correctly. Only the Google SecOps formatted resulting logs will be displayed, which do not include Attributes or Resource Attributes.

---

Referencing Google SecOps-Specific Fields Requires Special OTTL Syntax

Google SecOps log fields like namespace and labels don't map directly to standard OTel field paths. To reference these fields when configuring processors, use the following syntax:

Field	OTTL Path
Log Entry Time	attributes["log_entry_time"]
Collection Time	attributes["collection_time"]
Namespace	attributes["environment_namespace"]
Label value	attributes["labels.<labelName>.value"]
Label RBAC enabled	attributes["labels.<labelName>.rbac_enabled"]

For example, to reference a label named myLabel, you would use attributes["labels.myLabel.value"] for its string value or attributes["labels.myLabel.rbac_enabled"] for its boolean RBAC flag.

Additional Resources

• Google SecOps Data Processing Pipeline Documentation