Authorization Guide

This guide explains how authorization works for Kafka-to-Kafka (K2K) replication applications in Lenses. K2K apps replicate data between Kafka clusters across different environments, and this document

Note: This document focuses on IAM permissions and authorization. For information on creating and configuring K2K apps through the Lenses UI, see the Kafka to Kafka Replicator user guide.

Overview

To create or manage a K2K app, you need permissions on four types of resources:

1. K2K App - Permission to manage the app itself

2. Kubernetes Namespace - Permission to deploy to the target namespace

3. Source Kafka Connection - Permission to use the source connection

4. Target Kafka Connection - Permission to use the target connection

Important:

Your permissions control who can create and manage K2K apps. The actual data access (which topics the app can read/write) is controlled by the Kafka Connection's ACLs, which are configured separately when setting up the Kafka Connection.

Permission Requirements

To work with K2K apps, you need permissions on four resource types:

1. K2K App (k2k:app:${Name}) - The app itself

2. Kubernetes Namespace (kubernetes:namespace:${Environment}/${KubernetesCluster}/${KubernetesNamespace}) - Where the app is deployed

3. Source Kafka Connection (environments:kafka-connection:${SourceEnvironment}/${SourceConnectionName}) - Connection to read from

4. Target Kafka Connection (environments:kafka-connection:${TargetEnvironment}/${TargetConnectionName}) - Connection to write to

Required Permissions by Operation

The following table shows what permissions you need for each operation:

Operation	K2K App	Kubernetes Namespace	Source Kafka Connection	Target Kafka Connection
Create	write	write	read	read
Update	write	write	read	read
Delete	write	-	-	-
List	list	-	-	-
Get/View	read	-	-	-
Manage Offsets	write	-	-	-

Notes:

• All four permissions are required for Create and Update operations

• Delete, List, Get, and Manage Offsets only require the K2K App permission

• Even when source and target are in the same environment, you still need read permission on both Kafka Connection resources

• K2K app names are globally unique across all environments and namespaces

Example Resources:

• k2k:app:prod-to-staging-replication (specific app)

• k2k:app:staging-* (all apps starting with "staging-")

• k2k:app:* (all K2K apps)

• kubernetes:namespace:staging/incluster/data-replication

• environments:kafka-connection:prod/prod-source-conn

K2K Actions and Permissions

The following actions are available for K2K apps:

Action	Resource	Access	Description
k2k:CreateApp	k2k:app:${Name}	write	Create a new K2K app (automatically deploys and starts)
k2k:UpdateApp	k2k:app:${Name}	write	Update an existing K2K app (includes scaling, stopping via manifest)
k2k:UpsertApp	k2k:app:${Name}	write	Create or update a K2K app (idempotent operation)
k2k:DeleteApp	k2k:app:${Name}	write	Delete a K2K app
k2k:GetApp	k2k:app:${Name}	read	View details of a specific K2K app
k2k:ListApps	k2k:app:*	list	List all K2K apps (filtered by permissions)
k2k:ManageOffsets	k2k:app:${Name}	write	Reset or update consumer offsets (separate from UpdateApp)

Note: Creating a K2K app automatically deploys and starts it—there is no separate "deploy" or "start" action. To stop a K2K app, pause it through the UI or update the app configuration. To scale an app, update the replica count.

Understanding Permissions vs. Data Access

There are two separate layers of access control:

What Your Permissions Control

Your IAM permissions determine:

• ✅ Who can create, update, or delete K2K apps

• ✅ Which Kafka Connections you can use in K2K apps

• ✅ Which namespaces you can deploy to

• ✅ Who can view apps and metrics

• ✅ Who can manage offsets

What Kafka Connection ACLs Control

The Kafka Connection's ACLs (configured separately when setting up the connection) determine:

• ✅ Which Kafka topics the app can read from (source)

• ✅ Which Kafka topics the app can write to (target)

• ✅ Schema Registry access (if schema replication is enabled)

• ✅ Service account credentials used by the app

Why This Matters: This separation means you can create and manage K2K apps without needing direct access to the underlying Kafka topics. The app uses the credentials and ACLs configured in the Kafka Connection to access data at runtime.

Example: You can create a K2K app to replicate orders-* topics from production to staging, even if you don't have direct kafka:topic permissions. The app will use the service account and ACLs configured in the Kafka Connection to access topics.

Wildcard Topic Patterns

K2K apps support wildcard topic patterns (e.g., orders-*, user-events-*). When using wildcard patterns:

• You only need permission on the Kafka Connection, not on individual topics

• The app automatically handles new topics that match the pattern

• Topic access is controlled by the Kafka Connection's ACLs, not by your permissions

Example: If you create a K2K app to replicate orders-* topics:

• You need permission on the Kafka Connections (source and target)

• You don't need permission on individual orders-* topics

• When a new topic like orders-payment is created, the app will automatically replicate it if the Kafka Connection's ACLs allow access

Common Permission Scenarios

Scenario 1: K2K Admin (Full Control)

Use Case: Platform team managing all K2K apps across all environments.

Required Permissions:

- Effect: Allow
  Actions:
    - k2k:CreateApp
    - k2k:UpdateApp
    - k2k:DeleteApp
    - k2k:GetApp
    - k2k:ListApps
    - k2k:ManageOffsets
  Resources:
    - k2k:app:*
    
- Effect: Allow
  Actions:
    - kubernetes:DeployApps
  Resources:
    - kubernetes:namespace:*/*/*
    
- Effect: Allow
  Actions:
    - environments:GetKafkaConnectionDetails
  Resources:
    - environments:kafka-connection:*/*

