rpadmin: add OAUTHBEARER auth option for debug bundle#165
Merged
Conversation
Add WithOAuthBearerAuthentication(token) so callers can forward an
OIDC bearer token to the broker's /v1/debug/bundle endpoint. The
existing WithSCRAMAuthentication option only covers SCRAM profiles,
which leaves rpk with no way to express OAUTHBEARER credentials to
the broker-side rpk subprocess.
The new payload is {"mechanism":"OAUTHBEARER","token":"<JWT>"}, sent
as a peer variant of the existing SCRAM payload on the same
Authentication field. Also export an OAuthBearer constant alongside
ScramSha256/ScramSha512/CloudOIDC.
Broker-side support for this payload is a separate change in
redpanda.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
This was referenced Apr 17, 2026
gosec G117 flags fields named "Password"/"Pass", not generic token fields, so the nolint directive copied from the SCRAM password field is inert and trips nolintlint. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
10 tasks
c-julin
approved these changes
Apr 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
WithOAuthBearerAuthentication(token string)so callers can forward an OIDC bearer token to the broker's/v1/debug/bundleendpoint. The existingWithSCRAMAuthenticationonly covers SCRAM profiles, leaving rpk with no way to express OAUTHBEARER credentials to the broker-side rpk subprocess.debugBundleOAuthBearerAuthentication { mechanism, token }— sent as{\"mechanism\":\"OAUTHBEARER\",\"token\":\"<JWT>\"}on the sameauthenticationfield as the existing SCRAM payload.OAuthBearer = \"OAUTHBEARER\"constant alongsideScramSha256/ScramSha512/CloudOIDC.Motivation
Follow-up on review feedback in redpanda#30169, which adds OAUTHBEARER to rpk's Kafka/admin/Schema Registry clients. In that PR, `rpk debug remote-bundle start` silently drops auth for OAUTHBEARER profiles (via `HasSASLCredentials()`, which requires both user and password), so requests go to the broker with no auth and fail confusingly on secured clusters.
That PR lands a short-term guard that rejects OAUTHBEARER for remote debug bundle up front with a clear error. This PR unblocks the end-to-end fix by adding the client-side option; the broker-side JSON parser and subprocess arg builder still need to accept the new payload ([tracked in a separate redpanda issue]).
Test plan
🤖 Generated with Claude Code