Repository navigation
fix(OMN-14155): wire MSK-IAM auth kwargs into remaining direct aiokafka construction sites - #2238
Conversation
…ka construction sites OMN-2793 built the MSK-IAM OAUTHBEARER foundation (kafka_auth.py, ModelKafkaEventBusConfig, 8 call sites) but ~14 other direct AIOKafkaConsumer/AIOKafkaProducer construction sites bypassed it and passed only bootstrap_servers= (implicit PLAINTEXT). Several are docker-catalog-deployed cloud runtime containers (context-audit, llm-cost-aggregation, skill-lifecycle, agent-actions, infra-routing-decisions, consumer-health-projection, injection-effectiveness, waitlist-signup-notifier, plus the registration-orchestrator snapshot producer) that would fail the SASL handshake outright once the cloud dev broker is cut over to KAFKA_SASL_MECHANISM=AWS_MSK_IAM. Spread the existing build_aiokafka_auth_kwargs_from_env() helper into every remaining site (no-op today under PLAINTEXT; becomes load-bearing once the Infisical cloud-k8s secrets flip). Adds an AST-based CI regression guard (tests/ci/test_no_raw_aiokafka_construction_without_auth.py) so a new direct construction site can't silently skip auth kwargs again, with a documented allowlist for cli_kafka.py (explicit V2 SASL/TLS deferral, pre-existing). Design: docs/plans/2026-07-08-runtime-msk-iam-oauthbearer-design.md Closes OMN-14155
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 3 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (19)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Evidence-Source: OCC#3743
Evidence-Ticket: OMN-14155
Summary
kafka_auth.py,ModelKafkaEventBusConfig, 8 call sites already correctly spreadbuild_aiokafka_auth_kwargs_from_env()), and the CORE runtime bus (EventBusKafkaviabackends/auto_configure.py) is already fully wired via env-var overrides — zero code change needed there.AIOKafkaConsumer(/AIOKafkaProducer(construction sites bypassedkafka_auth.pyentirely, passing onlybootstrap_servers=(implicit PLAINTEXT). Several are docker-catalog-DEPLOYED cloud runtime containers (context-audit, llm-cost-aggregation, skill-lifecycle, agent-actions, infra-routing-decisions, consumer-health-projection, injection-effectiveness, waitlist-signup-notifier, plus the registration-orchestrator snapshot producer) that would fail the SASL handshake outright once the broker flips toKAFKA_SASL_MECHANISM=AWS_MSK_IAM.build_aiokafka_auth_kwargs_from_env()helper into every remaining site. It is a no-op today (returns{}under PLAINTEXT) and becomes load-bearing only once the Infisical cloud-k8s secrets are cut over (separate, config-only step — see design doc).tests/ci/test_no_raw_aiokafka_construction_without_auth.py) so a future direct construction site can't silently skip auth kwargs, with a documented allowlist forcli_kafka.py(pre-existing, self-documented V2 SASL/TLS deferral).Design doc:
docs/plans/2026-07-08-runtime-msk-iam-oauthbearer-design.mdCloses OMN-14155 (parent epic OMN-12986, Done)
Risk flagged (not a code blocker — verify before cutover)
MSKTokenProviderresolves AWS credentials via the default botocore chain (EC2 IMDS for the instance-profile role). This same k3s cluster previously had pod-level IMDS reachability broken by an IMDSv2 hop-limit issue (root cause of the recurring ECR-token-refresh outage, OMN-13749/13818/13819) that may not survive node replacement. Verifyaws sts get-caller-identitysucceeds from a live onex-dev pod before flipping the Infisical secrets — documented in the design doc §6.Test plan
tests/unit/event_bus/test_msk_auth_direct_clients.py— existing MSK auth coverage, unaffected, passestests/ci/test_no_raw_aiokafka_construction_without_auth.py) — both the main invariant test and the anti-permanence allowlist-staleness testruff format --check/ruff checkclean on all touched filesmypyclean on all touched filespre-commit run --files <touched>— full hook suite greengh pr checks) — verifying after push