CMAK, formerly Kafka Manager, is a web application for managing Apache Kafka clusters. It stores cluster connection settings and presents topic, consumer group, partition, and broker operations through a browser. The application is not the Kafka broker, but it can hold credentials and issue administrative requests on the broker's behalf.
The CMAK configuration supports basic authentication and LDAP-backed authentication. These controls protect the CMAK application. They do not automatically map every CMAK user to a narrow Kafka ACL. The Kafka client configured inside CMAK may use a service credential, a SASL identity, or a TLS certificate that is shared by everyone who reaches the UI.
That distinction is the main review point. A user who cannot connect to Kafka directly may still be able to perform an operation through CMAK if the application's broker credential is broad. The effective permission is the intersection of the CMAK authorization, the Kafka principal, and the operation the UI exposes. If CMAK has one administrator identity for all users, the Kafka ACL cannot distinguish them.
Inventory every configured cluster and the principal used for each connection. Record whether the connection is read-only, whether it can alter topics or consumer groups, and which Kafka ACLs apply. Separate production and non-production clusters. Test a view-only CMAK user against a topic creation or partition change path, including a direct HTTP request rather than only the visible button.
Protect the configuration and secret files. CMAK can store broker credentials in its configuration. A file that is readable by the application process should not be readable by every local user. Rotate the Kafka credential when an administrator leaves or when the CMAK deployment is rebuilt. A backup that contains the connection secret should be protected like the live configuration.
The network position matters because CMAK is a control plane. Place it on a management network or behind an identity-aware proxy, bind it to the intended address, and restrict outbound access to the configured Kafka clusters. An open proxy path from CMAK to arbitrary hosts can turn a management UI into a useful foothold during an incident.
The evidence for this article is a count-only ZoomEye observation. The query was title="CMAK", with sub_type=all, page 1, and page size 1, observed at 2026-11-10T22:43:49Z. It returned 1,508 matching records. The query found an exact-title footprint; it does not prove that each result is CMAK, that authentication is disabled, or that the Kafka principal is privileged.
CMAK's convenience comes from holding Kafka authority in one place. That is also its risk. Limit who can use the UI, make the Kafka principal match the intended role, protect the stored credentials, and verify that the broker ACLs still enforce the boundary when the UI is bypassed.