Restrict BasicAuth cluster access to unrestricted users

[Vamsi-klu]

Fixes #14595

What changed

This PR tightens BasicAuth access checks so table-scoped users do not automatically receive cluster-level access.

BasicAuthPrincipal now exposes whether a principal has unrestricted table access. The static and ZooKeeper-backed BasicAuth access-control factories use that information when evaluating non-table and cluster targets:

• Table checks still evaluate the requested table name and action permission.
• Cluster/non-table checks now require unrestricted table scope plus the requested action permission.
• Fine-grained action checks are wired through the same scope rules for both static and ZK BasicAuth factories.
• Existing coarse permissions remain compatible by mapping common fine-grained action names back to coarse READ, CREATE, DELETE, or UPDATE permissions when an exact action string is not configured.

Why it matters

A user who is scoped to one or more specific tables should not be treated as authorized for cluster-wide operations just because they have a valid BasicAuth principal. Cluster endpoints can expose or mutate state outside the user's table scope, so the authorization check must distinguish table-level access from unrestricted/cluster-level access.

This keeps table-scoped BasicAuth useful for table operations while closing the privilege boundary for cluster and other non-table targets.

The coarse-permission compatibility mapping matters because existing BasicAuth configs commonly use broad actions such as READ and UPDATE. Requiring every deployment to switch immediately to exact fine-grained action names would make the security fix unnecessarily disruptive.

Impact

Table-scoped BasicAuth users can continue accessing their allowed tables.

Table-scoped users are denied cluster-level and non-table operations unless they also have unrestricted table scope.

Unrestricted principals with the required action permission can still access cluster/non-table targets.

Both static BasicAuth configuration and ZooKeeper-backed BasicAuth configuration follow the same scope and action rules.

Testing

• ./mvnw -Dmaven.repo.local=/tmp/m2-pinot-14595 -pl pinot-core,pinot-controller -am -Dtest=BasicAuthTest,BasicAuthAccessControlFactoryTest -Dsurefire.failIfNoSpecifiedTests=false test
• ./mvnw -Dmaven.repo.local=/tmp/m2-pinot-14595 -pl pinot-core,pinot-controller spotless:apply checkstyle:check license:check
• git diff --check

The tests cover static and ZK-backed BasicAuth behavior, table-scoped users on allowed tables, denial of cluster access for table-scoped users, denial for excluded-table principals, fine-grained table actions, and cluster updates for unrestricted admin principals.

---

Drafted-by: Codex (GPT-5); human-reviewed by Vamsi-klu before marking ready for review

[Vamsi-klu]

Review request: @soumitra-st @Jackie-Jiang

GitHub did not allow this account/integration to add requested reviewers through the reviewer section, so I am tagging the relevant reviewers here for visibility.

This PR fixes #14595 by tightening BasicAuth cluster/non-table access checks so table-scoped users do not automatically receive cluster-level access, while keeping table-level access behavior and coarse permission compatibility intact. Review from the BasicAuth/FineGrainedAccessControl side would be especially useful to confirm the intended cluster-level authorization boundary and compatibility with existing role-based access-control deployments.

---

Drafted-by: Codex (GPT-5); human-reviewed by Vamsi-klu before posting