TL;DR: Apache Kafka underpins real-time event streaming by using an immutable commit log, partitions, consumer groups, and replication to move data at high volume with replay and fault tolerance, according to Kong. The governance lesson is that streaming platforms turn access, observability, and data contracts into identity problems as much as infrastructure problems.
NHIMG editorial — based on content published by Kong: What is Apache Kafka? Guide for Beginners
By the numbers:
- The platform handles massive data flows for more than 80% of Fortune 100 companies.
Questions worth separating out
Q: How should security teams govern Kafka access for service accounts?
A: Security teams should treat Kafka access as a service-identity problem, not a shared infrastructure permission set.
Q: Why does Kafka create governance risk in data and API platforms?
A: Kafka creates governance risk because the same stream can feed many consumers, making access broad by default if ownership is unclear.
Q: What breaks when consumer groups are not formally owned?
A: When consumer groups are not formally owned, no one is accountable for offset state, replay behaviour, or unexpected access to streamed data.
Practitioner guidance
- Assign an owner to every consumer group Treat each consumer group as a governed service identity with a named owner, documented purpose, and explicit entitlement review.
- Separate producer, consumer, and admin privilege Do not let the same credential set publish data, read broad topic sets, and reconfigure the cluster.
- Re-baseline controls after KRaft migration Review broker, controller, and metadata access once ZooKeeper is removed, because the authority model has changed even if the business use case has not.
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 explanations of Kafka topics, partitions, offsets, and replication for practitioners who need to implement rather than just evaluate.
- Detailed walkthroughs of Kafka APIs, Streams, and Connect for teams deciding how event processing should be built.
- Practical examples of KRaft migration and the removal of ZooKeeper for teams planning platform changes.
- Coverage of Kong Event Gateway patterns for exposing Kafka through API-style access controls and discovery.
👉 Read Kong's guide to Apache Kafka fundamentals and KRaft architecture →
Apache Kafka and event streaming: what IAM teams should notice?
Explore further
Kafka is no longer just a messaging layer, it is an identity-sensitive data plane. Once topics, consumers, connectors, and admin APIs become the backbone of real-time workflows, access control and observability matter as much as throughput. That is why Kafka governance should be treated as part of machine identity and API governance, not as an isolated platform exercise. Practitioners should manage Kafka as a distributed control surface.
A few things that frame the scale:
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
A question worth separating out:
Q: How do you know if Kafka admin access is too broad?
A: Kafka admin access is too broad when the same identity can change cluster metadata, create or delete topics, and inspect traffic without separate approval or logging. The signal is not just privilege count, but whether a single administrative path can alter multiple business-critical streams without clear oversight.
👉 Read our full editorial: Apache Kafka for beginners: why event streaming matters now