# Google SecOps Pipelines
### Overview Bindplane's SecOps Pipelines let you create, configure, and manage [Data Processing Pipelines](https://docs.cloud.google.com/chronicle/docs/ingestion/data-processing-pipeline) 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. ### Prerequisites The SecOps Pipelines feature requires the [Google SecOps partner integration](/feature-guides/partner-integrations/google-secops.md) to be connected in your Bindplane project ### 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](https://opentelemetry.io/docs/collector/components/processor/)'s [transform](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/transformprocessor#transform-processor), [filter](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/filterprocessor#filter-processor), and [redaction](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/redactionprocessor#redaction-processor) processors are supported at this time * See the list of supported processors [here](https://docs.cloud.google.com/chronicle/docs/ingestion/data-processing-pipeline#configure-processors) * See the list of all Bindplane processors [here](https://docs.bindplane.com/integrations/processors) * **No connector support:** [Connectors](https://docs.bindplane.com/integrations/connectors) are not supported in SecOps Pipelines at this time * **gRPC (Backstory API):** Logs ingested using the gRPC protocol ([Backstory Ingestion API](https://docs.cloud.google.com/chronicle/docs/reference/ingestion-api)) will not be processed by SecOps Pipelines. ### 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 ### 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 {% hint style="info" %} Not all Bindplane processors are supported in SecOps Pipelines. [Read more](https://docs.cloud.google.com/chronicle/docs/ingestion/data-processing-pipeline#configure-processors) {% endhint %} 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 imported using gRPC (**[**Backstory Ingestion API**](https://docs.cloud.google.com/chronicle/docs/reference/ingestion-api)**) will not be processed by SecOps Pipelines** To ingest logs that *will* be processed with SecOps Pipelines, you must switch to importing logs via the [Chronicle API](https://docs.cloud.google.com/chronicle/docs/reference/ingestion-methods) (HTTPS), or other supported methods such as [Feeds](https://docs.cloud.google.com/chronicle/docs/administration/feed-management-overview) or [Workspace](https://docs.cloud.google.com/chronicle/docs/ingestion/default-parsers/workspace-activity) Ingestion. **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:
FieldOTTL Path
Log Entry Timeattributes["log_entry_time"]
Collection Timeattributes["collection_time"]
Namespaceattributes["environment_namespace"]
Label valueattributes["labels.<labelName>.value"]
Label RBAC enabledattributes["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 Integration](/feature-guides/partner-integrations/google-secops.md) * [Google SecOps Data Processing Pipelines Documentation](https://docs.cloud.google.com/chronicle/docs/ingestion/data-processing-pipeline) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.bindplane.com/feature-guides/pipeline-processing/google-secops-pipelines.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.