Single-topic multi-tenant architecture. Client-side data filtering by path prefix

[vorbidan]

In the single-topic multi-tenant architecture, all OPAL clients subscribed to a topic receive all data updates, even if they only need a subset.

Use case: Service mesh deployment where each sidecar OPA serves a single tenant.

Pod (tenant-1):
  OPAL_DATA_TOPICS=tenant_data
  
  # Receives ALL tenant updates:
  /acl/tenant-1/roles  ← needs this
  /acl/tenant-2/roles  ← doesn't need, but stored anyway
  /acl/tenant-3/roles  ← doesn't need, but stored anyway

This leads to:

• Memory bloat — each OPA holds data for all tenants
• Unnecessary OPA writes — storing data that will never be queried
• Potential data isolation concerns — tenant data present on unrelated pods

Proposed Solution

Add a client-side configuration option to filter data entries by dst_path prefix:

OPAL_DATA_FILTER_PATH=/acl/tenant-1

Behavior:

• Client receives data update notification (as normal)
• Before storing in OPA, check if entry.dst_path starts with OPAL_DATA_FILTER_PATH
• If match → store in OPA
• If no match → discard silently (or log at debug level)

Example:

# Service mesh client - only stores tenant-1 data
OPAL_DATA_TOPICS=tenant_data
OPAL_DATA_FILTER_PATH=/acl/tenant-1

# Gateway client - stores all data (no filter)
OPAL_DATA_TOPICS=tenant_data
# OPAL_DATA_FILTER_PATH not set

Implementation Sketch

In opal_client/data/updater.py, add filtering after topic matching:

# Existing topic filter (~line 476)
if set(entry.topics).isdisjoint(set(self._data_topics)):
    continue

# Proposed path filter
if self._data_filter_path and not entry.dst_path.startswith(self._data_filter_path):
    logger.debug(
        "Skipping entry {path} - doesn't match filter {filter}",
        path=entry.dst_path,
        filter=self._data_filter_path
    )
    continue

Benefits

• Simple — small, scoped change
• Backward compatible — no filter = current behavior
• Enables hybrid deployments — single-topic simplicity + per-tenant isolation
• No server changes required

Alternatives Considered

Alternative	Why Not
Multi-topic per tenant	Requires managing topic lists, gateway needs restart for new tenants
Scopes	1 scope = 1 client, doesn't fit gateway use case; overkill if policy is shared
External filtering proxy	Additional infrastructure complexity

Additional Context

This came up while evaluating single-topic multi-tenant for a deployment with two modes:

• Gateway: One OPA serving all tenants (needs all data)
• Service mesh: One OPA per tenant sidecar (needs only its tenant's data)

The single-topic pattern is perfect for the gateway, but causes unnecessary data bloat for service mesh sidecars.

[orweis]

TL;DR- doesn't feel like a critical feature, but we'd be happy to accept a PR

Nice idea, and I can relate to the memory bloat issue, though haven't really seen people complain about this specific scenario.
I do have concerns about debugging challenges as people would lose track of which instances they ran with which filters (So much PBCAK) - so docs here should come with extra warnings, and logs should be very clear on data being dropped (both startup and at filtering level)
I'd also suggest filter being regex or wildcard based and not just prefix based, as there isn't a uniform template for topic names at the moment.