Securing gRPC Traffic in Envoy: Introducing the Proto API Scrubber

In the world of microservices, gRPC has become the de-facto standard for high-performance communication. Its binary nature (Protobuf) is excellent for efficiency but presents a significant challenge for observability and security: visibility.

Unlike JSON-over-HTTP, where a simple regex can often redact a credit card number or PII (Personally Identifiable Information) from logs, gRPC payloads are opaque binary blobs to most standard proxies. If you need to scrub a specific field from a request before it hits your backend — or, more critically, before it leaks into your access logs or tracing system — you often have to decode the entire message.

Enter the Proto API Scrubber, a powerful Envoy HTTP filter designed to bring deep content inspection, granular redaction, and access control to your gRPC traffic.

The Problem: The “All or Nothing” Dilemma

Standard Envoy filters operate brilliantly on headers and raw bytes. However, when it comes to the body of a gRPC message, you typically face an “all or nothing” choice:

1. Blind Forwarding: You pass the traffic through, risking PII leakage in logs or downstream services.
2. Full Deciding (Expensive): You write a custom Lua or Wasm filter to parse the body, which can be performance-prohibitive and fragile to manage.

The Proto API Scrubber solves this by understanding the schema of your traffic.

How It Works

The filter loads a Protobuf FileDescriptorSet at configuration time. This allows it to "see" the structure of the incoming binary stream. It converts the Envoy buffer into a traversable message, applies your policy rules, and re-encodes the message—all within the filter chain.

It leverages the Envoy Unified Matcher API, meaning you can trigger scrubbing actions based on any standard Envoy input: request headers, CEL expressions, or dynamic metadata.

Key Capabilities

1. Granular Field Scrubbing: Target specific fields for removal while preserving the rest of the message. Example: Remove user.credit_card.number but keep user.id.
2. Global Message Security (The “Any” Solution): This is a game-changer for complex architectures. You can define rules on a Message Type basis. Scenario: You have a SensitiveAuditLog message type. You can configure the filter to scrub fields from this message wherever it appears—even if it's nested deep within a google.protobuf.Any field or a recursive structure.
3. Method-Level Access Control: Need to deprecate a specific gRPC method or block it for certain users? You can enforce “Early Rejection” (404 NotFound) based on the method name and headers, blocking the request before the expensive payload parsing even begins.

Performance: Smart Caching for High Throughput

One of the biggest concerns with deep inspection is latency. We recently optimized the filter to minimize this overhead significantly.

The filter now implements Matcher Deduplication and Result Caching.

• Deduplication: If you configure the same restriction rule (e.g., “Scrub if user is guest") for 50 different fields, the filter intelligently maps them to a single evaluation logic in memory.
• Caching: The result of that evaluation is cached per request. If a rule is checked 1,000 times (e.g., inside a massive map or repeated field), the expensive check runs only once.

The Result? In our benchmarks with complex, nested payloads (10k+ fields), we saw latency reductions of ~20%, keeping the overhead minimal even for heavy traffic.

Configuration Example

Configuring the scrubber is straightforward. You provide the descriptor set and define your restrictions.

Here is a simple example that removes the raw_credit_card_data field from the GetTransaction response unless the user is an admin:

name: envoy.filters.http.proto_api_scrubber
typed_config:
  "@type": type.googleapis.com/envoy.extensions.filters.http.proto_api_scrubber.v3.ProtoApiScrubberConfig
  descriptor_set:
    filename: "/etc/envoy/descriptors/bank.pb"
  restrictions:
    method_restrictions:
      "/bank.BankingService/GetTransaction":
        response_field_restrictions:
          "raw_credit_card_data":
            matcher:
              matcher_list:
                matchers:
                  - predicate:
                      # CEL: Evaluates to true if x-user-role is NOT admin
                      single_predicate:
                        input:
                          name: envoy.matching.inputs.request_headers
                          typed_config:
                            "@type": type.googleapis.com/envoy.type.matcher.v3.HttpRequestHeaderMatchInput
                            header_name: "x-user-role"
                        value_match:
                          exact: "guest" 
                    on_match:
                      action:
                        name: remove
                        typed_config:
                          "@type": type.googleapis.com/envoy.extensions.filters.http.proto_api_scrubber.v3.RemoveFieldAction

Getting Started

The Proto API Scrubber is available in the Envoy contrib build. It is the missing piece for platform engineers who need strict data compliance (GDPR, PCI-DSS) without sacrificing the speed and structure of gRPC.

Check out the official documentation to learn more about the filter and its advanced features.