Building Block: Proposal document for Gatekeeper Building Block

[XavierGeerinck]

This proposal documents introduces the "Gatekeeper" building block which helps developers to implement "Authorization" requests for their application, assisting the developer by implementing core authorization requirements:

Am I as a user able to access resource X?
Which resources am I as a user able to access? (commonly known as an "ARQ" or "Access Request Query")
It works through added APIs in the Dapr runtime that work together with a state store to store the policies.

Background

While working with software, one of the most common issues that pops-up is "Authorization". After a user is authenticated, how do we know that this user has access to a specific piece in your code? For this, developers typically reside towards implementing:

• RBAC (Role-based Access Systems)
• ABAC (Attribute-Based Access System)

The above is often considered a lengthy task, as users have to ensure that everything works as intended and test it carefully. A leak in this piece of code could have serious consequences.

Dapr runs as a sidecar architecture, typically close to the software. This software often interacts with users (Backend API) or as microservices doing an isolated piece of code.

Therefore, I would love to propose a new Building Block: "Gatekeeper", where a user can simply call it through one of the Dapr SDKs and receive a response if they are allowed to access a certain feature or not.

Vocabulary

• Gatekeeper Principal: Who is trying to access the resource and what are his roles?
• Gatekeeper Action: What is the action the principal is trying to perform? (typically CREATE, READ, UPDATE, DELETE, MANAGE)
• Gatekeeper Resource Kind: What type of resource is the principal trying to access? (e.g., a user)
• Gatekeeper Resource Type: What resource is the principal trying to access?

Signed-off-by: Xavier Geerinck [email protected]

[XavierGeerinck]

@dapr/maintainers-dapr thoughts?

[yaron2]

@XavierGeerinck will be reviewing this soon, as back for vacation now.

[XavierGeerinck]

Any update @yaron2 or others?

[jogobella00]

That would be great to have it in Dapr already, would it be possible to have this PR approved?

[Yunzlez]

+1 Also waiting for this!

[XavierGeerinck]

Any opinions on this? @yaron2 @artursouza

[artursouza]

Can it follow a spec 100%, maybe Cerbos? Similar to how we have 100% compatible cloud event in pubsub. Then, show how this can be integrated with existing 3rd party frameworks. I think the biggest value add if it can interop outside the Dapr SDKs.

[XavierGeerinck]

I think it would indeed allow for a 100% compatibility with their spec, the question is just what the added value of Dapr would be then. Integrating it natively in Dapr could be more seen as building block, while a cloud event is more seen as interop layer for integration

[berndverst]

Can someone copy the proposal text also into the description here so we can discuss this better?

Also, I'm hesitant for us to merge proposals without any identified stakeholders who are committed to driving the engineering work / implementation.

I don't fully see / understand the value of this proposal for Dapr. An interop layer makes more sense to me.

[XavierGeerinck]

Can someone copy the proposal text also into the description here so we can discuss this better?

Also, I'm hesitant for us to merge proposals without any identified stakeholders who are committed to driving the engineering work / implementation.

I don't fully see / understand the value of this proposal for Dapr. An interop layer makes more sense to me.

Done (partly though as it makes no sense for an entire duplication)

The ideation (and community request - see references in the proposal) are around providing an microservice angostic way of authorizing calls. The value for Dapr is immense as it is a component required by many people and would even improve Daprs current authorization mechanisms.

An interop layer could work as well, but this is where the discussion comes in in if Dapr wants this as USP (extra building block type) or not.