Hi Vignesh It's actually a valid problem: CatalogConfigHandler.getConfig() doesn't authz at all today. It means any authenticated principal who guesses a warehouse name gets the catalog's properties. Clearly worth to fix. But, also, it returns PolarisEntity.getPropertiesAsMap() (should be user-visible properties), without internalProperties. So the exposure is admin-set config like default-base-location, not secrets. So, not super "criticial".
I think it makes sense to "hide" defaults behind CATALOG_READ_PROPERTIES. It's similar to getCatalog path. This should be the only thing in the PR imho. I don't think the new CATALOG_READ_CONFIG property makes sense. /v1/config is the Iceberg bootstrap call, every client makes it before doing anything. Your PR leans on TABLE_READ_PROPERTIES, but that only works for catalog-level grants. A principal granted read one namespace or one table gets a 403 and cannot bootstrap at all. So I don't think it's a good idea, it's actually a unnecessary breaking change. Regards JB On Fri, Aug 14, 2026 at 2:48 PM vignesh a <[email protected]> wrote: > > 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
