kafka: decouple security SASL types from Sarama

[3AceShowHand]

What problem does this PR solve?

Issue Number: close #5892

Kafka SASL configuration and SCRAM authentication were owned by pkg/security. The configuration model also derived protocol values from Sarama, coupling Kafka-independent security code and Kafka configuration parsing to a specific Kafka client.

What is changed and how it works?

• Move the SASL configuration model, mechanism parsing, GSSAPI authentication types, and OAuth2 validation into pkg/sink/kafka.
• Keep the SASL model private to the Kafka package so it does not become a shared repository API.
• Move the XDG SCRAM client and SHA-256/SHA-512 hash generators from pkg/security into pkg/sink/kafka as private implementation details.
• Remove Kafka SASL and SCRAM ownership from pkg/security.
• Define stable Kafka protocol values directly:
  • SASL mechanisms: PLAIN, SCRAM-SHA-256, SCRAM-SHA-512, GSSAPI, and OAUTHBEARER.
  • GSSAPI authentication types: unknown=0, user=1, and keytab=2.
• Keep Sarama-specific type conversion and interfaces at the Kafka client adapter boundary.
• Generate invalid SASL, GSSAPI, and OAuth2 configuration errors directly as ErrKafkaInvalidConfig errors without intermediate generic errors or duplicate wrapping.
• Preserve existing URI and TOML configuration keys, case-insensitive parsing, normalized protocol values, and authentication behavior.

Check List

Tests

• Unit test
  • go test ./pkg/security ./pkg/sink/kafka
  • go test -race -tags=intest ./pkg/security ./pkg/sink/kafka
  • go test -tags=intest ./downstreamadapter/sink/kafka ./downstreamadapter/sink/topicmanager
• Other checks
  • git diff --check

Questions

Will it cause performance regression or break compatibility?

No performance regression is expected. SASL parsing and validation run while creating or verifying a Kafka sink, not on the message production path.

Existing configuration keys, accepted values, case-insensitive parsing, and authentication behavior remain compatible. Invalid configuration errors now consistently use the CDC:ErrKafkaInvalidConfig RFC code.

Do you need to update user documentation, design documentation or monitoring documentation?

No. This refactor does not change user-facing configuration or monitoring behavior.

Release note

None

Summary by CodeRabbit

• New Features

  • Kafka sink SASL authentication supports PLAIN, SCRAM-SHA-256, SCRAM-SHA-512, GSSAPI, and OAUTHBEARER.
  • OAuth2 authentication supports client credentials, scopes, grant types, audiences, and token endpoint settings.
  • Added validation and clearer errors for invalid SASL, OAuth2, and GSSAPI configurations.

• Refactor

  • Kafka authentication configuration is now managed within the Kafka sink while preserving supported authentication behavior.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: c0869936-26b2-4ab7-af51-f194307bdbcb

📥 Commits

Reviewing files that changed from the base of the PR and between 0c7fc18 and 12be7dd.

📒 Files selected for processing (2)

• pkg/sink/kafka/sarama_config_test.go
• pkg/sink/kafka/scram_client_test.go

---

📝 Walkthrough

Walkthrough

Changes

The Kafka sink now owns internal SASL, OAuth2, GSSAPI, and SCRAM configuration types. The exported security SASL definitions were removed. Kafka options, Sarama integration, OAuth2 token provisioning, and tests now use the internal types and local parsers.

Kafka SASL decoupling

Layer / File(s)	Summary
Internal SASL contracts and validation pkg/sink/kafka/sasl_config.go, pkg/sink/kafka/sasl_config_test.go, pkg/security/sasl.go	Kafka defines local SASL mechanisms, OAuth2 settings, GSSAPI authentication types, and parsing validation. The former security SASL declarations are removed.
Kafka options and OAuth2 wiring pkg/sink/kafka/options.go, pkg/sink/kafka/options_test.go, pkg/sink/kafka/oauth2_token_provider.go, pkg/sink/kafka/oauth2_token_provider_test.go	Kafka options store nested internal SASL configuration. OAuth2 values are validated and passed to token provisioning through the new structure.
Sarama integration and SCRAM client pkg/sink/kafka/sarama_config.go, pkg/sink/kafka/sarama_config_test.go, pkg/sink/kafka/scram_client.go, pkg/sink/kafka/scram_client_test.go	Sarama conversion uses local SASL values and package-local SCRAM implementations. Tests cover SASL completion and SCRAM handshakes.

Estimated code review effort: 4 (Complex) | ~45 minutes

Possibly related PRs

• pingcap/ticdc#5786: Modifies Kafka SASL configuration and error handling in related Kafka code.
• pingcap/ticdc#5874: Modifies Kafka SASL and OAuth configuration in the same integration paths.

Suggested labels: lgtm, approved

Suggested reviewers: asddongmen, lidezhu, wk989898

Poem

A rabbit tends the Kafka stream,
With local SASL in every seam.
SCRAM handshakes hop and sing,
OAuth tokens take to wing.
Sarama maps the final way.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly states the main change: decoupling Kafka SASL types from Sarama.
Description check	✅ Passed	The description includes the issue, implementation details, tests, compatibility answers, documentation assessment, and release note.
Linked Issues check	✅ Passed	The changes satisfy issue #5892 by moving private SASL types, preserving stable values and parsing, isolating Sarama conversion, and expanding coverage.
Out of Scope Changes check	✅ Passed	All reported code and test changes support the stated Kafka SASL decoupling objectives, with no unrelated scope identified.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[3AceShowHand]

/test all

[3AceShowHand]

/test pull-error-log-review

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lidezhu, wk989898

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [lidezhu,wk989898]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2026-08-12 08:35:46.171430032 +0000 UTC m=+3208332.207525088: ☑️ agreed by lidezhu.
• 2026-08-12 11:35:55.811225303 +0000 UTC m=+3219141.847320349: ☑️ agreed by wk989898.