Skip to main content
Question

Set up data processing using API methods to redact okta user context logs

  • July 15, 2026
  • 1 reply
  • 17 views

DOwusu
Forum|alt.badge.img+1
Hi all, I am trying to test googles “Data processing using API methods” (No bindplane)

I was wondering has anyone tried to use this feature yet and have any tips.

I am testing with OKTA_USER_CONTEXT and trying to redact PII but just for testing I am trying to redact the “Title” field. I tried it but not sure if I can redact a whole field using blockedKeyPatterns or does it only work on with blockedValues.

 

Documentation used: 

Hi all,

I am testing Google SecOps Data Processing Pipelines using the API methods directly, without deploying Bindplane agents/collectors. My use case is OKTA_USER_CONTEXT, where I am trying to redact PII from the Okta user profile payload before the data is stored/parsed in Google SecOps.

For initial testing, I associated a data processing pipeline to a specific OKTA_USER_CONTEXT and confirmed the pipeline is associated using fetchAssociatedPipeline. The pipeline currently has a redactProcessor

I first tried testing field-based redaction using blockedKeyPatterns against the Okta profile field:

 
{
"processors": [
{
"redactProcessor": {
"allowAllKeys": true,
"blockedKeyPatterns": [
"^title$"
]
}
}
]
}

The sample Okta payload has the field nested under profile.title, for example:

 
"profile": {
"email": "user@example.com",
"login": "user@example.com",
"startDate": "2022-01-01",
"title": "Manager",
"userType": "Employee"
},
"status": "ACTIVE",
"statusChanged": "2025-01-13T06:36:59.000Z"

However, I still see the profile.title value in new events, so I am trying to understand whether blockedKeyPatterns supports nested JSON keys such as profile.title, or whether it only matches top-level/flattened key names depending on how the payload is represented internally.

I am also testing blockedValues, which matches the Google examples for regex/value-based redaction:

 
{
"processors": [
{
"redactProcessor": {
"blockedValues": [
"\\b[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}\\b",
"Manager",
"2022-01-01"
],
"allowAllKeys": true
}
}
]
}

My questions are:

  1. Does blockedKeyPatterns support nested JSON fields like profile.title, or only direct key names?
  2. If using blockedValues, is there any way to scope value redaction to specific keys, or does it apply globally across all allowed keys?
  3. For Okta user profile payloads, is the recommended approach to redact PII using blockedValues regex patterns rather than key-based redaction?

Any examples using OKTA_USER_CONTEXT with the API-based Data Processing Pipeline would be appreciated.

 

https://docs.cloud.google.com/chronicle/docs/ingestion/data-processing-pipeline#using_secops_data_pipeline_apis

1 reply

whathehack81
Forum|alt.badge.img+5

Okay, so I thought about this one for a while. Based on the behavior you described, I would first separate pipeline execution from field-path matching.

Before testing blockedKeyPatterns, confirm the pipeline is actually processing new events by using a unique blockedValues marker:

{

  "processors": [

    {

      "redactProcessor": {

        "blockedValues": [

          "^CASPER_REDACT_TEST_7f3c$"

        ],

        "allowAllKeys": true

      }

    }

  ]

}

Send a newly ingested event containing that exact value. If it remains visible, the likely issue is pipeline association, activation, revision propagation, or processing order rather than the key regex.

To determine how blockedKeyPatterns handles nested fields, test a payload containing both top-level and nested keys:

{

  "title": "TOP_LEVEL",

  "profile": {

    "title": "NESTED_TITLE"

  },

  "other": {

    "title": "OTHER_TITLE"

  }

}

Then test these patterns separately:

"^title$"

"^profile\\.title$"

That should show whether matching is based on the leaf key, a flattened field path, or only top-level keys.

For blockedValues, my understanding is that with allowAllKeys: true, matching is value-based across the keys traversed by the processor rather than scoped to one named field. Because of that, generic values such as Manager or 2022-01-01 may cause unintended redaction elsewhere.

For structured Okta payloads, key-based redaction is likely safer when the schema is stable. Value-based regex is better suited to recognizable PII formats such as email addresses, phone numbers, or identifiers.

I would also verify:

Testing is performed with newly ingested events.

The expected pipeline revision is active.

The ingestion source is associated with that revision.

fetchAssociatedPipeline returns the same source/log type being tested.

The displayed profile.title field is not being created later during parsing or normalization.

I would be interested to know whether Google confirms that blockedKeyPatterns supports dotted nested paths such as profile.title.... 🤔