Hi everyone, Thanks for all the thoughtful feedback on the OpaPolarisAuthorizer RFC[1] and PR[2]. There’s been a healthy discussion around the project structure, so I’ve added an RFC addendum summarizing the options and trade-offs to help us reach consensus and move the PR forward.
My recommendation is Option 3, a split approach where the OPA implementation lives in polaris-extensions-auth-opa and integration tests in polaris-runtime-services. This keeps the architecture extensible and avoids circular dependencies. Most OPA logic will stay outside core for now, making it easy to migrate later if we decide to adopt it as a core component. Please take a look at the RFC addendum and PR #2680 and share any final thoughts. If there’s general agreement, I’d like to proceed with merging and start gathering real-world feedback. Thanks again for all the reviews and feedback! Cheers, Sung [1] https://docs.google.com/document/d/1HadMFygjbuZathZZPanO6cFVorx0Ju0FopkICxX1tCE/edit?tab=t.0#heading=h.o1ltugri8fl3 [2] https://github.com/apache/polaris/pull/2680 On 2025/10/08 22:17:58 Yufei Gu wrote: > Sung, thanks for working on this. Did one round of review. > > Dimitri, it makes sense to mark it as "beta". It's a big feature, we > couldn't finish it in one PR. We could focus on the first PR, and add more > later. > > Yufei > > > On Wed, Oct 8, 2025 at 1:45 PM Dmitri Bourlatchkov <[email protected]> wrote: > > > 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 > > > > > > > > > > > > > > >
