kafka sink: Sarama GSSAPI fails with Kafka 3.x and 4.x

Summary

TiCDC Kafka sink GSSAPI authentication fails against Kafka 3.x and 4.x. The failure originates in the GSSAPI connection path of the Sarama client used by TiCDC.

All current GSSAPI combinations are affected:

ACL-enabled cases also fail during authentication, before authorization starts.

Failure sequence

Sarama -> Kafka: ApiVersionsRequest
Sarama -> Kafka: raw Kerberos token (legacy SASL v0)
Kafka 3.x/4.x: rejects the token as an invalid Kafka request

Kafka reports errors similar to:

InvalidRequestException: Error parsing request header. Our best guess of the apiKeyId is: 24706
Unexpected api key: 24706

Root cause in Sarama

TiCDC depends on IBM/sarama v1.41.2 through github.com/pingcap/sarama v1.41.2-pingcap-20260622.1.

Sarama defaults Net.SASL.Version to SASLHandshakeV1, then broker.go forces every GSSAPI connection to use SASL v0:

useSaslV0 := conf.Net.SASL.Version == SASLHandshakeV0 ||
    conf.Net.SASL.Mechanism == SASLTypeGSSAPI

The SASLTypeGSSAPI condition bypasses the versioned SaslHandshake and SaslAuthenticate path. Sarama writes the Kerberos token directly to the broker connection.

Why both Kafka 3.x and 4.x fail

• Kafka 3.x: the broker accepts a legacy raw GSSAPI token only as the first packet. Sarama has already sent ApiVersionsRequest, so the broker expects SaslHandshake and parses the raw token as a Kafka request.
• Kafka 4.x: KIP-896 removed the legacy raw SASL path completely.