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:

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:

Principal:   Developer
Resource:    vehicle-events
Operation:   Read
Permission:  Deny

The Kafka Admin can explicitly grant the required permission:

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:

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:

Navigate to Members in Condense Core.
Select the Environment User.
Select Assign Workspace Role.
Select one of the available roles:
- Kafka Admin
- Maintainer
- Developer
- Viewer
Select one or more workspaces.
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:

Open the Kafka Admin Dashboard.
Open ACL Management.
Locate the required user.
Select the Kafka resource.
Review the operation.
Review the current permission.
Change the permission to Allow when access is required.
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:

Workspace:  FleetTracking
Role:       Developer
Resource:   vehicle-events

Read:       Deny
Write:      Deny

The Kafka Admin can grant read access without granting write access:

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:

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.

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:

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.

​Overview

​Access Control in Condense

​Workspace Roles

​ACL Management

​Default Permission

​Assigning Kafka Resources

​ACL Availability

​When Applicable Roles Are Not Assigned

​When a Role Is Assigned

​When the Kafka Resource Is Not Available

​When the Kafka Resource Becomes Available

​Kafka Resources

​Topic Permissions

​Consumer Group Permissions

​Schema Access

​Users and Role Management

​Resource Management

​Managing ACL Permissions

​ACL Example

​Access Control Workflow

​Example: Multiple Users and Workspaces

​Access Capability Overview

​Administrative Controls

​External Users

​Access Control Model

​Frequently Asked Questions

​What is an ACL in Condense?

​Who manages Kafka ACLs?

​What happens when an ACL is created?

​Does workspace access automatically grant access to Kafka resources?

​What Kafka resources can be controlled through ACLs?

​Can access be granted for one operation but denied for another?

​What happens if a Kafka resource is not available?

​What is the difference between RBAC and ACL?

​Who assigns workspace roles?

​Who assigns Kafka resources?

​Summary