# Authorization Guide

> **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](https://docs.lenses.io/latest/user-guide/applications/kafka-to-kafka-replicator).

### 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

{% hint style="warning" %}
**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.
{% endhint %}

### 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

| 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)           |

{% hint style="info" %}
**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.
{% endhint %}

### 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**:

**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**:

**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**:

**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**:

**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**:

**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:

#### 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](https://docs.lenses.io/latest/user-guide/applications/kafka-to-kafka-replicator) - 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.lenses.io/latest/user-guide/using/share-and-replicate-data/kafka-to-kafka-replicator/authorization-guide.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.