Integrate rond with routers in golang services

[davidebianchi]

Is your feature request related to a problem? Please describe. At the moment, to use rond it is required to have a sidecar near each service. This sidecar is an additional operation inside the pod, and rond consumes resources.

Describe the solution you'd like I'd like to integrate rond inside our services. As first step, we could integrate in services written in golang with some middleware authorization step. As the next step, we could see also to create a Wasm lib to use it also in services written in other languages.

[fredmaggiowski]

Hey, this is coherent with the recent refactor that has been done to allow using rond as a server-side library; I was thinking about creating a sdk package that could expose specific APIs to perform policy evaluation.

On top of this sdk we can build another package holding several middlewares for supporting different frameworks and technologies.

The SDK could be something like: rond.Eval(request, ...)

[davidebianchi]

I'm thinking about the interface we could expose by the sdk, I'll write it in this issue when I have some update to it.

package sdk

type PolicyResult struct {
	QueryToProxy string
	Allowed      bool
}

type User struct {
	UserID       string
	UserGroups   []string
	UserRoles    []Role
	UserBindings []Binding
	Properties   map[string]any
}

type Rond interface {
	EvaluatePolicy(method, path string, userInfo User) (*PolicyResult, error)
}

I'd like to separate the http interface from both the sdk and the core, but the user should process method and path and retrieve user before use the sdk (probably, with some per router integration). What do you think about?

[fredmaggiowski]

I'd like to separate the http interface from both the sdk and the core, but the user should process method and path and retrieve user before use the sdk (probably, with some per router integration). What do you think about?

I agree in decoupling from the underlying Request types, however the proposed EvaluatePolicy method interface is a bit too narrow; policies can now be written on headers and body as well and they are missing from this struct.

I'd create a

type RequestInfo struct {
          Method string
          Path string
          QueryParams map[string]string
          Headers map[string][]string
          Body []byte (or even a bytes.Buffer)
}

[davidebianchi]

path and method are used to find the policy to evaluate. So, I think that we should pass the Input directly to the sdk, or as []byte using the core.CreateRegoQueryInput function. In this way, the sdk does not contains with how to retrieve data from the input request.

We should also have a NewEvaluator function exposed by sdk, which creates the correct evaluator and that we could use with the EvaluatePolicy method

[fredmaggiowski]

So, I think that we should pass the Input directly to the sdk, or as []byte using the core.CreateRegoQueryInput

it makes sense but the function should be coupled with the http.Request object (maybe with a generic implementation allowing for different request types?) At this point the whole EvaluatePolicy could be generic based on the Request type making the SDK completely autonomous on how to process the request to create the input

[fredmaggiowski]

This is the parent issue for several changes that are being done:

• #211
• #213
• #219
• #220

The whole project can be followed in the Project Board