roryqi opened a new issue, #12777: URL: https://github.com/apache/gravitino/issues/12777
### Version main branch ### Describe what's wrong `GET /configs` is unauthenticated by design so the Web UI can determine how to render login. However, it also publishes `gravitino.authorization.serviceAdmins`, exposing the principals with server administration privileges to anonymous callers. This is an information disclosure rather than an authorization bypass: authenticated `/api/*` endpoints remain protected. The tarball configuration template also includes `gravitino.authorization.serviceAdmins` in `gravitino.server.visibleConfigs`, which exposes the administrator list even when authorization is disabled. ### Error message and/or stacktrace An unauthenticated `GET /configs` response includes: ```json "gravitino.authorization.serviceAdmins": ["admin", "service-account-trino"] ``` ### How to reproduce 1. Start Gravitino from `main` with authorization enabled and configure `gravitino.authorization.serviceAdmins`, or use the tarball configuration template. 2. Call the endpoints without credentials: ```bash curl -s http://<host>:8090/api/version curl -s http://<host>:8090/configs ``` 3. Observe that `/api/version` returns 401 while `/configs` returns 200 and exposes `gravitino.authorization.serviceAdmins`. ### Additional context `web-v2` currently uses this list to decide whether the authenticated user can create a metalake. The UI should instead receive only whether the current authenticated user is a service administrator, without downloading the complete administrator list anonymously. Related enterprise issue: https://github.com/datastrato/gravitino-enterprise/issues/1621 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
