Using native rust cedar instead of rego?

[gtherond]

Managing the policy through OPA/Rego is nice, but wouldn't it be better to use a rust native cedar rather than the "Go based" solution?

Honestly, both are fine to me but to be frank, even if I like OPA/Rego, I need to admit that Cedar is easier to read and in the end clearer with complex and extensive policies such as the one we've got on Openstack.

[gtema]

thanks for the feedback. We have actually already invested pretty massive amount of time in preparing the whole OpenStack for OPA (like was demoed during Paris Summit).
OPA looks to be more wide-spread with support in K8, Ceph, Linux PAM, etc so a year ago I thought OPA is just having more chances in OpenStack compared to Cedar. I also like the possibility for OPA to get external data which simplifies integration of OpenStack with additional services by operators. It is also often considered as part of the ZeroTrust solutions. So in general I think OPA has slightly more chances to be integrated into the core of OpenStack (with Keystone being a control plane for them).
On the other hand what I want to achieve now is that we start looking at alternatives and depart from oslo_policy style. Maybe it is even worth considering it as part of the wider community of what are the preferences.

[gtherond]

Fair enough, thanks a lot for the answer.

PS: The only thing I could argue is CEDAR would allow keystone to manage the policy natively/internally without having to rely on compiled bundle and a sidecar tho.

[gtema]

I totally get that aspect. It is really a head-to-head run with OPA winning slightly (in my eyes) in the wider OpenStack context.

As you have most likely seen I am thinking actually about embedding opa binary into the Keystone container so that it can start it itself not relying on the sidecar. But this is only a "convenience" point.

[gtherond]

Yep, but it's kinda more that a "convenience" point as having a sidecar service managing the policies check/info is awkward for any dev/ops running Openstack since a long time.

Is this project an "Official" Openstack one or just you/your company trying to refresh the services?

I know you've presented it during a Openstack summit but as you're using your own whole github based workflow and not the official gitea I was wondering as it is a bit unusual (but frankly refreshing ;-) as contributing using gerrit can be a bit cumbersome at some point) :D

[gtema]

It is not a company driven project, but an individuals community (keystone cores included) trying to add features that can't be implemented with current Keystone architecture and take other advantages the Rust brings (security and performance).

Right now this is on the way of becoming the official OpenStack project once https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/WMU4UOOTE2LGJXVRVNQ23VOG4N3WBL57/ lands (feel free to comment there). For now you can see it as an OpenStack affiliated project that can't be made official unless a governance change lands. Once Rust is allowed this project would incorporate under the Keystone team either as an emerging technology, parallel delivery or whatever else

[gtherond]

Arffff, it's so bad you stumble upon such issues with the "governance" Fair enough, I like this initiative as it choose to go the rust way which IMHO (with golang) as you listed it, have a lot of advantage over python (Which I'm a huge fan nonetheless, but still) as it produce an easier and cleaner way to dev > build > ship for all the services be migrated as this one we would already benefit from a proper and clean Kubernetes Openstack Operator.

Anyway, thanks a lot for your work, and having taking time to discuss this!