# Google SecOps Pipelines vs. Bindplane Gateway

Google SecOps Pipelines and Bindplane gateways both give you control over your telemetry data before it lands in storage. They solve different problems, however, and choosing the wrong one can leave you hitting hard limits or paying for infrastructure you don't need.

This guide breaks down the constraints of each approach, explains the trade-offs, and provides guidance for common scenarios including compliance-sensitive environments.

### What SecOps Pipelines Can and Cannot Do

SecOps Pipelines are a Google-managed feature that lets you apply OpenTelemetry processors to data that is already flowing into Google SecOps. No collector infrastructure to manage, but the trade-off is a constrained processing environment.

**Hard limits imposed by Google:**

* **10 processors per pipeline.** This is a platform constraint set by Google, not by Bindplane. Once you reach 10 processors, you cannot add more to that pipeline. You must either create additional pipelines per log type or move processing upstream to a Bindplane gateway.
* **Processor types are restricted.** Only processors built on the OTel [transform](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/transformprocessor), [filter](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/filterprocessor), and [redaction](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/redactionprocessor) processors are supported. This means advanced capabilities like **sampling**, **deduplication**, **resource detection**, and **batching** are not available inside SecOps Pipelines.
* **Single destination only.** All data processed by a SecOps Pipeline goes to Google SecOps. You cannot fan data out to a SIEM archive, a data lake, a compliance store, or any secondary destination from within a SecOps Pipeline.
* **gRPC (Backstory API) logs are not processed.** Logs ingested via the legacy gRPC Backstory Ingestion API bypass SecOps Pipelines entirely. Only logs ingested via the newer Chronicle API ingestion methods are eligible for pipeline processing.

{% hint style="danger" %}
If your transformation or routing requirements exceed what SecOps Pipelines support, a Bindplane gateway is the correct architectural choice, not a workaround.
{% endhint %}

### What a Bindplane Gateway Can Do

A Bindplane gateway is a collector deployed to infrastructure you control (cloud VM, Kubernetes, on-premises server) that acts as a central hub for receiving, processing, and routing telemetry.

**Capabilities that go beyond SecOps Pipelines:**

* **No processor limit.** You can chain as many processors as your pipeline requires.
* **Full processor library.** Sampling, deduplication, batching, resource detection, custom OTTL transformations, connectors, and routing processors are all available.
* **Multi-destination fan-out.** The same log stream can be routed to Google SecOps, a cold storage bucket, a ClickHouse analytics cluster, Splunk, or any other supported destination, all simultaneously from a single pipeline.
* **Source flexibility.** Collect from any supported source, not just the ingestion methods accepted by SecOps Pipelines.
* **Works with all ingestion paths.** Because the gateway sends data to the SecOps API directly, gRPC and HTTPS both work and there are no restrictions based on ingestion method.

### Side-by-Side Comparison

| Capability                | SecOps Pipelines     | Bindplane Gateway |
| ------------------------- | -------------------- | ----------------- |
| Processor limit           | 10 per pipeline      | No limit          |
| Sampling                  | Not supported        | Supported         |
| Deduplication             | Not supported        | Supported         |
| Multi-destination routing | Not supported        | Supported         |
| Managed infrastructure    | Yes (Google-managed) | No (self-managed) |
| gRPC log processing       | Not supported        | Supported         |
| Connector support         | Not supported        | Supported         |
| Deployment complexity     | Low                  | Medium            |

### Choosing the Right Approach

You'll choose to send data either goes through a SecOps Pipeline or through a Bindplane gateway, not both.

#### "I have a simple enrichment or redaction requirement and no other destinations"

SecOps Pipelines are the right choice, as long as you stay within the 10-processor limit and the supported processor types. You avoid managing infrastructure, and the configuration is maintained directly in Bindplane.

#### "I need to apply more than 10 processors to a log type"

Move processing upstream. Deploy a Bindplane gateway, configure the processing there, and send the already-processed data to SecOps.

#### "I want sampling to keep my SecOps ingestion costs down"

Use a Bindplane gateway. The probabilistic sampler and tail-based sampling processors are not available in SecOps Pipelines. Configure sampling on the gateway before the SecOps destination.

#### "I need to send logs to SecOps and to a cold storage bucket"

Use a Bindplane gateway. Configure your source, then route to both a Google SecOps destination and a cloud storage destination simultaneously. SecOps Pipelines cannot fan out to a second destination.

#### "I am ingesting via gRPC (Backstory API) and need processing to apply"

Use a Bindplane gateway. Logs ingested via gRPC bypass SecOps Pipelines entirely. The gateway sends data through the Chronicle API directly, so processing is not subject to ingestion-method restrictions.

### Regulated and Compliance-Sensitive Environments

Organizations handling sensitive data in healthcare, financial services, and other regulated industries frequently evaluate whether to send data from high-volume security sources directly to Google SecOps via a native feed, or to route it through a Bindplane gateway first.

#### Direct feed (source → SecOps)

**Advantages:**

* No infrastructure to manage on the collection side.
* Simple configuration inside the SecOps console.
* Lower operational overhead for teams without dedicated pipeline engineers.

**Limitations:**

* No pre-ingestion processing. PII or PHI in log payloads reaches SecOps before any redaction can occur.
* No routing to secondary destinations. If your compliance program requires a separate audit store or SIEM, you need a separate integration.
* Limited volume control. High-cardinality sources (such as EDR tools like CrowdStrike) can generate significant log volume, and without a gateway there is no way to sample or filter before the data lands in SecOps.

#### Gateway approach (source → Bindplane → SecOps)

**Advantages:**

* PHI and PII can be redacted, masked, or dropped before data reaches SecOps, reducing compliance risk.
* Volume can be controlled via sampling or severity-based filtering before ingestion, which directly reduces SecOps ingestion costs at scale.
* The same stream can be duplicated to a separate compliant long-term archive alongside SecOps.
* Full audit trail of what was collected, what was transformed, and what was dropped, maintained at the gateway layer.

**Trade-offs:**

* Requires a Bindplane agent or gateway deployment and the associated infrastructure.
* Adds a hop in the ingestion path, which introduces a small amount of additional latency.

{% hint style="success" %}
For customers handling ePHI or other regulated data categories, the gateway approach is strongly recommended even if the immediate processing requirements are minimal. The ability to redact before ingestion and route to a compliance store is difficult to retrofit later once a direct-feed pattern is established at scale.
{% endhint %}

### Additional Resources

* [Google SecOps Pipelines feature guide](/feature-guides/pipeline-processing/google-secops-pipelines.md)
* [Using Google SecOps with Bindplane Best Practices](/how-to-guides/partner-integrations/google-secops/using-google-secops-with-bindplane-best-practices.md)
* [Google SecOps destination configuration](/integrations/destinations/google-secops-chronicle.md)
* [Google SecOps Data Processing Pipeline 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/how-to-guides/partner-integrations/google-secops/secops-pipelines-vs-bindplane-gateway.md?ask=<question>
```

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.
