provide a RBAC builder

[mstrYoda]

Currently I am writing RBAC configuration in golang code (like Istio does). It would be nice to have a fluent RBAC builder.

For example I wrote those configuration:

It would be better like below (it is just an example, it is not show exact implementation, real impl. can vary):

Do you guys planning to do something like that? I would like to implement it.

Any thoughts?

[kyessenov]

cc @yangminzhu

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[mstrYoda]

@yangminzhu Any thoughts?

[yangminzhu]

sorry for the late reply it got lost in my inbox. I like this idea and I think it will be very helpful for people to use the RBAC filter.

One thing to look at is the Istio authz code that already provides a simple library and abstraction of the RBAC API: https://github.com/istio/istio/tree/master/pilot/pkg/security/authz. Feel free to send out a doc or a PR directly, I guess the code could probably go to https://github.com/envoyproxy/go-control-plane/tree/main/pkg?

[alecholmez]

I'd like to actually revisit this but potentially widen the scope? Would people be interested in other "builders" as well such as circuit breaking policies, outlier detection, rbac, etc..? Anything with a complicated structure might be worth providing an API for

[alecholmez]

For this API I imagine something like this:

Builder

// Builder defines a global API for various policy engines
// that are targeted towards various service mesh core functionality pieces.
// These can be used by xDS/Envoy based control-planes to help
// internally construct config.
// Builder cannot tie itself to specific pieces of config, but
// should return generic bytes (proto config).
type Builder interface {
	// Build returns a generic byte array marshaled from protobuf.
	Build() ([]byte, error)

	// BuildJSON returns JSON bytes rendered from `protojson.Marshal()`.
	BuildJSON() ([]byte, error)
}

type RBACBuilder struct {
	Policy *rbacv3.RBAC
}

// NewRBACBuilder is a constructor for RBACBuilder that takes various
// args for a singular RBAC policy.
func NewRBACBuilder() *RBACBuilder {
	return &RBACBuilder{}
}

func (b *RBACBuilder) Build() ([]byte, error) {
	return nil, nil
}

func (b *RBACBuilder) BuildJSON() ([]byte, error) {
	return protojson.Marshal(b.Policy)
}

Idea

That interface is subject to change in this stage but providing a mechanism where we can let users consume a singular policy engine builder would enable a nice abstraction for internal code segmentation regarding individual policy types: rbac, circuit breaking, etc...

A user could do something like this:

// RBAC policy options go in this struct
b := NewRBACBuilder()

// We generate our policy, below. This API allows consuming functions to accept a 
// policy.Builder interface and not tie itself to an RBAC specific policy.
policy := b.Build()

The neat thing about this interface is it sort of lays the ground work for building config external to Envoy API objects. (Custom types, etc...)

Any thoughts around this?

[jpeach]

Any thoughts around this?

I'm a bit skeptical about this. The Envoy protobuf API is huge and tracking it with builder interfaces sounds like a lot of work. Being an upstream project, we can't easily simplify the API, because different users will eventually need every part of it, so it's not clear to me that in the end a builder patter would actually be more succinct than just writing out to protobuf structs.

I have no objection to anyone experimenting in this area, or taking on the work if they want to though :)

[alecholmez]

That's definitely true, the Envoy API is expansive and difficult to keep up with. You are right in thinking that if we went this route we'd take on the responsibility of managing that lifecycle. I might experiment to see if this is feasible but in my head the policy builders tie into this project becoming the Envoy reference control plane since we ultimately become responsible for maintaining Envoy config, as well as providing external APIs for consuming control-planes. This certainly broadens project scope but I think a lot of people would benefit from this