> ## Documentation Index > Fetch the complete documentation index at: https://docs.condense.io/llms.txt > Use this file to discover all available pages before exploring further. # Access Control List ## Overview Access Control Lists (ACLs) in Condense provide fine-grained control over access to Kafka resources. The ACL Management tab in the **Kafka Admin Dashboard** allows a Kafka Admin to define and manage access policies for users and Kafka resources. An ACL specifies the user the rule applies to, the Kafka resource, the operation, and whether that operation is allowed or denied. ACLs work with the Condense access model of **Organization, Environment, and Workspace**. Workspace roles determine the Kafka capabilities available to an Environment User, while ACLs provide control over the Kafka resources and operations available to that user. *** ## Access Control in Condense Condense manages access at three levels: ```text theme={null} Organization | v Environment | v Workspace | v Workspace Role | v Kafka Resource | v ACL Permission ``` The organization and environment layers determine administration and visibility. Workspace roles provide the operational capabilities available to Environment Users. Kafka Admins then manage Kafka resources and their ACL permissions. For Environment Users, workspace access is explicitly assigned. The workspace role selected for a user applies to all workspaces selected during that assignment. *** ## Workspace Roles The Kafka workspace roles in Condense are: * **Kafka Admin** * **Maintainer** * **Developer** * **Viewer** These roles define the Kafka capabilities available to an Environment User. | Role | Access | | --------------- | --------------------------------------------------- | | **Kafka Admin** | Kafka administration and Kafka resource operations. | | **Maintainer** | Maintainer capabilities within assigned workspaces. | | **Developer** | Developer capabilities within assigned workspaces. | | **Viewer** | Read-only access within assigned workspaces. | Environment Admins can assign workspace roles to Environment Users. Kafka Admins manage Kafka resources and ACLs. *** # ACL Management The **ACL Management** tab is available in the Kafka Admin Dashboard. It provides the Kafka Admin with a view of ACL rules associated with users and Kafka resources. Each ACL contains four primary fields: | Field | Description | | -------------- | -------------------------------------------------------------------------------------- | | **Principal** | The identity of the user to whom the ACL rule applies. | | **Permission** | The access level for the associated resource: **Allow** or **Deny**. | | **Operation** | The Kafka operation covered by the rule, such as Read, Write, or Describe. | | **Resource** | The Kafka resource to which the permission applies, such as a Topic or Consumer Group. | Operations are preconfigured according to the user's assigned role and can be modified by the Kafka Admin. *** ## Default Permission ACL permissions default to **Deny** until they are explicitly changed by a Kafka Admin. This means that assigning a role or making a Kafka resource available does not by itself grant the user permission to perform every operation on that resource. For example: ```text theme={null} Principal: Developer Resource: vehicle-events Operation: Read Permission: Deny ``` The Kafka Admin can explicitly grant the required permission: ```text theme={null} Principal: Developer Resource: vehicle-events Operation: Read Permission: Allow ``` The user can then perform the permitted operation on that resource. *** # Assigning Kafka Resources Kafka Admins assign Kafka resources to Environment Users. The resource assignment is separate from the user's workspace assignment. The workflow is: ```text theme={null} Environment User | v Workspace assigned | v Workspace role assigned | v Kafka resource assigned | v ACL permission configured ``` A user can therefore have access to a workspace without automatically receiving access to every Kafka resource in that workspace. *** # ACL Availability The ACL view changes according to the users, roles, and Kafka resources available in the environment. ## When Applicable Roles Are Not Assigned If no Environment Users have the applicable Kafka workspace roles, there are no corresponding ACL entries to configure. ## When a Role Is Assigned Once an Environment User has been assigned an applicable Kafka role, the ACL view can display the permissions associated with that role. ## When the Kafka Resource Is Not Available If the required Kafka resource is not yet available, the resource is shown as pending resource availability. The permission remains **Deny** until the resource is available and the Kafka Admin configures the ACL. ## When the Kafka Resource Becomes Available Once the Kafka resource becomes available, the Kafka Admin can configure the applicable ACL. The permission remains **Deny** until it is explicitly changed. *** # Kafka Resources ACLs are used with Kafka resources managed through Condense. The Kafka resource model includes: * **Topics** * **Consumer Groups** * **Schemas** The Resource Management view provides a resource-level view of configured access. Kafka Admins can use it to review: * Kafka resources with ACL configuration * Users associated with a resource * Roles associated with users * Effective permissions * Workspace associations *** # Topic Permissions Topic access is controlled through Kafka operations. | Access | Kafka Operation | Purpose | | ---------- | ------------------------- | ---------------------------------------------- | | **Read** | Fetch | Consume records from a topic. | | **Read** | List Offsets | Retrieve topic offsets. | | **Write** | Produce | Publish records to a topic. | | **Read** | Metadata | Retrieve topic metadata. | | **Read** | Offset Fetch | Retrieve offsets. | | **Read** | Describe Topics Partition | Retrieve partition and leader information. | | **Read** | Describe Configs | Read topic or broker configuration parameters. | | **Update** | Alter Configs | Modify topic or broker configuration. | | **Delete** | Delete Topics | Delete a topic. | | **Delete** | Delete Records | Delete records from a topic. | | **Create** | Create Topics | Create a new topic. | Kafka Admins have full topic lifecycle management capabilities. Other users operate on topics according to their assigned role, workspace, resource, and ACL permissions. *** # Consumer Group Permissions Consumer Groups are also managed through Kafka permissions. | Access | Kafka Operation | Purpose | | ---------- | ----------------------- | --------------------------------------------------- | | **Create** | Join Group | Allows a consumer to join a consumer group. | | **Create** | Sync Group | Synchronizes consumer group membership. | | **Read** | List Group | Lists consumer groups. | | **Read** | Describe Groups | Displays consumer group members, topics, and state. | | **Read** | Consumer Group Describe | Provides consumer group metadata. | | **Read** | Offset Fetch | Retrieves consumer offsets. | | **Read** | List Offsets | Retrieves the latest offsets. | | **Delete** | Delete Group | Deletes a consumer group. | | **Delete** | Delete Offsets | Deletes consumer group offsets. | Kafka does not expose a separate Create Consumer Group API. Join Group and Sync Group are therefore mapped to the Create category in the Condense permission model. Consumer Group operations are subject to the permissions configured for the user. *** # Schema Access Schemas are included in the Kafka resource model. Schema access follows the same role and resource model used for other Kafka resources. Schema Registry management is available when Schema Registry is enabled for the environment. *** # Users and Role Management The **Users and Role Management** area provides a role and resource permission matrix. The matrix shows: | Field | Description | | ----------------- | -------------------------------------------------------- | | **Role Name** | The Kafka workspace role. | | **Resource Type** | The Kafka resource type to which the permission applies. | | **Permissions** | Permissions associated with the role. | | **Actions** | Available role management actions. | The permissions associated with predefined roles are displayed as preselected permissions. Environment Admins assign workspace roles to Environment Users. To assign a workspace role: 1. Navigate to **Members** in Condense Core. 2. Select the Environment User. 3. Select **Assign Workspace Role**. 4. Select one of the available roles: * Kafka Admin * Maintainer * Developer * Viewer 5. Select one or more workspaces. 6. Apply the assignment. The selected role applies to all workspaces selected during the assignment. Later workspace additions use the same role. *** # Resource Management The **Resource Management** tab provides a resource-focused view of Kafka access. Use this view when you want to understand access from the perspective of a Kafka resource rather than a user. For a resource, Kafka Admins can review: * Users associated with the resource * User roles * Configured permissions * Workspace associations * ACL configuration This makes it possible to identify which users can access a Kafka resource and what operations are available to them. *** # Managing ACL Permissions Kafka Admins manage permissions from the ACL Management view. To configure an ACL: 1. Open the **Kafka Admin Dashboard**. 2. Open **ACL Management**. 3. Locate the required user. 4. Select the Kafka resource. 5. Review the operation. 6. Review the current permission. 7. Change the permission to **Allow** when access is required. 8. Save the ACL. Permissions that have not been explicitly granted remain **Deny**. *** # ACL Example Suppose a user has the Developer role and is assigned the `FleetTracking` workspace. The user has been assigned the `vehicle-events` topic, but the topic permissions are initially denied: ```text theme={null} Workspace: FleetTracking Role: Developer Resource: vehicle-events Read: Deny Write: Deny ``` The Kafka Admin can grant read access without granting write access: ```text theme={null} Workspace: FleetTracking Role: Developer Resource: vehicle-events Read: Allow Write: Deny ``` The user can now read from the topic, while write access remains unavailable. *** # Access Control Workflow The complete workflow for users and Kafka access is: ```text theme={null} Account Admin | v Invites Environment User | v Environment Admin | +---- Assigns Workspace | +---- Assigns Workspace Role | v Environment User | v Kafka Admin | +---- Assigns Kafka Resource | +---- Configures ACL | v Allow / Deny ``` The first stages establish the user's environment and workspace access. Kafka Admin then manages the Kafka resource assignment and the ACL permissions associated with that resource. *** # Example: Multiple Users and Workspaces Consider an environment with the following workspaces: * `FleetTracking` * `ColdChain` * `Sandbox` Users can have different workspace roles: | User | Environment | Workspace Role | | ---------- | ----------- | ------------------------------------ | | **Bharat** | Production | Kafka Admin — FleetTracking | | **Divya** | Testing | Maintainer — Sandbox | | **Eshan** | Production | Developer — FleetTracking, ColdChain | | **Farah** | Testing | Viewer — Sandbox | The resulting access is different for each user: * **Bharat** can access Production and has Kafka Admin access for FleetTracking. * **Divya** can operate in Sandbox as a Maintainer. * **Eshan** can work in FleetTracking and ColdChain as a Developer. * **Farah** has Viewer access to Sandbox. Environment Admins see and operate across all workspaces in their environments. Environment Users see only the workspaces for which they have been assigned a role. *** # Access Capability Overview | Capability | Environment Admin | Environment User | | -------------------------- | ----------------: | ---------------: | | Access all workspaces | Yes | No | | Access assigned workspaces | Yes | Yes | | Create / delete workspaces | Yes | No | | Manage workspace members | Yes | No | | Deploy connectors | Yes | Maintainer | | Develop applications | Yes | Developer | | Kafka operations | Yes | Kafka Admin | | View everything | Yes | Viewer | The workspace role determines the operational capabilities available to an Environment User. *** # Administrative Controls ACLs provide a separate control over Kafka resource operations. The main controls are: * ACL permissions default to **Deny**. * Kafka Admins explicitly grant access by changing the permission to **Allow**. * ACLs identify the principal, operation, resource, and permission. * Kafka resource assignment is managed separately from workspace assignment. * Kafka Admins can review resource-level access through Resource Management. * Kafka operations are subject to the permissions configured for the user. *** # External Users The current ACL specification includes external-user onboarding and ACL assignment as part of the broader flow. However, the detailed ACL behavior and onboarding experience for external users is **not yet defined** in the current specification and requires further discussion. *** # Access Control Model Condense combines workspace-level RBAC with Kafka resource-level ACLs. ```text theme={null} Organization | v Environment | v Workspace | v Workspace Role | v Kafka Resource | v Kafka Operation | v Allow / Deny ``` The workspace role determines the user's available capabilities. ACLs determine whether the user can perform a specific Kafka operation against the applicable Kafka resource. This keeps workspace access and Kafka resource permissions as separate controls while allowing Kafka Admins to manage resource-level access from a single dashboard. *** # Frequently Asked Questions ## What is an ACL in Condense? An ACL is an Access Control List rule that determines whether a user can perform a specific Kafka operation on a Kafka resource. ## Who manages Kafka ACLs? Kafka Admins manage Kafka ACLs from the Kafka Admin Dashboard. ## What happens when an ACL is created? The permission defaults to **Deny**. The Kafka Admin must explicitly change it to **Allow** to grant the operation. ## Does workspace access automatically grant access to Kafka resources? No. Workspace access and Kafka resource permissions are separate. The required Kafka resource must be assigned and the appropriate ACL permission must be configured. ## What Kafka resources can be controlled through ACLs? The current resource model includes Topics, Consumer Groups, and Schemas. ## Can access be granted for one operation but denied for another? Yes. ACLs are operation-specific. For example, a user can be allowed to Read a topic while Write remains Denied. ## What happens if a Kafka resource is not available? The ACL can remain pending resource availability. The permission remains Deny until the resource is available and configured by the Kafka Admin. ## What is the difference between RBAC and ACL? RBAC defines the capabilities associated with a user's workspace role. ACLs provide finer control over access to Kafka resources and operations. ## Who assigns workspace roles? Environment Admins assign workspace roles to Environment Users. ## Who assigns Kafka resources? Kafka Admins assign Kafka resources to Environment Users and manage their ACL permissions. *** # Summary Condense uses two related access controls: * **RBAC** controls what an Environment User can do within assigned workspaces. * **ACLs** control access to Kafka resources and operations. The resulting access path is: ```text theme={null} Organization | Environment | Workspace | Workspace Role | Kafka Resource | ACL | Allow / Deny ``` This allows teams to manage access across environments and workspaces while giving Kafka Admins control over individual Kafka resources and operations.