Notifications
Clear all
Topic starter
24/06/2026 7:16 pm
TL;DR: As Kafka adoption spreads across teams, regions, and external consumers, governance breaks down through inconsistent policies, silent contract drift, fragmented observability, and reactive controls, according to Kong. The architectural answer is a central event gateway layer that applies identity-aware policy, schema enforcement, and auditability before data reaches Kafka.
NHIMG editorial — based on content published by Kong: From Kafka Chaos to Control: A Practical Guide to Governing Real-Time Data
Questions worth separating out
A: Security teams should move governance closer to the event boundary by centralising policy enforcement, schema checks, and identity-aware access decisions.
Q: Why do broker ACLs often fall short for real-time data governance?
A: Broker ACLs are too coarse when teams need field-level filtering, identity-aware authorisation, or event-level masking.
Q: How can organisations tell whether Kafka governance is working?
A: Governance is working when malformed messages are blocked at ingestion, identity-linked audit logs are complete, and teams no longer rely on developer-by-developer security decisions.
Practitioner guidance
- Map governance gaps to the event boundary Identify where client-side validation, schema enforcement, and access checks are currently distributed across producers and consumers.
- Require identity-aware authorisation for shared topics Use JWT, OAuth scope, and mTLS-based controls where multiple consumers rely on the same Kafka estate.
- Treat schema rejection as a control, not an error path Block malformed or contract-breaking messages at ingestion rather than repairing them downstream.
What's in the full article
Kong's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of event gateway policy enforcement across Kafka producers and consumers.
- Specific handling for schema validation, identity-aware authorisation, and data masking at ingestion.
- Operational guidance on rate limiting, audit logging, and backpressure controls for shared streaming environments.
- The vendor's positioning on how an event gateway fits alongside existing Kafka deployments.
👉 Read Kong's practical guide to governing real-time data with an event gateway →
Kafka governance at scale: where the control gap shows up?
Explore further
25/06/2026 4:29 am
Kafka governance now depends on moving control closer to the event boundary. Broker ACLs were built for coarse access control, not for identity-aware policy enforcement across shared producers and consumers. When teams need field-level filtering, schema validation, and per-identity auditability, the control model has already outgrown the platform’s default guardrails. The practitioner conclusion is that governance must be enforced where data enters the stream, not reconstructed after the fact.
A few things that frame the scale:
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the same research.
A question worth separating out:
Q: What is the difference between Kafka ACLs and an event gateway?
A: Kafka ACLs control basic access to brokers and topics, while an event gateway can enforce identity-aware policy, validate schemas, mask data, rate limit traffic, and tie auditability to the caller. They solve different layers of the problem, so teams often need both, but only a gateway can govern the event itself.
👉 Read our full editorial: Kafka governance needs a control layer as event streams scale
