Service Accounts — Confluent Self-Service Docs

Overview

Service accounts provide machine-to-machine authentication for applications that need to interact with Kafka clusters. Unlike user accounts (which are tied to individuals), service accounts are designed for automated systems, CI/CD pipelines, and application workloads.

Each service account is created with a specific type that determines its role bindings — the set of permissions it receives on cluster resources like topics, consumer groups, and Schema Registry subjects.

Confluent Documentation

Naming Convention

Service account display names follow a fixed format that includes a sa- prefix, the cluster context, and the service account type:


    sa-{landing_zone}-{business_unit}-{stage}-usr-{identifier}-{type}

Shared Clusters

Example: sa-edh-shared-scada-dev-usr-order-processor-producer

Dedicated Clusters

For dedicated clusters landing_zone equals business_unit.

Example: sa-sales-sales-dev-usr-order-processor-producer

landing_zone: Shared cluster landing zone identifier (e.g., "edh-shared"); equals business_unit for dedicated clusters

business_unit: Your organization's identifier (e.g., "scada", "sales")

stage: Environment stage (dev, qas, or run)

identifier: Descriptive name you provide (e.g., "order-processor", "analytics-sink")

type: The account type — one of producer, consumer, stream-processor, or metrics

Note

When creating a service account, you only need to provide the identifier. The system automatically normalizes it (lowercase, hyphens instead of underscores/dots/spaces) and constructs the full display name including the appropriate prefix and type suffix.

Account Types

The type you choose determines which role bindings are created for the service account. Role bindings define the permissions the account has on cluster resources. These are system-defined templates.

Producer

Read/write access to topics and transactional IDs, read access to consumer groups and Schema Registry subjects, plus Operator role to view other consumers and producers.

Role	Resource
Operator	Cluster
DeveloperRead + DeveloperWrite	Topic
DeveloperRead + DeveloperWrite	TransactionalId
DeveloperRead	Group
DeveloperRead	Subject

Consumer

Read access to topics, consumer groups, and Schema Registry subjects, plus Operator role to view other consumers and producers.

Role	Resource
Operator	Cluster
DeveloperRead	Topic
DeveloperRead	Group
DeveloperRead	Subject

Stream Processor

Read/write access to topics, transactional IDs, and consumer groups (including internal group management for Kafka Streams / Flink), plus read access to Schema Registry subjects and Operator role. Use this type for stateful stream processing applications.

Role	Resource
Operator	Cluster
DeveloperRead + DeveloperWrite	Topic
DeveloperRead + DeveloperWrite	TransactionalId
DeveloperRead + DeveloperWrite	Group
DeveloperRead	Subject

Metrics

MetricsViewer access scoped to the environment. Allows querying the Confluent Metrics API (e.g. for Grafana dashboards or monitoring tools). Has no Kafka cluster or Schema Registry access.

Role	Resource
MetricsViewer	Environment

Creating Service Accounts

When you create a service account, the following happens automatically:

Name normalization: Your identifier is normalized and prefixed based on the naming convention
Account creation: The service account is registered in Confluent Cloud
Role bindings: Permissions are assigned based on the selected type (producer/consumer)
API key generation: A Cluster API key is created and both key and secret are stored in your Azure Key Vault

Topic Prefix (optional)

For account types that include Topic or Schema Registry subject role bindings (e.g., Producer, Consumer), you can optionally specify a Topic Prefix to narrow the scope of those bindings to a specific subset of topics and subjects. When set, role bindings are scoped to resources whose names start with {context_prefix}{topic_prefix}-* instead of the full context prefix wildcard.

Leave this field empty to grant access to all topics and subjects within your business unit context. Topic prefix narrowing is only effective on dedicated clusters; on shared clusters the context prefix already scopes resources to your business unit.

Important

Both the API key and secret are automatically stored in your business unit's Azure Key Vault. You can view the Key Vault reference on the Info page.

Bulk Creation

For scenarios where you need to create multiple service accounts at once, the portal supports bulk creation. This is useful when onboarding a new team or setting up a microservices architecture.

How it works

Define multiple service accounts with their names and types
All items are validated upfront — if any item fails validation, nothing is created
A background job is submitted to process the batch asynchronously
Track progress via the job status endpoint or the UI

JSON Format

Upload a .json file containing an array of up to 20 service account objects.

Property	Required	Description
name	Yes	Short identifier for the account (e.g. `order-ingestor`). This is not the final display name — it is normalized and combined with the context prefix and type to form the full name (e.g. `sa-edh-shared-scada-dev-usr-order-ingestor-producer`).
type	Yes	Account type: `producer`, `consumer`, `stream-processor`, or `metrics`.
description	No	Free-text description stored with the service account in Confluent Cloud.
topic_prefix	No	Narrows topic and Schema Registry subject role bindings to resources matching `{context_prefix}{topic_prefix}-*`. Leave empty to grant access to all topics in the context. Only effective on dedicated clusters.
prefix	No	Overrides the user CRN prefix used for all role bindings. Leave empty to use the auto-derived prefix. Only applicable on dedicated clusters.

Example:

[
  {
    "name": "order-ingestor",
    "type": "producer",
    "description": "Writes order events from the order service"
  },
  {
    "name": "order-reader",
    "type": "consumer",
    "description": "Reads order events for the fulfilment service",
    "topic_prefix": "orders"
  },
  {
    "name": "order-aggregator",
    "type": "stream-processor",
    "description": "Kafka Streams job that aggregates order metrics"
  },
  {
    "name": "grafana-metrics",
    "type": "metrics",
    "description": "Read-only metrics access for the Grafana dashboard"
  }
]

Note

Bulk creation jobs run asynchronously as Kubernetes jobs. API key secrets for each created account are stored in Azure Key Vault automatically.

API Keys

Each service account receives a Cluster API key upon creation. This key pair (key + secret) is used to authenticate the application against the Kafka cluster.

Key Properties

Resource-scoped: The API key is scoped to the specific Kafka cluster
Key Vault storage: Both the API key and secret are automatically stored in your business unit's Azure Key Vault

Using API Keys

Configure your Kafka client with the API key and secret:

bootstrap.servers=<bootstrap_server>
security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
  username="<API_KEY>" \
  password="<API_SECRET>";

Best Practices

Create one service account per application or microservice
Use descriptive names that identify the application (e.g., "order-processor", "analytics-sink")
Choose the minimum required type — use "consumer" for read-only apps, "stream-processor" for Kafka Streams / Flink, "metrics" for monitoring-only access
Store API key secrets in a secure vault; never commit them to source control
Rotate API keys regularly as part of your security practices
Test service accounts in dev/qas before creating them in production
Use bulk creation for consistent onboarding of multiple services