feat: add Kafka user password configuration solution#142
Conversation
Document the end-to-end flow for configuring a custom SCRAM-SHA-512 password on an RdsKafkaUser and rotating it via the changePasswordTimestamp annotation. Includes an OCP / AMQ Streams parity section for migration. Verified on ACP 4.2.x with rds-operator v4.2.0 and Kafka 4.1.1.
sinbadonline
had a problem deploying
to
translate
GitHub Actions
Failure
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 49 minutes and 31 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughAdded a new documentation page that explains how to configure SCRAM-SHA-512 passwords for an ACP Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
sinbadonline
had a problem deploying
to
translate
GitHub Actions
Failure
sinbadonline
had a problem deploying
to
translate
GitHub Actions
Failure
…ord-configuration
The Confluence source said "3.15增加配置密码功能" but rds-operator
rdskafkauser_types.go at tag v3.15.10 (last v3.15.x patch,
2023-12-25) has no Password field. The commit adding the field
(e289ccab "MIDDLEWARE-18371 add kafka admin and kafkauser set
password") landed on 2024-01-31, and the earliest tag containing
the field is v3.16.0.
Fix conflicting claims ("ACP 3.15" in Background vs "rds-operator
3.15" in Applicable Version) by removing the unverified ACP version
claim and pinning to the verifiable rds-operator version.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
docs/en/solutions/Kafka_User_Password_Configuration.md (1)
50-52: Clarify the base64 encoding comment.The comment on line 50 states
# base64 of 'Passw0rd123!'immediately before akubectl create secret --from-literalcommand. This placement may confuse readers because--from-literalautomatically base64-encodes the value; users should NOT pre-encode the password when using this flag.📝 Suggested clarification
-# base64 of 'Passw0rd123!' kubectl -n <ns> create secret generic my-user-password \ --from-literal=password='Passw0rd123!'Or make the comment more explicit:
-# base64 of 'Passw0rd123!' +# kubectl handles base64 encoding automatically with --from-literal kubectl -n <ns> create secret generic my-user-password \ --from-literal=password='Passw0rd123!'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/en/solutions/Kafka_User_Password_Configuration.md` around lines 50 - 52, The comment "# base64 of 'Passw0rd123!'" is misleading next to the kubectl command; update the comment near the kubectl -n <ns> create secret generic my-user-password --from-literal=password='Passw0rd123!' to explicitly state that --from-literal accepts a plaintext value and kubectl will handle base64 encoding, and remove any instruction that suggests pre-encoding the password so users do not base64-encode before using --from-literal.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@docs/en/solutions/Kafka_User_Password_Configuration.md`:
- Around line 50-52: The comment "# base64 of 'Passw0rd123!'" is misleading next
to the kubectl command; update the comment near the kubectl -n <ns> create
secret generic my-user-password --from-literal=password='Passw0rd123!' to
explicitly state that --from-literal accepts a plaintext value and kubectl will
handle base64 encoding, and remove any instruction that suggests pre-encoding
the password so users do not base64-encode before using --from-literal.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 691be8a5-b2d9-4eda-beac-f2c2f77ba740
📒 Files selected for processing (1)
docs/en/solutions/Kafka_User_Password_Configuration.md
Fixes from review of PR #142: - Correct the ACL-shape row in the OCP Parity table. Strimzi v1beta2 accepts both `acls[*].operation` (singular, deprecated) and `acls[*].operations` (plural array) — not either/or as previously implied. Same `resource` sub-fields in both. - Correct the rotation trigger row. Upstream Strimzi User Operator watches the referenced source Secret natively; the no-op annotation dance is not a workaround users need to know about. - Add a Supported `authentication.type` row surfacing that upstream Strimzi supports `tls-external` which RdsKafkaUser does not — a real migration gap for OCP users of that type. - Drop the `resource.{name,patternType,type}` vs `resource.{type,name,patternType}` "difference" — the fields are identical, only the listing order differed. - Broaden Notes on `tls-external` migration implication. - Add a Prerequisites clarification that SCRAM auth can live on any listener (plain/tls/external), not only the one shown. - Add a brief note after Step 3 explaining why RdsKafkaUser uses `status.phase` while the downstream KafkaUser uses `status.conditions`. - Add a new Step 5 "Remove the user" covering delete + GC behavior. Kafka 4.1.1 version claim in Applicable Version is now runtime-verified via `kafka-topics.sh --version` against the kafka-4-1-x:v4.2.0 image.
|
/lgtm |
2 participants
Summary
docs/en/solutions/Kafka_User_Password_Configuration.mdcovering the end-to-end flow for configuring a custom SCRAM-SHA-512 password on anRdsKafkaUserand rotating it via thechangePasswordTimestampannotation.RdsKafkaUserto upstream Strimzi / Red Hat AMQ StreamsKafkaUser, with a field-by-field migration table.Source of truth
rds-operatorsource (middleware/rds-operator) — verifiedRdsKafkaUserSpecshape, thecopier.Copyreconcile to downstream StrimziKafkaUser, andchangePasswordTimestamphandling.KafkaUser 支持配置密码(ID 184353383) — used as the starting point; the YAML example in that page has known errors (useskind: KafkaUser+strimzi.io/clusterlabel), which are corrected here.Verification
End-to-end validated on ACP 4.2.x (rds-operator
v4.2.0, Kafka4.1.1):RdsKafka(1 controller+broker, KRaft mode) withlisteners.plain.authentication.type: scram-sha-512andauthorization.type: simple.Secret+RdsKafkaUser; confirmedstatus.phase=Active, downstreamKafkaUserReady=True, and the auto-publishedsasl.jaas.configSecretcontained the custom password.Jobthat exercised four scenarios:SaslAuthenticationExceptionchangePasswordTimestampannotation bumped) — list topics succeedSaslAuthenticationExceptionRotation reconcile completed within ~10 seconds.
Test plan
docs/en/solutions/conventions.🤖 Generated with Claude Code
Summary by CodeRabbit