Skippr Docs

Appearance

What Access Skippr Needs to Read from Kafka ​

June 2026

Kafka access is not just broker reachability; Skippr also needs a usable consumer identity and the right topic ACLs.

Short Answer ​

Skippr needs network access to the bootstrap brokers, permission to read the selected topic, and the ability to join the configured consumer group and commit offsets. On secured clusters, that usually means the SASL settings are correct and broker ACLs allow both topic consumption and group commits, not just one of those pieces.

If you use Kafka for CDC, Skippr also expects Debezium-formatted messages on the topic. A topic such as dbserver1.public.customers works well when a Debezium connector is already publishing envelopes with op, before, and after fields and the consumer group has stable access to keep resuming from committed offsets.

Why Teams Struggle with This ​

Kafka access problems often hide behind connectivity tests. Teams prove they can reach a broker, then discover the group cannot commit offsets or the topic payload is not actually a Debezium CDC stream even though it looks like JSON on inspection.

  • The runner must reach the bootstrap brokers from the network where Skippr executes.
  • ACLs need to cover reading the topic and committing offsets for the consumer group.
  • If the cluster uses SASL, the security protocol, mechanism, username, and password all have to match the broker policy.
  • CDC is a message-shape contract as well as an access contract, so plain event JSON is not interchangeable with Debezium envelopes.

How Skippr Handles It ​

Skippr exposes the Kafka fields operators already care about: brokers, topic, group ID, offset reset policy, mode, and optional SASL settings. That keeps access review practical because you can compare the connector config directly against the platform team documentation and ACL policy.

The CDC story stays equally explicit. When cdc_enabled is on, Skippr parses Debezium envelopes and relies on Kafka consumer-group offsets for durable resume, so the right topic and a stable group ID matter as much as the broker credentials.

  • Consumes from one named topic through one explicit broker list.
  • Supports secured clusters through security protocol and SASL settings.
  • Uses Kafka consumer-group offset tracking for durable resume.
  • Parses Debezium envelopes when Kafka is being used as a CDC source.

What the First Useful Version Looks Like ​

The first useful version is one topic, one stable group ID, and one access policy that lets Skippr consume and commit offsets without special-case manual fixes.

If that run is clean, you can decide whether the topic is just a general event feed or a real CDC contract that deserves a final-state warehouse destination.