How Apache Kafka SSO and identity integration fits your existing identity stack
If you run a self-hosted Kafka cluster and want client and admin logins to follow the identity provider you already operate, the work is to connect Kafka's SASL and TLS authentication to that provider, then map the resulting principals to authorization rules that Kafka enforces. The usual options are SASL/OAUTHBEARER with an OIDC provider, Kerberos through GSSAPI, SCRAM credentials, and mutual TLS client certificates. Each one ties identity to Kafka differently, so the right choice depends on what your directory and certificate authority already support, not on which mechanism is easiest to switch on. The difficulty is that these pieces do not line up automatically. Kafka's documented SASL mechanisms validate identity in different ways, so a token signed by your OIDC provider, a Kerberos ticket and a SCRAM username and password each produce a principal with different properties and different revocation behavior. The principal name Kafka derives from a certificate or Kerberos identity must match exactly what your ACLs expect, or access will be denied in ways that look like misconfiguration. Security is also optional on each listener, so a cluster can run unsecured listeners next to secured ones. A partial rollout can leave an unauthenticated path open even after the main listener has been locked down.
Kafka 4.x runs in KRaft mode only, and ZooKeeper mode has been removed. Identity settings therefore belong to the KRaft cluster model: controller listeners, broker listeners and the metadata log that stores ACLs all need to be considered together. If your environment still carries configuration copied from ZooKeeper-era guides, review it before changing authentication, because some of those settings no longer apply and others now mean something different. Confirm your target release against the supported versions list on the Kafka downloads page before you design around any particular behavior. In KRaft clusters, the StandardAuthorizer stores ACLs in the cluster metadata log. Resources without a matching ACL are restricted to super users unless allow.everyone.if.no.acl.found is set to true. Leaving that setting at its default is the safer starting point, but it means every application, connector and admin tool needs an explicit grant before identity integration can be tested end to end. Plan that inventory of principals early, because it determines how much of the rollout is configuration and how much is coordination with the teams that own each client.
Apache Kafka is licensed under the Apache License 2.0 (SPDX: Apache-2.0), and the project does not sell a paid edition. Identity integration is therefore configuration and engineering work carried out inside your own environment, using your identity provider, your certificate authority or your directory, and your cloud or data center network. No part of the design depends on a vendor-hosted service. Before starting, confirm with your identity team which OIDC issuer, Kerberos realm or certificate authority will be the source of truth, who approves changes to it, and how quickly a disabled account or revoked certificate must stop Kafka access. Those answers set the scope of the work more than the Kafka settings themselves.
Which Kafka components carry identity
An identity integration touches a small set of Kafka components: listeners, SASL mechanisms, client configuration, the authorizer and the principal names it matches. Each one has to agree with the others, or a client can authenticate successfully and still be denied access, or be mapped to a name nobody intended.
Broker listeners with SSL and SASL
Each broker listener declares which security protocol it accepts, such as SSL for mutual TLS or SASL_SSL for SASL over encrypted transport. Kafka lets a cluster run secured and unsecured listeners side by side, so an identity integration must confirm that every client-facing and inter-broker listener is intentionally configured. Check which listeners are reachable from outside the trust boundary and whether plaintext listeners remain enabled after cutover.
SASL mechanisms Kafka documents
Kafka documents five SASL mechanisms: GSSAPI for Kerberos, PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER for token-based login. Each maps to a different identity source, credential lifecycle and operational burden. Choose the mechanism based on the identity system you already run, and confirm the exact client library support for your languages before committing. The security overview describes each mechanism in detail.
Client configuration
Clients, Kafka Connect workers and command-line tools each carry their own security settings, including the protocol, the SASL mechanism, JAAS or callback configuration and truststores. Identity integration fails most often here, because a single service with a stale credential or a missing truststore can block a deployment. Inventory every client type, its owner and how its secrets are rotated before the cutover date is set.
Pluggable authorizer and its ACL store
Kafka authorization is pluggable, and the StandardAuthorizer used in KRaft clusters stores ACLs in the cluster metadata log. This means ACL changes replicate with the metadata itself rather than living in an external database. Without ACLs, resources are restricted to super users unless allow.everyone.if.no.acl.found is set to true, so confirm that setting explicitly. Ask whether an external authorization service is needed, and what it would add to operations.
Principal names that ACLs match
ACLs match against a principal string derived from the authenticated identity, such as a Kerberos principal, a SCRAM username or a name extracted from a certificate or token. The mapping from identity provider claims or certificate subjects to that string is where many access problems originate. Define the mapping rules in writing, test them with a representative identity from each source, and review them whenever the identity provider changes its naming format.
Authorization and audit trail
ACL definitions, super user membership and authorization decisions form the evidence a security reviewer will ask for. Kafka's authorization documentation describes how ACLs apply to operations on topics, groups and the cluster, which is the reference for writing and reviewing rules. Plan for how authorization denials are logged and retained, and confirm which events your audit tooling can capture from the brokers.
Apache Kafka SSO options: OIDC, Kerberos, SCRAM and mTLS compared
This table compares the four main ways to authenticate Kafka clients against your identity systems, judged by the fit for each population and the operational work each one creates. Read each row as a decision question, then check the cost column against the identity team you already have. The main takeaway is that the mechanism matters less than who owns its credential lifecycle after go-live.
| Decision factor | SASL/OAUTHBEARER with OIDC | Kerberos via GSSAPI | SCRAM and mTLS |
|---|---|---|---|
| Best fit | Applications and human users who already sign in through an OIDC provider | Estates built on Active Directory or a Kerberos realm with keytabs already managed | SCRAM for service accounts needing simple credentials; mTLS for certificate-managed workloads |
| Token or credential lifecycle | Token validation design, signing key rotation and token lifetime settings must be agreed with the identity team | Keytab issuance, ticket renewal and principal rotation must be scheduled and tested per service | SCRAM credentials are stored in cluster metadata and need rotation; mTLS needs certificate issuance and revocation processes |
| Broker-side configuration | Validator settings and trusted issuer configuration on each listener; confirm against the 4.3 security documentation | Service principal names, keytab paths and realm settings on brokers and clients | Credential creation through admin tools for SCRAM; truststore and client certificate chain for mTLS |
| Failure mode to plan for | Expired or misconfigured signing keys stop all token-based logins at once | Clock skew or expired tickets cause authentication failures that are hard to diagnose | Leaked SCRAM secrets or unrevoked client certificates remain valid until rotated or removed |
| Human users versus service accounts | Usually the strongest fit for human users, with short-lived tokens | Often suited to service identities inside a Windows domain | Often suited to service accounts; keeping human access on a separate mechanism is a common choice to confirm with your security team |
| Mixing mechanisms across listeners | Possible: expose different listeners for different client groups, with each listener's authentication settings defined separately | Possible in the same way, but each additional mechanism adds a configuration and testing path | Possible; mixed listeners widen the review scope and must be covered by ACLs and monitoring |
| PLAIN | Not recommended as a substitute; PLAIN sends credentials in a form that depends on TLS for protection, so use it only as a deliberate, TLS-protected choice | Same caution applies; enable only when a specific client requires it and TLS is enforced on that listener | Same caution applies; SCRAM is the password-based option to prefer over PLAIN |
| Ongoing cost owner | Identity team for the provider, platform team for Kafka validator settings | Directory or Kerberos administrators plus platform team for keytabs | Platform team for credential issuance; security team for certificate revocation and review |
Apache Kafka SSO build sequence, from listeners to verified logins
This sequence moves a Kafka cluster from unauthenticated access to SSO-backed logins one listener and one application at a time, with a verified check closing each stage so the team knows what works before the next change.
Confirm cluster version and KRaft mode
Before touching authentication, record the Kafka version of every broker and controller and confirm the cluster runs in KRaft mode, since Kafka 4.0 supports only KRaft and ZooKeeper-based clusters must migrate first. Check the supported release list on the downloads page and the upgrade notes for the target version, and confirm the Java runtime on each broker meets the requirement for that release. The step closes when the team has a written inventory of versions, controller and broker roles, and Java versions that matches what the cluster reports, with no unsupported release in use.
Define identity source and principal naming
Decide which identity system is the source of truth for users, service accounts and groups, such as an OIDC provider, a Kerberos realm or a directory behind them. Write a principal naming scheme that maps each identity type to a Kafka principal, including how service accounts are named and how group claims will feed ACLs. Agree the naming with the security and application owners before any broker configuration changes. The step closes when a reviewed document lists each identity type, its Kafka principal format and the owner who approves changes to it.
Enable TLS on SASL listeners
Add a dedicated listener for SASL traffic and enable TLS on it, with broker certificates issued from the organization's chosen certificate authority and trust settings distributed to clients. Keep existing listeners running so applications are not interrupted while the new listener is built. Confirm the certificate chain, hostnames and expiry dates are correct for every broker. The step closes when a TLS handshake to the new listener succeeds from a test client and the certificate details match the inventory.
Configure one mechanism on a test listener
On a non-production listener, enable a single SASL mechanism that matches the identity source, such as OAUTHBEARER for an OIDC provider, GSSAPI for Kerberos or SCRAM for stored credentials. Avoid enabling several mechanisms at once, because each one widens the surface you must test and monitor. Restart brokers according to the change process and confirm the listener advertises only the chosen mechanism. The step closes when a broker configuration check shows the mechanism active on the test listener and nowhere else.
Validate tokens or tickets against the broker
Obtain a token or Kerberos ticket from the identity provider for a test identity and present it to the broker through the test listener. Confirm the broker extracts the expected principal from the credential and that group or claim data maps to the naming scheme from the earlier step. Test with an expired credential and a credential from an untrusted issuer or realm, and confirm both are rejected. The step closes when the valid login is accepted with the expected principal and both invalid credentials fail with clear broker logs.
Test a single service account end to end
Add client configuration for one service account only, then run an authenticated produce and consume on a test topic. Next, create an ACL that allows the service account to read a second topic, and confirm a read against a topic it is not granted is denied. Keep the ACL scope narrow and document which resources the account can reach. The step closes when the authenticated produce and consume succeed, and the ACL-denied topic read fails with an authorization error recorded in the broker logs.
Move applications and retire unauthenticated paths
Migrate applications one at a time, each with its own principal, ACLs and rollback plan, and monitor authentication failures during each cutover. When all clients use the authenticated listener, remove the plaintext or unauthenticated listeners and review whether allow.everyone.if.no.acl.found is still needed, since resources without ACLs are otherwise limited to super users. Confirm the remaining principals and super user list match the approved inventory. The step closes when a connection attempt on the retired listener is refused and an audit of active principals shows no unowned or shared accounts.
Mapping identities to Apache Kafka ACLs without opening the cluster
Authentication answers one question: who is this client? It does not decide what that client may do. In a Kafka cluster, that decision belongs to the authorizer, and in KRaft mode the StandardAuthorizer is the component that evaluates each request against stored access control lists. Every identity you integrate, whether it arrives as an OIDC token claim, a Kerberos principal or a SCRAM username, becomes a principal that the authorizer matches against ACL entries. If you get the principal name wrong, the integration works at the login step and then fails, or quietly succeeds in the wrong place, at the authorization step. Plan the mapping before you enable any listener. ACLs are stored in the cluster metadata log that KRaft controllers replicate, not in an external directory that brokers query on each request. That design means your ACL state travels with the cluster's own metadata and can be inspected with the Kafka admin tooling. It also means every change is a metadata change that your change control should record. The important default is that a resource with no matching ACL is restricted to super users, unless allow.everyone.if.no.acl.found is set to true. Confirm the value on every broker in your environment, because a single broker with a different setting can make the deny-by-default posture inconsistent. Leaving allow.everyone.if.no.acl.found set to true undoes deny-by-default. Any authenticated principal can then reach any topic or group that has no ACL, which includes topics created later by a team that never asked for access. Treat that setting as a migration aid at most, and remove it once every existing resource has explicit grants. Before you flip it, list the resources that currently have no ACLs and decide who should own each one. Use the authorizer's ACL listing output as your evidence, and record the result with the change ticket. Super users bypass ACL checks entirely, so membership in that list should be small and named. Keep the super user list to the controller and broker service identities and a short list of named operators, and grant application principals only the specific operations they need. Revisit the list whenever staff change roles. For group-style ownership, model it with a naming convention that maps each team's identity to prefixed topics and consumer groups, using prefix-match ACLs rather than one entry per resource. Illustrative example: a payments team's OIDC group claim maps to a principal that holds read and write on topics prefixed with its team name and describe on the matching consumer groups. Confirm which resource pattern types your Kafka version supports before you design around them. MirrorMaker 2 can replicate ACLs between clusters, so your mapping decisions do not stay on one site. A principal name that is valid in the source cluster is replicated to the target, where it may refer to a different or missing identity provider configuration. Before enabling ACL replication, confirm that the target cluster uses the same principal format and the same super user list, and decide whether ACLs should be replicated or managed locally. The geo-replication documentation for Kafka 4.3 describes this behavior, so review it alongside your replication design.
What drives the cost of an Apache Kafka identity integration
This table lists the factors that most change the effort of an identity integration for self-hosted Kafka and explains how to keep each one contained. Read each row as a lever: the driver explains why effort grows, and the reduction column shows the design choice that limits it. The main takeaway is that most of the effort comes from the number of distinct mechanisms, identity sources and client classes, so standardizing these early reduces both the build and the ongoing work.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Client applications and teams | Each application needs its own credentials, client settings, testing and sign-off, and each owning team adds coordination. | Group applications into a small number of client classes and reuse one tested client configuration template per class. |
| Identity sources | Every additional directory, identity provider or Kerberos realm adds mapping rules, trust setup and claim or principal checks. | Use a single identity source for Kafka principals where possible, and map any secondary sources into it before they reach Kafka. |
| Mechanisms per listener | Each listener running a different SASL mechanism or TLS setup multiplies configuration, testing and monitoring paths. | Use one mechanism per client class and roll new listeners out in stages, so each stage has a narrow test scope. |
| Existing ACLs to migrate | Legacy ACLs tied to raw user names or hosts must be translated to principal-based rules, reviewed for over-broad grants and cut over without breaking consumers. | Inventory current ACLs first, remove unused entries, and convert them in batches by topic or application owner. |
| Environments | Development, test, production and any disaster recovery cluster each need identity configuration, certificates or keys and verification runs. | Keep configuration in version-controlled templates with only environment values changed, and promote the same artifacts through each environment. |
| Connectors and Kafka Streams applications | These run as service workloads that need their own credentials, secret rotation and restart handling, and they often fall outside the team that owns client apps. | Assign each connector and Streams application a dedicated principal and a documented secret source, and cover them in the same test plan as clients. |
| Compliance evidence requirements | Assessors may ask for evidence of authentication settings, access reviews and change history, which adds collection and documentation work. | Confirm the evidence list with your assessor before the build, and generate configuration and access records as part of normal change control. |
How identity integration differs for single-cluster, multi-site and air-gapped Kafka
On a single cluster on virtual machines, identity work centers on broker listeners and the ACL migration. Each listener defines which SASL mechanism and TLS settings clients must use, so the change is mostly a listener and client configuration exercise. Most teams plan a window in which the existing and new authentication run side by side.
- Listener design: Decide whether the new OAUTHBEARER, GSSAPI or SCRAM listener replaces the current listener or runs beside it during cutover, and keep inter-broker and controller traffic on their own settings.
- Principal mapping: Confirm how identity provider claims or Kerberos principals map to the Kafka principal name, because ACLs match on that name.
- ACL migration: Export existing ACLs, rewrite them against the new principal names, and confirm that no resource is left without an ACL while allow.everyone.if.no.acl.found is at its default.
- Client inventory: List every application, Connect worker and admin tool. Each needs its own configuration change, and each can fail independently.
Confirm with the security documentation for your Kafka version how your chosen mechanisms are configured, and rehearse the cutover on a non-production cluster that matches your listener layout.
With MirrorMaker 2, consumer group offsets and ACLs replicate between clusters, but authentication settings do not. Each cluster keeps its own listener and identity configuration, so the same user or service must work on both sides for failover to succeed. The replicated ACLs are only useful if the principal names they reference resolve identically at the target site.
- Principal parity: Confirm that each user or service produces the same principal name on both clusters, and that the replicated ACLs reference that name.
- Offset continuity: Check that consumers which resume from replicated offsets authenticate with the same principal at the target site, or they will be denied after failover.
- Identity provider reachability: If tokens come from an identity provider in one site, failover depends on that provider being reachable from the other site. Test this path explicitly rather than assuming it.
- Token and key settings: Compare token lifetimes, signing key rotation and clock synchronization between sites, since mismatches can cause intermittent authentication failures during a failover.
- Replication scope: Confirm which topics, groups and ACLs your MirrorMaker 2 configuration includes, so that no identity dependency is missing from the replicated set.
Confirm with the geo-replication documentation for your version how offsets and ACLs are translated, and run a failover test that authenticates every consumer group from the target site.
In an air-gapped or restricted network, the identity sources, certificate authority and token validation must all run inside the boundary. Public identity services and online revocation checks are unavailable, so every trust element needs an internal owner and a documented process for rotation. Kerberos adds a time dependency that is easy to overlook.
- Internal identity source: Confirm whether you will run an internal OIDC provider or a Kerberos realm, how it is replicated for availability, and how clock synchronization is enforced across brokers, clients and the key distribution center.
- Certificate authority handling: Brokers, clients and the identity provider need certificates that chain to an internal CA. Plan distribution of root and intermediate certificates and renewal without relying on external revocation services.
- Offline token validation: Confirm whether your OAUTHBEARER validation can verify signatures from locally stored key material or needs a remote call, and how key rotation is delivered to brokers by hand.
- Dependency packaging: Confirm that the libraries required for GSSAPI or OAUTHBEARER validation can be built, verified and upgraded from an internal repository.
- Audit trail: Keep records of identity, key and certificate changes locally, because no external service will hold them for you.
Confirm each of these elements with your own security team and the vendor documentation for your identity platform before the design is fixed, and test certificate rotation in a staging enclave.
Securing the identity layer: credentials, certificates and admin access
Once Kafka trusts an identity provider, Kafka's own credential stores, certificates and admin paths become the places an attacker would look first. The cards below cover the identity-specific controls that keep those paths closed, and the full platform hardening scope is covered in the security hardening topic.
TLS on every credential listener
Any listener that carries SASL credentials, bearer tokens, Kerberos tickets or client certificates needs TLS, because SASL alone does not encrypt traffic. Kafka security is optional per listener, so a single plaintext listener left for convenience can expose credentials that the rest of the design protects. Check every listener in the broker configuration, including inter-broker and controller listeners, and confirm that no credential-bearing path falls back to plaintext.
Secret storage for SCRAM and keytabs
SCRAM password hashes live in the cluster metadata, and Kerberos keytabs and client private keys are files on disk or in a secrets manager. Decide where each secret is generated, who can read it and how it is injected into broker and client processes without landing in shell history, container images or version control. Ask your team to confirm that keytab file permissions are restricted to the service account and that no keytab is copied between hosts without a recorded reason.
Rotation procedures per credential type
SCRAM passwords, Kerberos keytabs, TLS certificates, OAuth client secrets and signing keys each rotate differently and each has a different blast radius. Write a runbook for each type that states the overlap window, the order of changes across brokers and clients, and how a failed rotation is rolled back. Confirm the procedure against a non-production cluster before the first production rotation, since a missed client update usually surfaces as an authentication failure at the worst time.
Separating inter-broker and client authentication
Brokers talk to each other with a different identity than applications do, and the inter-broker listener should not accept the credentials issued to clients. Use a dedicated listener and mechanism for broker-to-broker traffic, with its own principal that is granted only the access replication requires. Verify that a client credential cannot authenticate to the inter-broker listener and that the broker principal cannot be used by an application.
Restricting super users and admin tools
Super users bypass ACLs, and resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true. Keep the super user list short, bind it to named service identities rather than shared accounts, and review it whenever a team or service changes. Confirm that command-line admin tools, which run with the credentials on the operator's workstation, are limited to a small group using identities that are logged and revocable.
Protecting Connect REST and client configs
The Kafka Connect REST API and client property files often hold connector credentials, database passwords and truststore passwords in plain text. Restrict REST access to authenticated administrators, avoid returning secret values through configuration endpoints, and store client configs in a secrets system rather than in application repositories. Ask your team to confirm which configuration endpoints are reachable from which networks, because these interfaces are a common route to credential exposure.
How to test that Apache Kafka SSO works and fails safely
The most important thing to establish before cutting over Kafka authentication is that every denial path works as designed, not only the happy path. A login that succeeds proves little on its own. Your test plan should show that an authorized client gets through, that a rejected credential stays rejected, that an identity without permissions cannot read or write, and that an unauthenticated connection never reaches a listener that requires authentication. Write each case down with an expected result before you run it, so the outcome cannot be reinterpreted afterward.
Core test cases. Start with five. First, an authenticated client with a valid token, Kerberos ticket or SCRAM credential should produce and consume on a topic it has an ACL for. Second, an expired or revoked credential must be refused. For OAUTHBEARER, revoke or let a token expire at the identity provider and confirm the broker rejects the next connection. Third, a valid identity with no matching ACL must be denied. Under the StandardAuthorizer, resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true, so confirm that setting is false in your test cluster. Fourth, connect without credentials to a listener that requires SASL or TLS client authentication and confirm it refuses the connection. Fifth, perform a super user action such as creating an ACL, and confirm it appears in your audit log and reaches the reviewer you named.
Multi-site and identity provider outage tests. If you replicate with MirrorMaker 2, test failover with identities in place. Confirm that ACLs and consumer group offsets arrive at the secondary cluster as your design expects, and that a client authenticating against the secondary succeeds and is denied in the same way as on the primary. Then test the identity provider outage. Stop or block access to the OIDC provider or Kerberos key distribution center and confirm that new client connections fail rather than falling back to anonymous access, a weaker mechanism or a cached permissive state. Also confirm that existing connections behave as your design says. Record which of these outcomes you observe, because "fails closed" is a claim you must demonstrate.
Record the evidence. Each test needs a record with its ID, the cluster version, the configuration reference, the identity used, the expected and observed result, the timestamp, the person who ran it and the log excerpt that shows the decision. Store these with the configuration baseline so that an auditor can trace a result to a specific build. DeployOpen prepares test scripts, records and evidence packages that your independent auditor can examine. DeployOpen does not issue audit reports, attestations or certifications, and the auditor's opinion is what your compliance program relies on.
Confirm with your environment. Some details depend on your deployment and must be verified rather than assumed. Ask your identity team which token lifetimes, revocation methods and group claims apply. Ask your platform team which broker versions and Java runtime are in use, since the upgrade notes set minimum Java 17 for brokers. Confirm with your security team how long audit logs must be retained and who reviews super user activity. Agree these items with the people who own them before scheduling the test window.
What to monitor, rotate and document after Apache Kafka SSO goes live
Once SSO is live, the work shifts to proving it still behaves as designed. This sequence covers the monitoring, rotation, review and retesting that keep authentication and authorization correct over the life of the cluster.
Alert on authentication failures and denials
Your team forwards broker authentication logs and authorization denial events to the monitoring or SIEM platform you already run, then creates alert rules for spikes in failed SASL logins, rejected TLS handshakes and denied operations on sensitive topics. Start with the failure patterns you saw during the pilot so that a normal baseline is established before alerts are tuned. The step is complete when a test with a deliberately wrong credential produces a logged event and an alert that reaches the on-call channel, and the rule is stored in version control with an owner named.
Track credential and certificate expiry dates
Build an inventory of every credential the integration depends on: SCRAM user passwords, Kerberos keytabs and their service principals, broker and client certificates, and the signing keys or metadata endpoints your identity provider publishes for OAUTHBEARER. Record each item's owner, issuing system and expiry date, then schedule reminders well ahead of expiry in the team's calendar or ticketing system. Ask your identity and PKI teams to confirm which items they renew automatically and which need manual action. The inventory is the artifact that proves the step, and it should be reviewed whenever a credential is issued or retired.
Rotate SCRAM passwords, keytabs and certificates
Run rotation on a fixed schedule set by your security policy, covering SCRAM-SHA-256 or SCRAM-SHA-512 user credentials, Kerberos keytabs for GSSAPI, and broker and client certificates for mTLS. Rotate in an order that keeps existing connections working, typically by adding the new credential, updating clients, and then retiring the old one once no clients use it. Confirm the exact procedure for each mechanism with your Kafka and identity administrators before the first rotation. The step is complete when a dated rotation log records who rotated what, the verification performed, and the retirement of the old credential.
Review super users and ACL drift
On a fixed review cadence, compare the current super user membership and the ACL set in the cluster metadata against the approved access model. In KRaft clusters, the StandardAuthorizer stores ACLs in the metadata log, and resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true, so confirm that setting is still false during each review. Remove stale grants, document each exception with an owner and reason, and confirm that service accounts still map to the principals your identity provider issues. The review record, signed by the reviewer and the approver, is the artifact that proves the step.
Version control identity provider and principal mapping
Store the identity provider configuration, OIDC client settings, Kerberos realm and principal mapping rules, listener and SASL configuration, and ACL definitions in a version control repository with peer review on every change. Changes to the identity provider, such as a new client, key rotation or claim change, should trigger a pull request that links to the matching change ticket. Deploy from the repository rather than editing live configuration by hand, and keep a record of which commit is running in each environment. The repository history, with approved reviews, is the artifact that proves the configuration is controlled.
Retest authentication after each upgrade or change
Repeat the full authentication and authorization test set after each Kafka upgrade and after any change to the identity provider, certificate authority or Kerberos realm. The test set should cover every enabled mechanism, one successful and one failed login per client type, and a sample of allowed and denied topic operations. Kafka's upgrade notes and the time-based release plan define which versions can roll forward to which, so check compatibility before scheduling the change. The step is complete when the tested runbook is updated, the results are attached to the change record, and any failed case has an owner and a fix before the change is closed.
Questions teams ask before they hire help with Apache Kafka SSO
What drives the cost of Apache Kafka SSO integration work?
Cost follows the number of mechanisms, principals, environments and credentials you must manage. Each authentication path you enable, such as SASL/OAUTHBEARER with an OIDC provider, GSSAPI with Kerberos, SCRAM or mTLS, adds design, configuration and testing work. Each environment (development, test, production and disaster recovery) multiplies the testing effort. The number of principals and how they map to ACLs affects authorization design and review. Credential lifecycle matters most over time: rotation, revocation, expiry and certificate renewal are recurring tasks. One-time costs cover design, build, testing and runbooks. Recurring costs cover rotation, identity changes and checks during upgrades. When you request a quote, ask for line items by mechanism, environment and principal group.
How long does Kafka SSO integration usually take to deliver?
No single duration applies, because identity access and environment readiness set the timeline more than the Kafka configuration does. The main factors are how quickly your identity team grants access to the identity provider, whether a test tenant is available, how many environments need the change, how complex the principal-to-ACL mapping is, and how often your change windows open. Each delay in one of these inputs moves the schedule. DeployOpen works on fixed-scope engagements, so scope, deliverables and timelines are agreed in writing before work starts. Ask for the dependencies behind any proposed timeline, and confirm them with your identity and platform teams before you commit a date.
What must our team provide for a Kafka SSO project?
Four inputs carry most of the dependency risk: identity provider access, a test tenant, named owners and change windows. Identity provider access means the rights to register clients, define scopes or claims, or manage the Kerberos or certificate authority that the design uses. A test tenant lets the team validate tokens, tickets or certificates without touching production identities. Named owners for ACLs and credentials should be people who can approve principal mappings and sign off on rotation schedules. Change windows should be booked in advance for each environment, including any broker restarts needed to load new listener settings. Also prepare a test Kafka cluster that matches production listener layout, so testing reflects real configuration.
Can our internal team build Kafka SSO integration without outside help?
A team with working knowledge of Kafka security configuration, identity protocols and ACL design can build the integration alone. The work requires familiarity with Kafka listeners, SASL mechanisms, the StandardAuthorizer and the identity system you already run. Outside help usually adds value in three places: choosing the mechanism that fits your identity estate, reviewing the authorization model so that resources without an ACL stay restricted, and building a repeatable test harness across environments. An outside team can also plan cutover and document runbooks for rotation and incident response. Your internal team can decide how much of that to buy, and a fixed-scope quote should list the deliverables separately so you can compare the options.
Does Apache Kafka charge a license fee for SSO support?
Apache Kafka is licensed under the Apache License 2.0, and the project itself offers no paid edition. SSO support is part of the open-source software, so there is no license fee for enabling SASL or SSL authentication. Your costs sit in engineering time, operations, and identity tooling you may already own. Confirm with your identity provider vendor whether the OIDC or Kerberos features you plan to use are included in your current license tier, since that is set by the vendor, not by Kafka. If you buy a support agreement or outside implementation work, that is a separate cost and should appear as its own line in the quote.
Which Apache Kafka version should we confirm before starting SSO work?
Confirm your target release on the Apache Kafka downloads page before scoping the work. The page lists 4.3.1 (June 25, 2026), 4.2.2 (September 29, 2026) and 4.1.2 (March 17, 2026) as supported releases, and earlier versions are archived. The project supports rolling upgrades from each release in the past year to the latest version, so confirm your current version falls inside that window. If you run a ZooKeeper-based cluster, you must migrate to KRaft before moving to 4.x, and Kafka's upgrade notes recommend upgrading KRaft clusters older than 3.3.x to 3.9.x before moving to 4.x. Kafka 4.0 and later require Java 17 for brokers, Kafka Connect and tools, so confirm your JVM version too.
Which SASL mechanism should we choose for Kafka: OAUTHBEARER, GSSAPI or SCRAM?
Choose the mechanism that matches the identity system you already operate and can staff. SASL/OAUTHBEARER with an OIDC provider fits organizations that centralize identity and want tokens issued and expired by one system. GSSAPI fits environments that already run Kerberos, usually through Active Directory. SCRAM-SHA-256 or SCRAM-SHA-512 stores credentials in Kafka itself, which keeps the design simpler but adds a credential rotation process you must own. Mutual TLS ties identity to certificates, so it depends on a certificate authority and renewal process. Whichever you pick, map each principal to ACLs explicitly. Under the StandardAuthorizer, resources without ACLs are limited to super users unless allow.everyone.if.no.acl.found is set to true, so confirm that setting in your design.
How DeployOpen scopes, builds and hands over Apache Kafka identity integration
DeployOpen plans and implements Apache Kafka identity integration inside your own infrastructure, tying client, broker and tool authentication to the identity systems you already run. Each engagement starts from a written, fixed scope that names the mechanisms, principals and ACL model in use, so your security and platform teams know what will be delivered before work begins.
How we scope
- Inventory which clients, brokers, Connect workers and admin tools need authentication, and which listeners stay unsecured.
- Choose between OAUTHBEARER with an OIDC provider, GSSAPI, SCRAM and mTLS for each client group and document the reasons.
- Define the principal naming model and how identities from your directory map to Kafka ACLs before any configuration is written.
How we build
- Configure SASL listeners and TLS on KRaft clusters, then test each mechanism with representative producer and consumer clients.
- Load ACLs into the StandardAuthorizer metadata log with deny-by-default behavior and confirm super user membership is limited to named accounts.
- Check the authorization path against sample principals, including denied cases, and record the results alongside the configuration.
How we hand over
- Deliver runbooks covering credential rotation, certificate renewal, identity provider changes and adding new principals to ACLs.
- Document every listener, mechanism, principal mapping and ACL rule so your team can audit and reproduce the configuration.
- Walk your operators through failure cases such as expired tokens, Kerberos clock skew and rejected ACL requests before closing the engagement.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope engagement ends.
- Retest identity paths when Kafka releases change client or broker behavior, so supported versions stay within the agreed design.
- Confirm with your identity team and your Kafka release plan which support scope and response expectations apply to your environment.
