Title	Kafka as a Service Solution Design - Access Management
Version	12.0
Approval Pull Request (PR)	PR233418

Solution Design - Access Management¶

Purpose & Scope¶

This Solution Design covers access management of KaaS across services and deployments (e.g. Confluent Cloud and Splunk). See the Solution Designs section for an overview of the entire KaaS Solution.

Abbreviations and definitions¶

See Abbreviations and definitions

Solution Design Requirements¶

ID	Name
1	NovoAccess
2	Identity Provider and Single Sign On
3	Fallback User
4	Environments
5	AD Groups and Roles
6	Permission setup
7	Configuration Management

NovoAccess¶

Access Management will be done in NovoAccess.

The structure of the AD groups in section AD Groups will be available to request access to in novoAccess.

Identity Provider and Single Sign On¶

AzureAD is used as Identity provider for authentication and authorization on the platform.

SAML is chosen as the standard for user - SSO - authentication.

OpenID Connect (OIDC) is set up with Azure AD to enable token-based authentication and authorisation for system-to-system communication resources e.g. schema registry, and pub/sub of events to topics.

Fallback User¶

1 fallback user with full admin privileges is created for emergency situations, if SSO setup is not working and platform requires immediate attention. - Credentials will be stored in managed PIM safe and only accessible by few, privileged members.

Environments¶

To ensure separation of duties 4 default environments will be created;

Environment Name	Description
Development	Used for Development
Test	Used for End-to-End Testing
Quality Assurance	Used for Quality Assurance
Production	Used for Production

AD Groups and Roles¶

To handle the role-based access, individual AD groups will be created;

The AD groups will be linked to Confluent RBAC roles using the Group Mapping feature.

Platform Groups¶

AD Group	Description
KaaS_Administrator_ADM	Full access to configuration and data
KaaS_Operator_ADM	Full access to configuration platform (except Admin task), no data access
KaaS_Supporter	Read access, no data access
KaaS_Viewer	Read access (Only topics and schemas - less than supporter), no data access
KaaS_Playground_User	Read and Write access to the namespace "kaas_pg" in DEV environment

Team Domain AD Groups¶

Team groups is having access to the complete domain area, following below naming standard

AD Group	Description
`KaaS_<team>_Operator_ADM`	read + write access to team configuration and data on the domain
`KaaS_<team>_supporter`	Read access, can view data on the domain
`KaaS_<team>_developer`	Read access, can view data on data dev+test+qa environments, write access to data on dev in the domain

Team SubDomain AD Groups¶

Teams can be divided into subdomains. Team subdomain groups will be created as needed, following below naming standard

AD Group	Description
`KaaS_<team>_<subdomain>_Operator_ADM`	read + write access to team configuration and data in a specific subdomain
`KaaS_<team>_<subdomain>_supporter`	Read access, can view data in a specific subdomain

Permission setup¶

The following section describes how roles are linked to permissions and how prefixes are being used in the setup.

As default any access given to a user for an environment will mean giving access to both private and public clusters. It is only for CI/CD purposes we differentiate between public and private.

note: all = Dev, Tst, QA, Prd

Prefix¶

Scope of accesses are based on prefix, defined per team when created.

Domain¶

The first part of the prefix is the team name also called domain

<domain>

Examples:

Karen: Drug Development
Poul: People and organization
Damien: Master Data Management

Subdomain¶

A Domain can be divided into subdomains.

<domain>_<subdomain>

Examples:

karen_clinical  
karen_regulatory

Reserved subdomains for sharing between domains and subdomains.

Share

Used to share data between domains

<domain>_ _share_ _<subdomain>

Internal

Used to share data within domain in the individual subdomains.

<domain>_ _internal_ _<subdomain>

Users¶

Confluent Cloud Platform Users¶

Role	Platform Administrator	Platform Operator	Platform Supporter	KaaS Viewer
OrganizationAdmin (Organization)	x
Operator (Organization)		x	x
DataSteward (Environment)		all
DataDiscovery (Environment)			all	all
DeveloperManage (Topics*)		all
ResourceKeyAdmin(Organization)		x
BillingAdmin(Organization)		x
DeveloperRead (Connectors)		All	All
FlinkDeveloper (Flink)		All	All
ConnectManager (Clusters)		All

