Skippr Docs

Appearance

How Kafka Source Authentication Works in Skippr ​

June 2026

Kafka source authentication can be as simple as no credentials on a local broker or as strict as SASL over a secured cluster, but in both cases the topic and consumer-group permissions still decide whether the source is usable.

Short Answer ​

Kafka source authentication in Skippr is either no-auth local broker access or broker-level security settings supplied directly in the source config. For secured clusters, the important fields are security_protocol, sasl_mechanism, sasl_username, and sasl_password, with the sensitive values usually coming from environment variables such as KAFKA_SASL_USERNAME and KAFKA_SASL_PASSWORD.

That auth model only becomes useful when it matches the consumption contract. A source pointing at brokers broker1:9092,broker2:9092, topic events, and group skippr-consumer still needs ACLs that allow topic reads and consumer-group commits. On a Debezium CDC topic, the same authenticated consumer is also carrying a stricter payload contract than a generic event stream.

Why Teams Struggle with This ​

Kafka makes it easy to blur authentication and consumption behavior together. The docs separate them: broker security is one concern, but the runner also has to reach the brokers, join the configured group, and read the selected topic. If any of those are wrong, the source feels unauthenticated even when the SASL secret itself is valid.

  • Local development can be unauthenticated, while production often needs explicit security_protocol and SASL settings.
  • SASL credentials should be interpolated from environment variables rather than committed into the source config.
  • Broker ACLs need to cover both topic consumption and consumer-group commit behavior.
  • A CDC topic authenticated correctly can still be the wrong source if it does not contain the Debezium envelopes the docs expect for CDC mode.

How Skippr Handles It ​

Skippr keeps the Kafka auth model transparent because the security fields sit right next to the topic and group settings they affect. That helps during review: you can see whether the connector is unauthenticated local development, SASL-secured production, or something in between.

It also helps during incidents. If the consumer stops moving, the checklist stays concrete: broker reachability, security protocol, SASL values, topic ACLs, and group ACLs. You do not need to reverse-engineer a hidden auth layer to understand why the pipeline cannot consume.

  • Direct support for unauthenticated development clusters and SASL-secured Kafka brokers.
  • Environment-backed SASL credentials through ${KAFKA_SASL_USERNAME} and ${KAFKA_SASL_PASSWORD}.
  • A source contract that explicitly includes brokers, topic, group ID, and offset behavior alongside auth settings.
  • Documented compatibility with Debezium-based CDC when the topic payload matches that model.

What the First Useful Version Looks Like ​

The first useful version is one topic, one dedicated group ID, and one confirmed security profile. That makes restart behavior and ACL troubleshooting much easier to interpret.

If the team cannot yet say whether the topic is a generic event feed or a Debezium CDC feed, answer that before widening the source. Authentication is only half of the Kafka contract.