pflynn-virtru commented 7 months ago

Open Policy Agent removal

Context and Problem Statement

Currently, we use OPA for our entitlement PDP.

This is the next iteration, soon-to-be-merged. Note most logic is removed from .rego, basically it is just glue at this point.

Relevant ADR

Entitlement Policy Deployment Model https://github.com/opentdf/platform/issues/472 Configuration Service https://github.com/virtru-corp/adr/blob/main/docs/decisions/ar-8-config-service-v2.md

Decision Outcome

📜 No change
- Keep OPA
- Re-evaluate after upcoming major milestone

Decision Notes

🟩 Infinite flexibility in entitlement PDP
🟨 More data points needed - this will come after the next major milestone
🟨 Support should be like other sub-system integrations, ex. database, IdP
🟥 Developers' velocities will be impacted when working around OPA

Decision Drivers

OPA development challenges
- type conversion
- built-in development
- testing
- small rego codebase < 50 loc
OPA customer challenges
- non-support if changed
OPA capabilities
- Federation of policies
- Policy signing
OpenTDF subject mappings solution
Possible performance bottleneck (not enough data)

Considered Options

Remove OPA library
Optional OPA library
Optional OPA service integration
Support and Keep OPA

⚖️ Remove OPA library

Create a pure Go implementation of the Entitlement PDP. Mimic what is done with Access PDP

🟩 Developers happy
🟨 Moves integration point to Entity Resolution Service (ERS)
🟥 One less integration point

⚖️ Optional OPA library

Create a pure Go implementation of the Entitlement PDP. Leave OPA-Entitlement PDP. Create a configuration to enable.

authorization:
  entitlement:
    # native Golang
    pdp: default
    # unsupported OPA
    pdp: opa

⚖️ Optional Entitlement PDP Service integration with OPA example

Create a pure Go implementation of the Entitlement PDP. Remove OPA-Entitlement PDP. Create a configuration to enable.

authorization:
  entitlement:
    # native Golang
    pdp: default
    # unsupported
    pdp: remote
    url: https://pdp-opa-service/entitlement

The design could be similar to the v1 entitlement PDP https://github.com/opentdf/backend/tree/main/containers/entitlement-pdp

🟩 Integration point with other services than OPA is doable.
🟨 Previous design
🟥 Supported?

⚖️ Support and Keep OPA

🟩 Supported!

jrschumacher commented 7 months ago

Great work @pflynn-virtru. I think you are calling out some important trade-offs. It seems that if we chose Option 1 we could cue up additional work to implement Option 3. Would this enable customers to hook into their existing authorization service like Strya, Permit.io, or AuthZed?

strantalis commented 7 months ago

@pflynn-virtru Thanks for putting this together. In option 3 it would be neat if we defined a set of protobuf that someone could implement. This way we would have that strict contract when calling out to those external services.

I believe istio does something similar here with the external authorizer.

ttschampel commented 7 months ago

I think we either do nothing or option 1.

It sounds like OPA is causing to much friction at the moment for our developers; if this is true then option 1 seems like the only choice.

We have not fully implemented and tested a full set of scenarios E2E flows through the Authorization Service RPCs; given this current state I think only option 1 really makes sense. The ERS will capture the complexity and customization for near term deployments. Until we fully understand what should be easily configurable (ABAC auth, entitlements, entity resolution, etc.)

An example would be someone has their own entitlements service already. Does the entitlement service speak ABAC and the Attribute space within the deployment? Should those entitlements be transformed via subject mappings? At a certain point someone could just use the existing spec and plugin in their own RPCs per the protobuf service apis.

damorris25 commented 7 months ago

I'd advocate doing nothing until we have a fully working platform that is stable, reliable, and well-documented. At that stage, iterating on improvements to the platform would make sense.