For more detailed information on the predefined RBAC roles in Confluent Cloud click here.

*: all Topics
all: dev, tst, qa and prd environment or cluster

Confluent Cloud Playground User¶

Topics and Schemas with prefix : kaas_pg_*

Role	KaaS Playground User
DeveloperRead (Topics*)	Dev
DeveloperWrite (Topics*)	Dev
DeveloperManage (Topics*)	Dev
DeveloperRead (Schema Registry*)	Dev
DeveloperWrite (Schema Registry*)	Dev
DeveloperManage (Schema Registry*)	Dev
ResourceOwner (Schema Registry*)	Dev
DeveloperRead (Consumer Group*)	Dev
DataDiscovery (Environment)	all
DeveloperRead (Connectors)	Dev
DeveloperWrite (Connectors)	Dev
ResourceOwner (Connectors)	Dev
ConnectManager (Specific Resource)	Dev
FlinkDeveloper (Flink)	Dev

For more detailed information on the predefined RBAC roles in Confluent Cloud click here.

Confluent Cloud Team Users¶

Role	Team Operator	Team Supporter	Team Developer
DeveloperRead (Topics*)	all	all	Dev, Tst, QA
DeveloperWrite (Topics*)	all		Dev
DeveloperManage (Topics*)	Dev		Dev
DeveloperRead (Schema Registry*)
DeveloperWrite (Schema Registry*)	all		Dev
DeveloperManage (Schema Registry*)	all		Dev
DataDiscovery (Environment)	all	all	all
DeveloperRead (Connectors*)		all	QA, Prd
ResourceOwner (Connectors*)	all		Dev, Tst

For more detailed information on the predefined RBAC roles in Confluent Cloud click here.

*: prefix
all: dev, tst, qa and prd environment

Confluent Cloud Team SubDomain Users¶

Role	Team Operator	Team Supporter	Team Developer
DeveloperRead (Topics*)	all	all	Dev, Tst, QA
DeveloperWrite (Topics*)	all		Dev
DeveloperManage (Topics*)	all		Dev
DeveloperRead (Schema Registry*)
DeveloperWrite (Schema Registry*)	all		Dev
DeveloperManage (Schema Registry*)	all		Dev
DataDiscovery (Environment)	all	all	all
DeveloperRead (Connectors*)		all	QA, Prd
ResourceOwner (Connectors*)	all		Dev, Tst

For more detailed information on the predefined RBAC roles in Confluent Cloud click here.

*: prefix
all: dev, tst, qa and prd environment

Service Accounts¶

Confluent Cloud Platform Service Accounts¶

Role	tp_runner
OrganizationAdmin (Organization)	x

This is saved in unmanaged PIM account for KaaS.

Confluent Cloud Team Deployment Service Accounts¶

Role	Access
ResourceOwner(Topics*)	`<env>`
ResourceOwner(Schema Registry*)	`<env>`
DataSteward(Environments)	`<env>`

For more detailed information on the predefined RBAC roles in Confluent Cloud click here.

*: prefix

These api secrets are stored in KaaS AWS secret manager.

The process on how to use these service accounts is described in the project Wiki.

Naming: <TeamName>-deployment-<env>

env = Dev, Tst, QA and Prd

Confluent Cloud Stream Catalog Pipeline Service Account¶

This Service Account is used by the stream-catalog-pipeline to deploy tags and metadata collections to Confluent Cloud, for downstream use by application pipelines, that create bindings of these to specific resources.

Role	Access
DataSteward(Environments)	`<env>`

API keys and secret are deployed for this service account, like with team deployment service accounts, and are also stored in KaaS AWS secret manager.

env = Dev, Tst, QA and Prd

Confluent Cloud for Client Consumer/Producer Service Accounts¶

Service Account is created to grant publishers and consumers access programmatically to create/consume events.

Naming: <TeamName>-<Subdomain>-<env>

This is a high-level naming standard but can be customized according to security needs.

env = Dev, Tst, QA and Prd

