Notifications
Clear all
Topic starter
24/06/2026 7:20 pm
TL;DR: Static Kafka ACLs break down in multi-team environments because they cannot use identity context, forcing hardcoded topic lists, over-permissive access, and configuration drift, according to Kong. The governance question is no longer whether ACLs work, but whether access policy should be driven from identity claims instead of cluster-level permissions.
NHIMG editorial — based on content published by Kong: Dynamic Kafka ACLs: Implementing Identity-Aware Policies with Kong Event Gateway
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should teams govern Kafka access when permissions depend on identity claims?
A: Treat the identity provider as the source of entitlement truth and the gateway as the enforcement point.
Q: Why do static Kafka ACLs become risky in multi-team environments?
A: They create broad permissions, manual exceptions, and configuration drift because they cannot adapt to changing team scope or workload context.
Q: What should security teams measure when using claim-based topic access?
A: Track how quickly entitlements change in the identity system, how often token claims are reviewed, and whether revoked access still works before token expiry.
Practitioner guidance
- Map Kafka entitlements to identity source of truth Document which identity provider owns topic-level claims, which team approves them, and how those claims are revoked when roles or projects change.
- Replace hardcoded topic lists with scoped claims Use short-lived tokens carrying explicit topic or pattern claims, then validate that the gateway resolves them consistently across environments and client types.
- Audit wildcard access and policy drift Look for topic-* permissions, manual broker exceptions, and duplicated ACLs that indicate access is being managed outside the identity layer.
What's in the full article
Kong's full blog post covers the implementation detail this analysis intentionally leaves for the source:
- The exact Kong Identity and Event Gateway configuration used to validate JWT claims and enforce ACLs
- The expression syntax for mapping token claims to topic access in the virtual cluster
- The step-by-step example showing how topic permissions change when claims are updated
- The advanced patterns for mixing static lists, topic wildcards, and role-based access logic
👉 Read Kong's engineering post on identity-aware Kafka ACLs →
Kafka ACLs and identity context: what IAM teams need to know?
Explore further
25/06/2026 4:34 am
Static ACLs create an identity blind spot when the caller is known at runtime. Kong's core point is not simply that ACLs are hard to maintain. It is that broker-level permission lists cannot express the identity context already available in tokens, so access policy lags behind the caller's actual state. For NHI governance, that means the control plane is making decisions with stale or incomplete identity information. Practitioners should treat that as a structural mismatch between authorization and identity source of truth.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Only 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Who should own Kafka authorization when access is driven by workload identity?
A: Ownership should sit with the IAM or identity platform team, with platform engineering responsible for enforcement plumbing and application teams responsible for declaring least-privilege needs. That separation keeps policy governance aligned with identity lifecycle, rather than scattered across broker administrators and application owners.
👉 Read our full editorial: Identity-aware Kafka ACLs expose the limits of static policies