Capabilities:

• ✅ Create and manage any K2K app

• ✅ Deploy to any namespace

• ✅ Use any Kafka Connection

Scenario 2: K2K Operator (Prod to Staging)

Use Case: Data engineer managing replication from production to staging.

Required Permissions:

- Effect: Allow
  Actions:
    - k2k:CreateApp
    - k2k:UpdateApp
    - k2k:DeleteApp
    - k2k:GetApp
    - k2k:ListApps
    - k2k:ManageOffsets
  Resources:
    - k2k:app:staging-*
    
- Effect: Allow
  Actions:
    - kubernetes:DeployApps
  Resources:
    - kubernetes:namespace:staging/incluster/data-replication
    
- Effect: Allow
  Actions:
    - environments:GetKafkaConnectionDetails
  Resources:
    - environments:kafka-connection:prod/prod-source-conn
    - environments:kafka-connection:staging/staging-target-conn

Capabilities:

• ✅ Create and manage K2K apps with names starting with "staging-"

• ✅ Deploy to staging data-replication namespace

• ✅ Use specified source/target Kafka Connections

• ❌ Cannot use other Kafka Connections or manage apps with different naming patterns

Scenario 3: Read-Only Observer

Use Case: SRE monitoring apps and metrics.

Required Permissions:

- Effect: Allow
  Actions:
    - k2k:GetApp
    - k2k:ListApps
  Resources:
    - k2k:app:*

Capabilities:

• ✅ View all K2K apps and their details

• ✅ View metrics and status

• ❌ Cannot create, update, or delete apps

• ❌ Cannot manage offsets

Scenario 4: Operations Engineer (Offset Management Only)

Use Case: On-call engineer who needs to reset offsets on critical apps.

Required Permissions:

- Effect: Allow
  Actions:
    - k2k:GetApp
    - k2k:ManageOffsets
  Resources:
    - k2k:app:critical-*

Capabilities:

• ✅ View critical K2K apps

• ✅ Reset offsets on critical apps

• ❌ Cannot create, update, or delete apps

• ❌ Cannot manage non-critical apps

Scenario 5: Development Team (Specific App)

Use Case: Team owning a specific data pipeline.

Required Permissions:

- Effect: Allow
  Actions:
    - k2k:CreateApp
    - k2k:UpdateApp
    - k2k:DeleteApp
    - k2k:GetApp
    - k2k:ListApps
    - k2k:ManageOffsets
  Resources:
    - k2k:app:user-events-replication
    
- Effect: Allow
  Actions:
    - kubernetes:DeployApps
  Resources:
    - kubernetes:namespace:dev/incluster/team-datapipe
    
- Effect: Allow
  Actions:
    - environments:GetKafkaConnectionDetails
  Resources:
    - environments:kafka-connection:dev/dev-source-conn
    - environments:kafka-connection:dev/dev-target-conn

Capabilities:

• ✅ Full control over their specific app (user-events-replication)

• ✅ Deploy to their team namespace

• ✅ Use specified dev environment Kafka Connections

• ❌ Cannot manage other apps or use other connections

Best Practices

1. Use Wildcard Patterns for Flexibility

Grant permissions using wildcard patterns to allow flexibility while maintaining security:

# Good: Allows managing all apps with a specific prefix
Resources:
  - k2k:app:team-*

# Good: Allows managing all apps in a specific namespace
Resources:
  - kubernetes:namespace:staging/incluster/data-*

# Avoid: Overly broad permissions unless necessary
Resources:
  - k2k:app:*  # Only for admins

2. Principle of Least Privilege

Grant only the permissions needed for the specific use case:

• App operators need k2k:app write, namespace write, and Kafka Connection read

• Observers only need k2k:app read

• Operations teams may only need k2k:ManageOffsets for specific apps

3. Separate App Management from Data Access

Remember that:

• User permissions control app lifecycle (create, update, delete)

• Kafka Connection ACLs control data access (topics, schemas)

Configure Kafka Connection ACLs separately to control what data the app can access, independent of who can create the app. This is configured when setting up Kafka Connections in the Lenses UI, not when creating the K2K app.

4. Use Descriptive App Names

Since K2K app names are globally unique and used in permission grants, use descriptive names that indicate purpose and scope:

• ✅ prod-to-staging-orders-replication

• ✅ dev-user-events-pipeline

• ❌ app1, test, replication

App Ownership

Important: K2K apps are organizational resources, not individually owned.

• ✅ Once created, any user with the appropriate permissions can manage the app

• ✅ Apps continue running even if the creator's account is deleted or permissions are revoked

• ✅ Audit logs track who created and modified apps

This ensures that personnel changes don't break production data flows.

Related Documentation

• Kafka to Kafka Replicator User Guide - How to create and manage K2K apps through the Lenses UI

Summary

To create or manage a K2K app, you need permissions on four resource types:

1. K2K App (k2k:app:${Name}) - Permission to manage the app

2. Kubernetes Namespace (kubernetes:namespace:${env}/${cluster}/${namespace}) - Permission to deploy to the namespace

3. Source Kafka Connection (environments:kafka-connection:${env}/${conn}) - Permission to use the source connection

4. Target Kafka Connection (environments:kafka-connection:${env}/${conn}) - Permission to use the target connection

Key Takeaway: Your permissions control who can create and manage K2K apps. The actual data access (which topics the app can read/write) is controlled by the Kafka Connection's ACLs, which are configured separately when setting up the Kafka Connection.