Role	`<role> in claims.roles && aud = <App Registration id>`
DeveloperWrite (Topics*)	x
DeveloperRead (Topics*)	x
DeveloperRead (Consumer Group*)	x
DeveloperWrite (Schemas*)	x
DeveloperRead (Schemas*)	x
DeveloperWrite (Transactional_ids*)	x
DeveloperRead (Transactional_ids*)	x

Above permissions can be optionally set when creating Service Accounts with the teams-pipeline in order to provide keys and secrets to Teams, as OIDC is not possible for all services and use-cases.

Consumer Group prefixed should be added with prefix sa.

For more detailed information on the predefined RBAC roles in Confluent Cloud click here.

Connector permissions¶

Initially Connector permissions are setup leveraging the existing Topic and schema access model, while ad-hoc configuring any custom connector permission from the GUI following the Connector ACL GUI Guide

Identity Pool¶

Confluent Cloud Platform Identity Pool¶

One Identity pool is created for each environment cross-platform access.

Naming: kaas-platform-<env>

Role	Platform `schemaregistry.Read in claims.roles && aud = <App Registration id>`
DataDiscovery (Environment)	x

Confluent Cloud Team Users Identity Pool¶

One Identity pool is created for a team to grant developer access to publish and consume events programmatically on the development environment.

Naming: kaas-team-<TeamName>

Role	Team Developer `'developer' in claims.roles && aud = <App Registration id>`
DeveloperRead (Topics*)	Dev
DeveloperWrite(Topics*)	Dev
DeveloperRead (Consumer Group*)	Dev

Consumer Group prefixed should be added with prefix pool

Each team will have a single App Registration and get roles from AD Group linked to AD Account.

Authorization Code grant flow is being used for authentication/authorization

For more detailed information on the predefined RBAC roles in Confluent Cloud click here.

*based on Prefix rule

Prefix <TeamName>

Confluent Cloud Identity Pool for Consumer/Producer¶

Identity pools is created to grant publishers and consumers access programmatically to create/consume events.

App Registration Naming: kaas-<TeamName>-<Subdomain>-<env>

App role <Product>.<SubProduct>.<Read,Write,FullAccess>

This is a high-level naming standard but can be customized according to security needs.

env = Dev, Tst, QA and Prd

Role	`'<role>' in claims.roles && aud = <App Registration id>`
DeveloperWrite (Topics*)	x
DeveloperRead(Topics*)	x
DeveloperRead(Consumer Group*)	x

Client Quota¶

Confluent Cloud Client Quota for Consumers/Producers Service Accounts¶

Client quotas are created to control ingress (producer writes) and egress (consumer reads) at a service account level, but all service accounts mapped to the same quota tier (e.g., tier-1MBps, tier-2MBps) are grouped under a single quota resource. This prevents any single client from exhausting cluster resources while maintaining fair usage.

Quota Naming: tier-<N>

Quota	Throughput Limits	Principals (Service Accounts)
tier-1MBps	Ingress: 1 MB/s, Egress: 1 MB/s	`pilot-pilotapp`, `pilot-connector-sink`
tier-2MBps	Ingress: 2 MB/s, Egress: 2 MB/s	`labs-lims`
tier-5MBps	Ingress: 5 MB/s, Egress: 5 MB/s	`pilot-pilotap2`, `karen-datacore`
tier-10MBps	Ingress: 10 MB/s, Egress: 10 MB/s	`karen-system-cosmos`

Changing Tier of a Service Account¶

To change the quota tier of a service account, simply update the clientQuota field in its definition.

Example:

# Before
clientQuota: "tier-1MBps"

# After
clientQuota: "tier-2MBps"

Removing Client Quota of a Service Account¶

To remove a client quota from a service account, just remove the clientQuota field. Terraform will detect this change and automatically delete the quota assignment for that service account.

# Before
clientQuota: "tier-1MBps"

# After
# clientQuota field removed → quota deleted

Adding a New Quota Tier¶

To introduce a new quota tier, add a new entry in the client-quota-sa-tiers.yaml file in access-mgmt-config-prod repository. Each tier defines separate producer and consumer byte rate limits.

Example: Adding a 20 MBps Tier

