Hi Sung, Re: beta - since OPA is not "on" by default, I think it should be enough to mention "beta" in docs / javadoc / examples that show how it gets enabled. Maybe add a ProductionReadinessCheck for it?.
Cheers, Dmitri. On Tue, Oct 7, 2025 at 10:08 PM Sung Yun <[email protected]> wrote: > Hi Yufei and Dmitri, > > Thank you both for following up on this thread! > > And thank you to everyone who’s taken the time to review the RFC - I’ve > incorporated much of the feedback to improve the document and made a few > minor updates to the PR as well. > > Dmitri - now that the RFC has been thoroughly reviewed, I’ve adopted the > feedback and formally opened the PR for review. I agree that marking the > initial implementation as beta makes sense. Could you clarify the process > for that - is it simply a matter of documentation? > > And yes, I’m also happy to follow up with a separate PR to add the > relevant documentation updates. > > Sung > > On 2025/10/03 16:28:52 Dmitri Bourlatchkov wrote: > > It's a very nice and useful proposal, IMHO. Thanks for driving it, Sung! > > > > I added some minor comments to the doc. The rough edges related to > > per-realm configuration and federated principals can probably be > addressed > > later. > > > > What is your plan for opening the related GH PR for general review (it's > > still a "draft" ATM)? > > > > In terms of bundling OPA into Polaris distributions, we discussed > > supporting flexing options for end users in the last sync call. At this > > state, though, I think standard Polaris images are still pretty > monolithic > > so I think OPA will have to be a built-in component, if we want to open > it > > to users of the binary distribution (which is fine from my POV). > > > > Custom downstream builds still have the option of including or excluding > > the OPA authorizer module from their build-time dependencies. > > > > Since the OPA authorizer configuration involves a schema for outgoing > > requests to OPA agents, it might be prudent to mark the initial > > implementation as "beta" to allow this schema to evolve quickly over the > > next few releases without incurring too much backward compatibility > > overhead. WDYT? > > > > Would you be open to contributing Polaris doc pages for OPA (later)? > > > > Cheers, > > Dmitri. > > > > On Wed, Oct 1, 2025 at 5:47 PM Sung Yun <[email protected]> wrote: > > > > > Hi folks, > > > > > > I'm seeking feedback on an RFC to add Open Policy Agent (OPA) as an > > > opt-in authorizer plugin for Polaris. The motivation is > > > straightforward: as deployments scale, RBAC alone struggles with > > > context (purpose of use, data sensitivity, workload identity) and > > > often devolves into role explosion. Policy engines like OPA enable us > > > to decouple policy from code and express richer attribute-based rules > > > in a Rego, improving auditability and testability without changing > > > Polaris’ catalog semantics. > > > > > > Delegating policy decisions to OPA will also enable organizations to > > > reuse their existing, centralized policy store. Polaris can run OPA > > > locally as a sidecar while OPA fetches bundles from the centralized > > > policy distribution pipeline, which may be a necessity due to a > > > streamlined governance strategy. > > > > > > The proposal is ready for review (so is the PR) and has been > > > intentionally designed to be safe to trial. The existing > > > PolarisAuthorizerImpl will remain the default and the proposed > > > OpaPolarisAuthorizer is strictly opt-in through configurations. > > > Implementation details, configuration, and security options are in the > > > RFC. > > > > > > I'd appreciate your review and feedback! > > > > > > Thanks, > > > Sung > > > > > > Google Doc: > > > > https://docs.google.com/document/d/1HadMFygjbuZathZZPanO6cFVorx0Ju0FopkICxX1tCE/edit?tab=t.0 > > > PR: https://github.com/apache/polaris/pull/2680 > > > > > >
