Purpose and scope of this Document

This document offers guidance around Service Account creation and usage. Service Accounts are created by the Central Platform Team but requested and defined by the System/Service owner or a Team delegate. A service account is intended to provide an identity for an application or service that needs to perform programmatic operations within Confluent Cloud. Avoid user account keys; if a user leaves and a user account is deleted, all API keys created with that user account are deleted and might break applications.

It is the Platform vision to move towards OAuth2 and OpenID Connect (OIDC); however, at this point, the setup is pending more automation, governance, and provider capabilities before it can be realized.

Naming

See Naming Conventions: Service Accounts for structure and considerations. Find Naming Conventions for guidance and inspiration on how to organize and structure your domain.

Use-cases for service accounts

Team Provisioning/Deployment account

• Whenever a new Data Domain is onboarded, a Service account "Deployment user" is created with it.
• This account enables the 'pipeline-template' to have the right level of permissions to create and update resources (schemas, topics, etc.) with the team prefix on the platform.
• There is a separation of accounts between environments, and it has the following naming structure: <TeamName>-deployment-<env>.
• The credentials are stored in a centrally managed AWS account and accessed by team-specific IAM users, which can be set up by reaching out to the platform team.
• See also Data Product Pipeline Template: Operation Guide.

Confluent Cloud Producer and Consumer Service Accounts

• Usage, permissions, and the number of Service accounts within a Team are highly dependent on the access model for the data that is being produced.

Scope Permissions & Approval

• You need to decide if you need to read (DeveloperRead) or write (DeveloperWrite) across specific resources.
• The patterns may include wildcards (*) to match multiple resources. Below are the most common ones:
  • Topics (reading from or writing to the data records).
  • Schemas (reading to validate compatibility of structure or writing to evolve versions of schema structure).
  • Transactional ID (a producer will need write permissions, as it identifies a single producer instance across application restarts and provides a way to ensure a single writer; this is necessary for exactly-once semantics (EOS)).

• The requested Service Account and permissions MUST be approved by the Data Domain/Data Product Owner or a delegate, since the central platform team grants permissions to data that may be critical or sensitive.

Examples

• "environments" define in what environments the service accounts should be created (by default, we separate service accounts between environments, meaning you have to switch keys).
• "consumergroup" when true, allows the service account to access consumer groups (logical grouping for one or more of its consumers).

Producer example

- name: "cosmos-infra"
  environments: ["dev", "tst", "qa", "prd"]
  consumergroup: true
  permissions:
    - topics: ["karen_system_cosmos_*"]
      role: "DeveloperRead"
    - topics: ["karen_system_cosmos_*"]
      role: "DeveloperWrite"
    - transactional_ids: ["karen_system_cosmos_*"]
      role: "DeveloperWrite"
  ```
### Consumer example
```yaml
- name: "datacore"
  environments: ["dev", "tst", "qa", "prd"]
  consumergroup: true
  permissions:
    - topics: ["karen_system_cosmos_*"]
      role: "DeveloperRead"