jerryshao opened a new issue, #12921:
URL: https://github.com/apache/gravitino/issues/12921

   ### Version
   
   main branch
   
   ### Describe what's wrong
   
   `SecretProvidersConfigServlet`, registered at `/configs/secrets/providers` 
in `GravitinoServer.initializeRestApi()`, is mounted outside the `/api/*` 
pathspec that carries the authentication filter chain, so it is reachable 
without authentication. It returns the full secret provider registry (name, 
type, non-secret `uri`) for every configured provider, with no 
operator-controlled way to disable or restrict it.
   
   Unlike `ConfigServlet` (`/configs`), whose public output is scoped to an 
explicit allowlist (`gravitino.server.visibleConfigs`), this servlet has no 
equivalent control. Its Javadoc claims it "uses the same auth model as 
ConfigServlet," but that comparison doesn't hold — `ConfigServlet`'s exposure 
is a deliberate, bounded choice; this one is not. On deployments using an 
external secret manager, the response can reveal internal Vault/OpenBao 
endpoint URIs to unauthenticated callers, and none of these requests are 
audited.
   
   This is split out from #12760, which fixes the broader structural problem 
(root-mounted servlets bypassing the entire filter chain, including audit). 
This issue tracks specifically adding an authorization/visibility control for 
this endpoint's data, analogous to `visibleConfigs`.
   
   ### Error message and/or stacktrace
   
   N/A — not a crash, an authorization gap.
   
   ### How to reproduce
   
   1. Start a Gravitino server built from `main` with authentication enabled 
and at least one secret provider configured.
   2. Send an unauthenticated `GET /configs/secrets/providers`.
   3. Observe the full provider registry returned with `200 OK`, with no 
corresponding audit log entry.
   
   ### Additional context
   
   Related to #12760. Only exists on `main` (confirmed via `git log` — no 
commits on `origin/branch-1.3`), so it should be resolved before this endpoint 
ships in any release rather than needing a hotfix.
   


-- 
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]

Reply via email to