Hi All, I approved [5246] in GH.
>From my POV the PR offers a reasonable path towards tighter authZ checks on the /config endpoint. It does not break any APIs at this time. I propose merging it on Oct 28. [5246] https://github.com/apache/polaris/pull/5246 Thanks, Dmitri. On Wed, Oct 21, 2026 at 9:17 PM Dmitri Bourlatchkov <[email protected]> wrote: > Hi Yufei, > > I'm not sure how we (Polaris community) can check the behaviour of (all) > existing clients. > > PR [5246] provides ways to configure AuthZ grants in internal RBAC and OPA > such that Polaris' behaviour would be the same as before the change. > CHANGELOG entries inform users of this change. The onus is on users to > validate their specific clients and use cases and configure the system > appropriately. Corresponding Ranger Authorizer changes are to follow soon. > > Note that config defaults result in _old_ Polaris behaviour now. Changes > to default behaviours will be introduced only after the next release. Users > will have enough time to prepare. > > Heads up: PR [5246] approaches a mergegeable state from my POV. Only minor > merge conflicts remain. > > Cheers, > Dmitri. > > [5246] https://github.com/apache/polaris/pull/5246 > > On Fri, Sep 4, 2026 at 6:22 PM Yufei Gu <[email protected]> wrote: > >> > 1) Always on: soft-hide catalog properties (defaults) unless the >> principal >> has CATALOG_READ_PROPERTIES. Prefix / endpoints still returned so clients >> can bootstrap. >> >> The hiding may break existing IRC clients as well, given that clients >> won't >> be able to get any "serve default" and "server overrides" now in case of >> table-only permission. >> >> Can we double check this behavior change(hiding catalog properties) won't >> break existing IRC clients or cause a meaningful client-side behavior >> changes? >> >> Yufei >> >> >> On Fri, Sep 4, 2026 at 11:03 AM vignesh a <[email protected]> wrote: >> >> > Hi, >> > >> > Thanks all for the feedback >> > >> > On Yufei’s point: GET_CATALOG_CONFIG_PROPERTIES is an authorizable >> > operation, not a new privilege. The RBAC mapping reuses the existing >> > CATALOG_READ_PROPERTIES privilege (same idea as management getCatalog). >> > The separate operation is mainly for non-native authorizers >> (Ranger/OPA), >> > where the SPI is operation-based. Dmitri already covered that on-thread. >> > >> > On JB’s concern about CATALOG_READ_CONFIG: I agree /v1/config is the >> > Iceberg bootstrap call, and a hard 403 there is painful for principals >> > that only have table- or namespace-scoped grants. Catalog-path AuthZ >> does >> > not see those scoped grants, so day-one enforcement would break those >> > clients. That is why the PR keeps ENFORCE_CATALOG_CONFIG_AUTHORIZATION >> > default false - the privilege is grantable now, but the endpoint itself >> > is not hard-gated until an operator opts in. >> > >> > So today the PR is really two layers: >> > >> > 1) Always on: soft-hide catalog properties (defaults) unless the >> > principal has CATALOG_READ_PROPERTIES. Prefix / endpoints still >> > returned so clients can bootstrap. This is the actual disclosure fix. >> > >> > 2) Opt-in: hard-gate the whole endpoint behind CATALOG_READ_CONFIG when >> > the flag is true (for folks who want every REST path covered by >> AuthZ). >> > >> > JB’s suggestion to ship only (1) and drop (2) is a fair alternative if >> > the list prefers zero bootstrap risk. I’m fine either way: >> > >> > A) Keep both, flag default false, open a follow-up to flip the default >> > later (current PR shape), or >> > B) Narrow #5246 [1] to properties soft-hide only; revisit endpoint >> > hard-gate >> > in a later DISCUSS if we still want it. >> > >> > In my pov: A matches “all REST endpoints should eventually have AuthZ” >> > without breaking upgrades day one, but I’ll switch to B if that’s the >> > preferred consensus. >> > >> > WDYT?? >> > >> > https://github.com/apache/polaris/pull/5246 [1] >> > >> > Thanks, >> > Vignesh >> > >> > On Thu, 3 Sept 2026 at 20:06, Jean-Baptiste Onofré <[email protected]> >> > wrote: >> > >> > > 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 >> > > >> > >> >