- clientQuotaName: "tier-20MBps"
  byteRate:
    producerByteRate: 20000000     # 20 MB/s limit on production
    consumerByteRate: 20000000     # 20 MB/s limit on consumption

Once applied, this new tier can be referenced in service accounts by setting:

clientQuota: "tier-20MBps"

Configuration Management¶

All configuration will be handled by a Team Provisioning Pipeline. See Team Provisioning Pipeline

Traceability between Requirements¶

Traceability between Requirements (URS) and (SDR)¶

ID	Work Item Type	URS (Status Dynamically Updated)	GIT SDR
1318367	URS	#1318367	Solution Design Requirement: Identity Provider and Single Sign On
1421694	URS	#1421694	Solution Design Requirement: NovoAccess
1337204	URS	#1337204	Solution Design Requirement: Identity Provider and Single Sign On
1374619	URS	#1374619	Solution Design Requirement: Fallback User
1374669	URS	#1374669	Solution Design Requirement: AD Groups and Roles Solution Design Requirement: Permission Setup
1374692	URS	#1374692	Solution Design Requirement: Environments
3144028	URS	#3144028	Solution Design Requirement: Permission Setup
3351539	URS	#3351539	Solution Design Requirement: Client Quota

Change Log¶

Version no.	CHG no.	Approved Pull Request	Date	Change Description
1.0	CHG0100614	PR93710	Date of acknowledgement	New document
2.0	CHG0100614	PR99125	Date of acknowledgement	Updated identity pools
3.0	CHG0100614	PR110259	Date of acknowledgement	Added service Accounts and updated Platform and User Roles
4.0	CHG0100614	PR111901	Date of acknowledgement	Changed Platform Operator permissions
5.0	CHG0122187	PR118690	See PR	Added DataSteward to Team Deployment ServiceAccount permissions and Confluent Cloud Stream Catalog Pipeline Service Account
6.0	CHG0127934	PR127845	See PR	Added 'KaaS Viewer' to Confluent Cloud Platform Users
7.0	CHG0136972	PR138553	See PR	Added transaction_id and permissions to Confluent Cloud for Consumer/Producer Service Accounts
8.0	CHG0137519	PR139909	See PR	Updated Confluent 'BillingAdmin' Role to KaaS 'Platform Operator'
9.0	CHG0139543	PR158576	See PR	Added a minor comment addressing Group Mapping from AD Roles to Confluent Cloud RBAC roles.
10.0	CHG0173645	PR202591	See PR	Setting up of Playground User role.
11.0	CHG0184608	PR229067	See PR	Added permissions related to connector enablement
12.0	CHG0184608	PR233418	See PR	Removed redundant DeveloperRead permissions related to connector enablement

Solution Design - Access Management¶

Purpose & Scope¶

Abbreviations and definitions¶

Solution Design Requirements¶

NovoAccess¶

Identity Provider and Single Sign On¶

Fallback User¶

Environments¶

AD Groups and Roles¶

Platform Groups¶

Team Domain AD Groups¶

Team SubDomain AD Groups¶

Permission setup¶

Prefix¶

Domain¶

Subdomain¶

Share and Internal subdomains¶

Users¶

Confluent Cloud Platform Users¶

Confluent Cloud Playground User¶

Confluent Cloud Team Users¶

Confluent Cloud Team SubDomain Users¶

Service Accounts¶

Confluent Cloud Platform Service Accounts¶

Confluent Cloud Team Deployment Service Accounts¶

Confluent Cloud Stream Catalog Pipeline Service Account¶

Confluent Cloud for Client Consumer/Producer Service Accounts¶

Connector permissions¶

Identity Pool¶

Confluent Cloud Platform Identity Pool¶

Confluent Cloud Team Users Identity Pool¶

Confluent Cloud Identity Pool for Consumer/Producer¶

Client Quota¶

Confluent Cloud Client Quota for Consumers/Producers Service Accounts¶

Changing Tier of a Service Account¶

Removing Client Quota of a Service Account¶

Adding a New Quota Tier¶

Configuration Management¶

Traceability between Requirements¶

Traceability between Requirements (URS) and (SDR)¶

Change Log¶