Hi all,

Following the review discussion on #5246 [1] GET /v1/config previously had
no AuthZ at all, so any authenticated principal that knew a warehouse name
could read the full catalog properties (defaults). Not great for
multi-tenant setups.

Proposal:

   1. Always-on (no new privilege needed for the sensitive bit): Soft-hide
   defaults unless the principal has CATALOG_READ_PROPERTIES (same idea as
   management getCatalog). Prefix, endpoints, etc. are still returned so
   clients can bootstrap.
   2. New privilege CATALOG_READ_CONFIG (op GET_CATALOG_CONFIG), grantable
   now. Hard 403 on the whole endpoint only if:
   polaris.features."ENFORCE_CATALOG_CONFIG_AUTHORIZATION" = true Default is
   false, so operators can grant first (or rely on catalog-level content
   subsumption) and then turn enforcement on.
   3. Later we flip the default to true and drop the flag.

Why not hard-on in one shot:

   - Catalog-path checks don’t see table/ns-scoped grants → day-one enforce
   can break least-privilege clients on upgrade.
   - Ranger still maps both ops to catalog-properties-read (no dedicated
   access type yet) → need time to update the service def + grants.

Basically two-phase behaviour in one binary: permissions available now,
enforcement when people are ready.

I can also split GET_CATALOG_CONFIG into a follow-up PR if that is
preferred — the flag makes that easy either way.

Mainly interested whether default-false + later flip is acceptable, or if
hard-on in a single release (with the breakage risk) is preferred. [1]
https://github.com/apache/polaris/pull/5246

Thanks, Vignesh

Reply via email to