RBAC Cache & Cluster-Wide Invalidation

The V2 RBAC pipeline resolves a principal's role assignments and effective permissions on every request. To avoid hammering the database, ProAuth caches both shapes in process and propagates invalidations across the cluster via the platform pub/sub.

This page documents the operational expectations of that cache.

Cached authorization data

ProAuth caches role assignments and effective permissions separately on each instance. Both expire after 30 seconds. Concurrent requests share cached results until a change invalidates them or they expire.

Worst-case staleness

A cache hit can return data that is at most 30 seconds older than the database row. After 30 s the entry is treated as expired and the next request triggers a fresh load.

Permission grants that are time-critical for security (e.g. revoking an active administrator) should not rely solely on TTL — make the change through the Management API v2 or AdminApp, which publishes the invalidation automatically.

Cluster-wide invalidation

Changes to role assignments, roles, users and groups invalidate the relevant authorization data across the cluster. Use the Management API v2 or AdminApp for these changes; direct database edits do not send the required notifications.

Every serving instance must be connected to the same configured messaging backplane. Propagation time depends on network and messaging health; expiry provides a fallback when an invalidation notification is missed.

Operational expectations

• Clock skew between pods does not matter. TTL is measured from cache-write time on each pod independently.
• A failed pub/sub publish does not corrupt the cache. Stale entries simply expire after 30 s.
• Restarts are safe. The cache is in-memory only; a fresh process starts with an empty cache.
• Shared messaging. Every serving instance must receive authorization-change notifications through the configured pub/sub backend. In-process messaging is suitable only for a single-instance deployment.

Verifying the backplane

A simple smoke test for a multi-instance deployment:

1. Pick two pods A and B.
2. Issue a request on A that resolves a principal's roles (any V2 API call as that principal).
3. On B, delete one of that principal's role assignments via DELETE /api/management/v2/ProAuthRoleAssignment/{id}.
4. Re-issue the request on A within ~1 s. The deleted role must no longer be effective.

If step 4 still observes the old role for more than ~5 s, the pub/sub backplane between A and B is misconfigured (e.g. different pub/sub component names, a Redis ACL rejecting subscribe). Consult the Dapr / pub/sub component logs.