Manage Access to Lightning Tables in Confluent Cloud

You control access to Lightning Tables through Confluent Cloud role-based access control (RBAC) and authentication credentials. You use Confluent Cloud roles to control who can enable Lightning Tables and who can query data.

Roles and permissions

You need different permissions for managing Lightning Tables and querying data.

Managing Lightning Tables

Managing Lightning Tables includes enabling and disabling a Lightning Table for a topic and editing its table description. You need one of the following roles to manage Lightning Tables:

  • OrganizationAdmin

  • EnvironmentAdmin

  • CloudClusterAdmin

  • ResourceOwner on the topic

The OrganizationAdmin, EnvironmentAdmin, and CloudClusterAdmin roles also grant permission to query data.

Querying data with MCP

Querying data through the Real-Time Context Engine Model Context Protocol (MCP) tools includes listing topics, running queries, and retrieving topic metadata. The following table shows which of these MCP operations each role can perform.

Role

Scope

List topics

Query data

Get metadata

OrganizationAdmin

Organization

Yes

Yes

Yes

EnvironmentAdmin

Environment

Yes

Yes

Yes

CloudClusterAdmin

Cluster

Yes

Yes

Yes

DeveloperRead

Cluster

Yes

Yes

Yes

DeveloperRead

Topic

No

Yes

No

DeveloperRead

Schema Registry cluster

Yes

No

Yes

ResourceOwner

Topic

Yes

No

No

OrganizationOperator

Organization

Yes

No

No

EnvironmentOperator

Environment

Yes

No

No

CloudClusterOperator

Cluster

Yes

No

No

DeveloperManage

Cluster

Yes

No

No

These operations correspond to the following MCP tools:

  • List topics: listTopics

  • Query data: queryData

  • Get metadata: getMetadata

You can query data only from topics that you already have permission to read in Apache Kafka®.

Authentication

You can authenticate in the following ways:

  • Use a Global API key with HTTP Basic authentication. You can use a Global API key with the API, MCP clients, and the Java Database Connectivity (JDBC) driver.

  • Sign in with your Confluent Cloud account. You can sign in with the Confluent CLI and with MCP clients, and queries run with your own roles.

  • Use OAuth with an identity provider. Your MCP client gets a bearer token from an identity provider that you configure in Confluent Cloud.

Use a Global API key

You can use a Global API key to query Lightning Tables through the API, MCP, or JDBC with HTTP Basic authentication. You can use a Global API key both to manage Lightning Tables and to query data. It works on all supported cluster types, including Basic and Standard clusters.

If you only need to manage Lightning Tables, you can use a Cloud API key instead of a Global API key.

Create a Global API key

A Global API key grants access across Confluent Cloud resources with a single credential. For more information, see Global API keys.

To create a Global API key, use one of the following methods.

  1. Sign in to the Confluent Cloud Console at https://confluent.cloud/.

  2. Open the Administration menu.

  3. Select API keys.

  4. Click + Add API key.

  5. For Name, enter a name for the API key.

  6. Optionally, for Description, enter a description.

  7. Under Select account, select My account.

  8. Under Select key scope, select Global.

  9. Click Create API key.

  10. Download or copy the API key and secret. After you close the dialog, the secret is no longer available.

Run the following command to create a Global API key for a service account.

confluent api-key create \
  --resource global \
  --service-account <service_account_id> \
  --description "Global API key for Lightning Tables"

Save the API key and secret that the command returns. The secret isn’t displayed again.

Send a POST request to create a Global API key.

curl -X POST "https://api.confluent.cloud/iam/v2/api-keys" \
  -H "Authorization: Bearer $AUTH_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "spec": {
      "display_name": "my-global-key",
      "description": "Global API key for Lightning Tables",
      "owner": {"id": "<service_account_id>"},
      "resource": {"id": "global"}
    }
  }'

Save the API key and secret from the response. You can’t retrieve the secret after the initial response.

Generate the Base64 token

The API and the Real-Time Context Engine MCP server use HTTP Basic authentication, which requires a Base64-encoded token. The JDBC driver takes the API key and secret directly, so it doesn’t need a token.

To generate the token, set your API key and secret as environment variables. Then encode them, like the following example:

export KEY=<api_key>
export SECRET=<api_secret>
export TOKEN=$(echo -n "${KEY}:${SECRET}" | base64 | tr -d '\n')
echo $TOKEN

Use the resulting token in the Authorization header of each request:

Authorization: Basic <token>

Sign in to an MCP client with your Confluent Cloud account

