Kong Manager is a browser interface for administering Kong Gateway. The Admin API behind it controls services, routes, plugins, consumers, and credentials. Exposing the manager without a strong authentication and network boundary can turn a configuration convenience into a gateway-wide control problem. A discovery count is only the first step.
Manager access is an administrative path
Kong documentation describes Kong Manager as a gateway management interface and the Admin API as the REST interface for gateway configuration. When RBAC is enabled, an admin token identifies the administrator and the authorization rules apply. Kong Manager can be secured through an authentication plugin, and RBAC must be enabled to enforce its authorization rules.
A deployment should decide who reaches the manager, which identity provider authenticates them, and what each role can change. The Admin API should also be protected. A proxy rule for the manager does not automatically protect the Admin API if both use the same host and the API path remains reachable.
A bounded ZoomEye observation
On 2026-10-31, app="Kong Gateway" returned 595737 matches and title="Kong Manager" returned 1543. Both queries used page 1, page size 1, and sub_type=all. The app count is much broader than the manager title. It may include gateway assets, references, and pages that are not management interfaces. The title count is a narrower lead but still not proof of an unprotected manager.
This contrast is useful in reporting. Do not present the gateway count as the number of exposed managers. Keep each query labeled with its field and count. The manager title observation is the more relevant starting point for a UI review, while the app query can support a broader Kong inventory.
Review the identity and network path
Map public hostnames to the manager and Admin API listeners. Confirm that the manager is not reachable from the general internet unless there is an explicit operational need. If remote access is required, put it behind a VPN or an identity-aware proxy and enforce authorization at the application layer.
Review the administrator accounts. A super administrator has broad control across workspaces. Individual admin accounts should have roles that match their work. Use short-lived sessions where possible and remove accounts that no longer need access. The manager should not rely on a shared basic-auth password as the only control.
Test the API separately
Send an unauthenticated request to an administrative endpoint and a read-only endpoint. Test a valid account with a role that should not be able to create a service. Check workspace boundaries and confirm that a role in one workspace cannot modify another. Record the HTTP status and the request path without storing credentials.
Inspect logs around admin changes. A configuration update outside the deployment pipeline, a new administrator, or a change to RBAC settings deserves attention. The manager is an interactive path, but a compromised API token can make changes without ever opening the UI.
Use ZoomEye as a discovery input
ZoomEye can show that Kong-related assets exist and help prioritize a review. It cannot determine whether the manager is authenticated, whether RBAC is enabled, or whether an administrator used a weak password. The internal identity inventory and controlled API tests answer those questions. Combining the two keeps the observation factual and the response actionable.