Redpanda Cloud has separate auth planes: OAuth2 for control plane, SCRAM for Kafka

TL;DR

Do not mix the two auth planes: OAuth2 client credentials with the cloudv2-production.redpanda.cloud audience are for the control plane API; SASL/SCRAM username and password are for the Kafka data plane.

Fix

1. Do not mix the two auth planes: OAuth2 client credentials with the cloudv2-production.redpanda.cloud audience are for the control plane API; SASL/SCRAM username and password are for the Kafka data plane. Expected: you can confirm this matches your situation.

When to use

• You are setting up or using this Redpanda Cloud has separate auth planes feature.
• The symptom matches: OAuth2 for control plane, SCRAM for Kafka.

When NOT to use

• Unrelated Redpanda Cloud has separate auth planes issues (different feature, different failure).
• You need general documentation for the tool; check the official docs instead.

Compatibility

Reported against Redpanda Cloud has separate auth planes.

Variant phrasings

OAuth2 for control plane, SCRAM for Kafka

Why it happens

Official docs (redpanda-data/skills, cloud-dedicated skill): documents the two-plane auth gotcha that trips agents automating Redpanda Cloud. The control plane uses OAuth2 client credentials: create a client ID and secret in the Cloud console (Clients tab under Users), then request a token with granttype=clientcredentials and audience=cloudv2-production.redpanda.cloud, passing it as a Bearer token on every API call. The data plane (Kafka) uses separate SASL/SCRAM credentials. Serverless clusters are also managed through a separate ServerlessClusterService API, not the ClusterService used for Dedicated/BYOC.

Edge cases

• If your error message differs even slightly, this is probably a different issue; search the exact text.
• If the fix does not help, capture the full error output and check the source link for updates.

Source: Official docs (redpanda-data/skills, cloud-dedicated skill): documents the two-plane auth gotcha that trips agents automating Redpanda Cloud. The control plane uses OAuth2 client credentials: create a client ID and secret in the Cloud console (Clients tab under Users), then request a token with granttype=clientcredentials and audience=cloudv2-production.redpanda.cloud, passing it as a Bearer token on every API call. The data plane (Kafka) uses separate SASL/SCRAM credentials. Serverless clusters are also managed through a separate ServerlessClusterService API, not the ClusterService used for Dedicated/BYOC.

Verified resolution: Do not mix the two auth planes: OAuth2 client credentials with the cloudv2-production.redpanda.cloud audience are for the control plane API; SASL/SCRAM username and password are for the Kafka data plane. Create the OAuth client in the console's Clients tab, cache the token, and send it as a Bearer token. If your automation targets a Serverless cluster, call the ServerlessClusterService API, not ClusterService; the wrong service returns nothing useful. With rpk, rpk cloud login --client-id ... --client-secret ... --save handles this.

Source URL: https://github.com/redpanda-data/skills/blob/HEAD/skills/cloud-dedicated/SKILL.md