Add ability to filter policies in the Admin API ListPolicies RPC about cerbos HOT 5 CLOSED

I now remember why we didn't add filtering in the first place. Doing that on disk-based policies would require reading all of them -- which would not scale as the number of policies increase.

I think we should keep ListPolicies as it is and introduce a different RPC (FilterPolicies?) that is only implemented on stores that can be easily queried.

from cerbos.

Makes sense. We're not (directly), but I started tinkering with the cgo-dependent package for name matching and came across this. No blockers - was just intrigued.

from cerbos.

This RPC is currently enabled for non-mutable stores. I can't decide if there's any practical use for this filtering for "static" policy sets.

On one hand, users can review their stores (git or otherwise) to see what's there, but on the other hand, this filter might be useful for quickly getting a view on what's there (particularly if they have a hefty number of policies deployed).

I'm erring on the side of implementing this only for mutable stores for now. Thoughts?

from cerbos.

TL;DR: I'm intrigued about why we set CGO_ENABLED=0.

Enabling REGEXP in SQLite (via a user defined function when using https://github.com/mattn/go-sqlite3) requires cgo which we disable (CGO_ENABLED=0). This got me thinking - is there a particular reason we disable this?

There are numerous ways to work around this (using a cgo-free port of SQLite, disabling for unsupported drivers, post-filtering result sets in code, etc), but I'm just intrigued.

from cerbos.

It's to avoid platform incompatibilities and security issues. We ship a minimal scratch image that doesn't have a libc.

The version of SQLite we use is the CGO-free one. Are we referencing the CGO-based driver anywhere in the code?

from cerbos.