You can connect to the Real-Time Context Engine MCP server by signing in with your Confluent Cloud user account instead of using an API key. Your MCP client opens a browser to the Confluent Cloud sign-in page. After you sign in, queries run with your user account’s roles, as shown in the table in Roles and permissions.

Your MCP client must use the client ID that Confluent registered for it. For the list of client IDs, see Confluent Cloud account sign-in (OAuth). For help with common sign-in problems, see Troubleshooting for the managed MCP servers.

The following example command registers the server in Claude Code with confluent-rtce as the server name:

claude mcp add --transport http --client-id claude-cli confluent-rtce \
  "https://mcp.<region>.aws.confluent.cloud/mcp/v1/context-engine/organizations/<org_id>/environments/<env_id>/kafka-clusters/<lkc_id>"

Replace the following values:

  • <region>: The AWS region of your cluster, for example us-east-1.

  • <org_id>: Your Confluent Cloud organization ID.

  • <env_id>: Your Confluent Cloud environment ID.

  • <lkc_id>: Your Kafka cluster ID.

To sign in from Claude Code, complete the following steps:

  1. Run /mcp.

  2. Select confluent-rtce.

  3. Select Authenticate.

  4. In the browser window that opens, sign in to Confluent Cloud.

For other MCP clients, configure the same server URL with http transport and the client ID for your client. Don’t add an Authorization header or a Confluent-Identity-Pool-Id header.

Sign in with the Confluent CLI

To query a Lightning Table with the confluent lightning query command, sign in to the Confluent CLI with your Confluent Cloud user account. Run the confluent login command. Then sign in with a username and password or with single sign-on (SSO). The confluent lightning query command runs queries with your own roles. It doesn’t support signing in with an API key.

For more information, see Query a Lightning Table with the Confluent CLI in Confluent Cloud.

Use OAuth with an identity provider

You can authenticate with the Real-Time Context Engine MCP server by using OAuth 2.0 with the client credentials flow. With OAuth, your MCP client authenticates with an identity provider instead of using a static API key.

Prerequisites

Before you begin, make sure that you have the following:

  • An OAuth identity provider configured in Confluent Cloud. For setup instructions, see Add an identity provider.

  • An identity pool created for the identity provider. For setup instructions, see Add an identity pool.

  • The DeveloperRead role granted to the identity pool on the Kafka cluster.

  • The DeveloperRead role granted to the identity pool on the Schema Registry cluster.

Configure an MCP client with OAuth

Connecting with OAuth requires two steps. First, register the Real-Time Context Engine MCP server with your identity pool ID. Then, complete the OAuth token exchange to get a bearer token.

Step 1: Register the MCP server

Register the Real-Time Context Engine MCP server with your MCP client and include the Confluent-Identity-Pool-Id header.

The following example command registers the server in Claude Code with confluent-rtce as the server name:

claude mcp add --transport http confluent-rtce \
  "https://mcp.<region>.aws.confluent.cloud/mcp/v1/context-engine/organizations/<org_id>/environments/<env_id>/kafka-clusters/<lkc_id>" \
  --header "Confluent-Identity-Pool-Id: <identity_pool_id>"

For MCP clients that use a JSON configuration file, add an entry like the following example:

{
  "mcpServers": {
    "confluent-rtce": {
      "url": "https://mcp.<region>.aws.confluent.cloud/mcp/v1/context-engine/organizations/<org_id>/environments/<env_id>/kafka-clusters/<lkc_id>",
      "headers": {
        "Confluent-Identity-Pool-Id": "<identity_pool_id>"
      }
    }
  }
}

Replace the following values:

  • <region>: The AWS region of your cluster, for example us-east-1.

  • <org_id>: Your Confluent Cloud organization ID.

  • <env_id>: Your Confluent Cloud environment ID.

  • <lkc_id>: Your Kafka cluster ID.

  • <identity_pool_id>: The ID of the identity pool to use for authentication.

Step 2: Complete the OAuth token exchange

After you register the MCP server, you need to get a bearer token from your identity provider and add it to the MCP server configuration. The token exchange uses the following flow:

  1. Send a request to the Real-Time Context Engine MCP server.

  2. The server responds with a 401 status and a WWW-Authenticate header that contains the authorization server URL.

  3. Exchange your client credentials (client_id and client_secret) with the authorization server for a bearer token.

  4. Add the bearer token to the Authorization header in your MCP server configuration.

How you complete this flow depends on your MCP client.

For more information about OAuth in Confluent Cloud, see OAuth overview.