Table of Contents
Table of Contents
A Kafka user interface (UI) becomes a production control surface the moment someone can reset a consumer group, alter a Topic configuration, or publish a test Record. Redpanda Console makes those operations visible through a browser, which helps teams diagnose incidents, but the browser does not make the underlying authorization or audit problem go away. The hard question is who can perform each action, where that permission is enforced, and which system records the decision.
A useful Redpanda Console operating model keeps four things separate: the Console interface, the identity and roles that let someone enter it, the Kafka access control lists (ACLs) enforced by the broker, and the runbook that explains what to do during an incident. This separation also matters when a team evaluates an alternative Kafka platform. A UI can remain familiar while the control plane and data plane underneath it follow a different boundary.
1Redpanda Console is an operating surface, not a security boundary
Redpanda Console is an open-source web interface for Kafka-compatible clusters. The project exposes views and actions for common Kafka administration tasks, but the exact actions available to an operator depend on the Console release, its configuration, the credentials it uses to reach the cluster, and the application programming interfaces (APIs) supported by that cluster. Treat the repository and the versioned deployment documentation as the source for what a particular deployment can do.
That distinction matters during an access review. Hiding a button can improve the user experience, but it does not replace authorization at the Kafka broker. Conversely, granting a service account broad Kafka privileges because the UI needs one diagnostic action gives every user of that Console path more authority than the screen may suggest. The interface is one actor in the request path. It is not the final policy decision.
A production review should start with actions rather than job titles. “Developer,” “operator,” and “administrator” are too broad to describe Kafka risk. A developer might need to inspect metadata for an owned Topic, while a site reliability engineer (SRE) may need temporary permission to reset an Offset during an incident. Both users may sign in through the same Console, but their allowed actions and evidence requirements are different. For a broader treatment of this boundary, see Kafka UI access patterns for platform and application teams.
Review the four layers in order:
| Layer | What it answers | Where to verify it | What it must not be mistaken for |
|---|---|---|---|
| Console interface | Which Kafka views and controls are presented to a user | Console configuration, release notes, and deployment logs | Proof that the broker will authorize the request |
| Identity and application roles | Who can sign in and which Console routes or actions are exposed | Identity provider, reverse proxy, and Console configuration | A replacement for Kafka authorization |
| Kafka ACLs | Whether a principal may perform an operation on a resource | Kafka authorizer configuration and broker authorization logs | A record of every browser decision or business approval |
| Runbook and change process | Why the action is allowed, who owns it, and how to recover | Change ticket, incident record, and post-change evidence | A feature supplied automatically by a UI |
The table is a boundary map, not a product scorecard. It gives a security reviewer a way to ask the same question at each layer: which system makes this decision, and which system proves that it happened?
2Map actions to Kafka authorization before assigning UI access
Kafka authorization applies to the request that reaches the broker. Depending on the operation, that request can require permissions such as DESCRIBE, READ, WRITE, ALTER, or DELETE on a Topic, consumer group, or cluster resource. The exact ACL pattern depends on the operation, the Kafka version, and the authorizer configuration, so a role name in the UI is not enough evidence. Use the Apache Kafka security documentation and test the effective principal against the same cluster listeners and credentials used in production.
A useful access matrix separates observation from mutation. The owner column matters because the person who requests an action is not always the person who should approve it.
| Operation exposed through a Kafka UI | Typical Kafka-side permission to validate | Additional production control | Evidence to retain |
|---|---|---|---|
| View Topic metadata and Partition state | Metadata permissions on the relevant resources | Scope by environment and ownership | User identity, cluster, Topic, timestamp |
| Read Record payloads | Read permission for the Topic and group or consumer context | Data classification and payload masking policy | Query context, user, purpose, and access log |
| Produce a test Record | Write permission on the Topic | Use a non-production Topic or approved test key | Principal, Topic, payload policy, result |
| Reset a consumer group Offset | Group and Topic permissions required by the reset path | Incident or change approval, recovery note | Before and after Offset, operator, reason |
| Alter retention or Partition settings | Alter permission on the Topic | Capacity review and rollback value | Previous value, resulting value, owner, change reference |
| Delete a Topic or change ACLs | Delete or cluster-level administrative permissions | Break-glass approval and explicit confirmation | Approver, request, command result, review |
This matrix prevents a common mistake: treating “read-only Console access” as one universal permission. Metadata inspection, payload access, and Offset changes carry different data and business risks. If the UI cannot express those distinctions, keep the high-impact operations behind a controlled workflow instead of compensating with informal instructions.
ACLs also need an ownership model. A platform team can own cluster-wide settings and ACL administration, while an application team owns its consumer groups and Topics. That ownership should be represented in a source of truth such as infrastructure-as-code, a catalog, or a service registry. A name in the Topic prefix is useful context, but it is not a reliable approval system by itself.
Role-based access control adds another layer of meaning. An identity provider or application role may decide who can enter the Console and which paths they can use. Kafka ACLs then decide whether the Console's Kafka principal can complete the request. If the Console connects with one shared service account, broker logs may show that service account rather than the human who clicked the button. That may be acceptable for read-only views, but it is weak evidence for high-impact mutations unless the surrounding identity and audit system preserves the human actor.
3Audit the full request path
An audit trail for Kafka operations is assembled from several systems. A browser access log can show that a user reached a Console route. An identity provider can show sign-in, group membership, and elevation. A reverse proxy can add network context. Kafka authorization logs can show which principal requested an operation and whether the broker allowed it. A change or incident system can explain why that operation was approved.
None of those records is complete on its own. A broker log may prove that a service account altered a Topic, but not which human approved the change. A Console request log may identify the human, but not the effective Kafka principal or the previous and resulting configuration values. During an investigation, the missing link is usually the correlation identifier between these records.
Before enabling mutation through Redpanda Console, retain at least the following evidence:
- Actor: human identity, service identity, or break-glass account, with the identity-provider event that established it.
- Target: cluster, environment, Topic, Partition, consumer group, connector, or ACL resource.
- Requested operation: the action and parameters presented by the user.
- Effective principal: the Kafka principal that reached the broker.
- Result: success or failure, including the broker response and any asynchronous task result.
- Reason and approval: incident, change record, or approved self-service request.
- Recovery point: the previous configuration, Offset, or ACL state needed to reverse the change.
Keep audit records separate from message payloads. A Record shown in a debugging view can contain personal, financial, or security-sensitive fields. A screenshot of the Record is not a substitute for a structured audit event, and an audit system should not copy payloads merely because the UI displayed them. Set retention and access rules for the audit stream itself.
The evidence boundary should influence the runbook. If your deployment cannot associate a human actor with a mutating Kafka request, state that limitation in the runbook and route the action through an approval service or infrastructure-as-code workflow that can. Do not infer a complete audit trail from the presence of a Console screen.
4Give each runbook a clear owner and recovery path
A Kafka UI is useful during incidents because it shortens the path from symptom to inspection. A rising Consumer lag can lead an operator to inspect group membership, Partition assignment, and recent deployment events. The same UI can shorten the path to a harmful action if the operator resets an Offset before confirming the cause. The runbook must define where investigation ends and mutation begins.
A practical boundary has three lanes:
- Observe: use the Console to inspect metadata, group state, Partition assignments, and approved diagnostic views. Link the evidence to the incident timeline.
- Change: use a controlled workflow for Offset resets, retention changes, ACL edits, and destructive Topic operations. Record the before state and the approval.
- Recover: verify application behavior after the change, compare Consumer lag and throughput with baseline signals, and retain the rollback decision.
The lane for a given operation should be explicit. A team may permit application owners to inspect their own Topics and request an Offset reset, while only the platform team can execute that reset in production. Another team may allow a self-service reset for replayable jobs but require an incident record for payment or notification consumers. Both policies can be valid when the business effect and recovery path are documented.
Use the Console for diagnosis when it improves response time, but keep durable desired state in the system your platform team already reviews. If Terraform, a deployment controller, or a change-management API is the source of truth for Topic configuration, a direct UI edit should either be prohibited or reconciled immediately. Otherwise the next apply may overwrite the emergency fix, or the UI may display a state that no longer matches the declared configuration.
Break-glass access deserves its own path. It should have a named approver, a time limit, an explicit reason, and a post-incident review. A permanent “admin” account shared by the on-call rotation is fast to use, but it collapses identity, approval, and execution into one credential. That design makes both incident analysis and access review harder.
5Separate Console network access from broker data access
A self-hosted Console introduces two network paths. The browser connects to the Console endpoint, and the Console process connects to Kafka brokers and any additional services it uses. These paths can have different authentication, firewall, DNS, and logging policies. Allowing a user to reach the web endpoint does not imply that the user can reach a broker, and placing the Console in a management subnet does not by itself prove that payload data remains inside the intended boundary.
Use this path map in the runbook:
| Path | Questions for the runbook |
|---|---|
| User to Console | Which identity provider, session timeout, network zones, and proxy logs apply? |
| Console to brokers | Which bootstrap address, Transport Layer Security (TLS) identity, Kafka principal, and ACLs are used? |
| Console to auxiliary services | Does the deployment query Schema Registry, Kafka Connect, or other APIs? Which credentials and network paths do they use? |
| Logs and audit | Where are access, authorization, and change records stored, and who can read them? |
| Break-glass path | How does an on-call engineer reach the Console when normal identity or network controls are unavailable? |
This map prevents a second common mistake: assuming a UI is “inside the cluster” because it can display Kafka data. The UI may be deployed beside the cluster, in a management environment, or behind a gateway. The security decision depends on the actual paths and credentials, not on the browser layout.
6Where AutoMQ control plane and data plane fit
The same boundary test applies when the Kafka-compatible data plane is AutoMQ. AutoMQ separates the product control plane from the Kafka data plane. AutoMQ Console and its management services handle lifecycle, resource, monitoring, and access-management workflows. AutoMQ Brokers serve Kafka client traffic in the data plane. The product control plane does not become a Kafka broker, and the Kafka data plane does not become a browser authorization system.
That distinction is useful when a team brings an external Kafka UI into an AutoMQ environment. The UI talks to Kafka-compatible broker endpoints and is governed by the Kafka authorization model configured for those brokers. AutoMQ Console can remain the system for environment lifecycle, resource ownership, and control-plane role-based access control (RBAC) or single sign-on (SSO) workflows. A user who can open a Console page is not automatically authorized to read a Topic, and a Kafka ACL that permits a broker request does not automatically grant permission to change a cluster through the product control plane.
The deployment boundary depends on the AutoMQ product form. In AutoMQ BYOC (Bring Your Own Cloud), the control plane and data plane run in the customer's cloud account and Virtual Private Cloud (VPC). In AutoMQ Software, both are deployed in the customer's private data center. Those boundaries affect where the Console endpoint, audit records, identity and access management (IAM) permissions, and network controls live. They do not change the basic rule that Kafka ACLs authorize Kafka requests and control-plane roles authorize management actions. The AutoMQ architecture overview describes this separation in more detail. The related Kafka UI operating models guide applies the same ownership questions to self-service workflows.
AutoMQ's Shared Storage architecture can change the operational consequences behind a runbook, but it does not remove the runbook. Broker scaling, storage placement, Partition reassignment, and recovery still need evidence and ownership. Evaluate those mechanics separately from the UI: first verify the Kafka operation and its authorization, then verify how the platform executes it in the data plane.
Run the evaluation in this order:
- Verify the UI's supported Kafka APIs and authentication mode against the target AutoMQ release.
- Map each UI action to the Kafka ACLs and effective principal that will reach AutoMQ Brokers.
- Map lifecycle and environment changes to AutoMQ Console, Terraform, or the approved control-plane workflow.
- Test the audit correlation between human identity, control-plane action, Kafka principal, and broker result.
- Run the rollback path before granting production mutation.
This sequence keeps the comparison fair. Redpanda Console, another Kafka UI, and AutoMQ Console may appear in the same operator workflow, but they do not perform the same role.
7Make the UI earn production access
A production Kafka UI should earn broader access through evidence. Start with read-only metadata, then add payload inspection only where data classification permits it. Introduce mutation through owned workflows, and allow break-glass execution only when the audit and recovery path has been rehearsed.
The opening question was who can press the button and what happens afterward. The answer is not hidden in the button label. It is in the chain from identity, to Console, to Kafka ACL, to broker result, to incident evidence. Redpanda Console can shorten the operator's path to Kafka state, but the organization still has to define the boundary around every action.
If you are comparing Kafka-compatible platforms or designing that boundary for your own environment, review the AutoMQ Kafka compatibility documentation against your action matrix. Then use the AutoMQ home page to request the next evaluation step.
8FAQ
8.1Is Redpanda Console the same thing as Kafka RBAC?
No. Redpanda Console is a web interface. Kafka ACLs are enforced by the broker for Kafka requests. An identity provider or application role may control access to the UI, but that role does not replace broker authorization. Verify the effective Kafka principal and its ACLs for every action that can mutate state.
8.2Can a read-only Console role read Kafka Record payloads?
Only if the Kafka principal and the Console deployment allow payload reads. Metadata visibility and payload access are separate decisions, and production payloads may require data-classification approval. Treat a payload view as data access, not as a harmless UI feature.
8.3Does a Kafka ACL provide a complete audit trail?
No. Kafka authorization logs can show the principal and operation that reached the broker, but they may not identify the human who initiated the request or the approval reason. Correlate identity-provider, Console or proxy, broker, and change-management records.
8.4How should a team compare Redpanda Console with an AutoMQ Console workflow?
Compare the action and evidence path, not the labels. Check which system handles UI access, which principal reaches the Kafka data plane, where ACLs are enforced, which control-plane roles govern lifecycle changes, and how a rollback is recorded. The same Kafka client semantics can sit behind different control-plane and data-plane boundaries.
