Apache Pinot controller and broker need separate authorization reviews
Apache Pinot serves real-time and batch analytical queries. Its controller manages cluster metadata, tables, and segments. Its broker accepts SQL queries and returns data. The two roles have different exposure consequences, and the product documentation treats their authentication and ACL configuration independently.
Pinot's authentication guide says HTTP Basic authentication and ACLs are available for controller and broker access. Authentication is disabled by default for easier setup, and the security hardening guide notes that the default access factory allows all access. A production deployment therefore needs an explicit check that authentication, authorization, TLS, and internal service credentials are enabled.
What ZoomEye observed
The 2026-11-12 count-only probe used sub_type=all, page 1, and page size 1. app="Apache Pinot" returned 1,337. title="Apache Pinot" returned 1,150. http.body="Apache Pinot" returned 1,450.
Search dork: app="Apache Pinot".
Search link: ZoomEye Apache Pinot app query.
Title query: title="Apache Pinot".
Search link: ZoomEye Apache Pinot title query.
These are matching assets, not evidence that the default access factory is active. The next step is to identify which component is listening and which access-control class is configured.
Protect the controller
The controller API can create tables, inspect segments, and change cluster state. A caller who can modify a table definition may alter how data is ingested or queried. A caller who can inspect segment metadata may learn tenant, schema, or volume information even without reading rows.
Enable authentication on the controller API and restrict ACLs by table and action. Review the configuration source in Git and the running process. A secure-looking template does not protect an instance that was started without the property.
Protect the broker
The broker returns query results and may expose a controller web UI query console when both components are reachable. The Pinot documentation says a user who accesses data through the controller's query console must have matching credentials and read permissions on both controller and broker. That is an important compatibility condition, not a reason to share a broad administrator account.
Test a read-only broker user, a table-specific user, and an administrator separately. Confirm that the broker denies an unauthenticated query and that a user cannot read a table outside the configured ACL. Check row-level security where the use case requires tenant separation.
Internal paths and TLS
Pinot components authenticate to each other through their own configuration. A segment fetcher or task token can be as sensitive as a user password. Protect these credentials and limit their scope. Use TLS for controller, broker, and internal service traffic where the deployment supports it, then verify certificate trust and hostname validation.
Place controller and broker endpoints on the network paths they need. A broker used by an internal BI service does not need a public listener. A controller used only by administrators should not share a public load balancer with application traffic.
Review evidence
Record the component, port, access-control implementation, TLS state, and the test result for an authenticated and unauthenticated request. Keep the product query and the effective configuration together. The product count gives a population; the configuration gives the risk decision.
Top comments (0)