Thanks!

If you have strong opinions, please post them. We'd love to have the input.

We've discussed just simple things like just giving people a wasm sandbox, but also more complex ideas like trying to constrain extensibility such that "policies" end up being code that generates a "virtual graph" that is also time-stamped like everything else in the system.

maybe we should make a separate issue for policy in general rather than this issue which is for OPA specifically

I don't have strong opinions but my knee jerk reaction is thinking that maybe it could be "simpler" to only have 1 tool, only 1 language (dsl?) to learn and write tests for. I understand that there must be reasons for using OPA. I read some of the previous messages in this channel, but I still have a hard time understanding how the 2 works together.

The very short of it is that SpiceDB/Zanzibar is for deterministic decisions based on what relationships people/resources have. Policy Engines enable you to write arbitrary code that is not embedded within your application to make decisions. If you were using both, a policy engine would be more useful for doing something like "verifying the request" such that it has an allowed IP address, came from an approved client software, etc... and then you could query SpiceDB whether or not that user has the correct relationships to take an action.

Is there any plans to have multi level inheritance in schema?

Yep. We've tried it for a few use cases, but we haven't fully baked the feature yet https://github.com/authzed/spicedb/issues/15

Thanks!

Hi everyone! Are there any resources around using authzed in the context of a Rails application? What are people doing when it comes to enforcement? Having pundit or CanCanCan policies being backed by the rules in authzed? On another non-Ruby-specific topic, how are you ensuring data consistency between your relational DB and authzed?

Hey there, we haven't spent much time on the Ruby ecosystem, unfortunately. We have some Ruby bindings, but they haven't been regenerated for v1 just yet. If you're interested in using them, we could get them working for you. I think calling out to authzed from a cancancan policy makes sense, but I'm not a rails dev. For consistency, right now, we simply don't commit our db transactions until we've written relationships into authzed. It isn't perfect, but we're exploring other alternatives in the future, like remote transaction APIs.

Thanks Jimmy! I'll probably work on a PoC 🙂 on my later question, it's a common problem to deal with whenever you have multiple data stores, and hence CQRS. I was just curious about people's approaches.

Are you using anything like Kafka for CQRS right now? We aren't crazy familiar with that space, so hearing what is popular would help us design something more approachable for our users.

Indeed, we are! We are only now taking our first steps and so our architecture is still quite immature. ATM it's best-effort, so as you described, we use an Active Record

after_commit

hook to trigger a background job that writes to Kafka. We are leaning towards implementing a transactional outbox to keep coherency. That's the solution I worked with in the past and it served my previous company well. We did hit scalability issues at some point but we worked around them by dropping ordering guarantees across some domains (e.g., facts for different tenants could be reordered, but not facts for the same tenant) and started distributing the load across multiple publishers using consistent hashing. We only hit these issues once we started facing significant deviations from our average traffic, years after we put the base infrastructure in place.

For fun, I'm attempting to bring V1 to the ruby client: https://github.com/authzed/authzed-rb/pull/13

Hey, that looks about right

i'll add some feedback really quick, but mostly you need to sign off your commit

git commit amend --signoff

Ah sure! I'm on vacation and not on my usual gear so oops, I forgot to set up GPG 😅

no it it's not using GPG

it just adds the text "Signed by off: blah blah blah"

Ahhhh! Sure!

that's the difference between

-s

and

-S

with git, haha

it's a part of using the DCO

which I'm not totally sure is 100% required

so we might drop it eventually

nodejs for example uses the DCO without forcing people to signoff

Hey what is the best way to patch the schema I want to dynamically add new definitions and update relations, permissions to existing definition.

WriteSchema

upsert the schema, but i am not able to add relations and permission to existing definition with that as it rewrite the current one

Right now the only way to patch a schema is to fetch the current schema with

ReadSchema

, modify it, and then update it with

WriteSchema

But I'll also add that it's usually better to find a way to represent changes that need to happen frequently as relationships (data) and not schema, if possible

Are there any recommendations/references on how to address search and authorization that someone can point me too. For example, let's say I had an asset manager/service that was storing all the assets in our system and zanzibar is being used for determining if a user can access a resource. The assets that a user is allowed to access can be queried using the expand API. If Elasticsearch is being used to store all the metadata for assets and I wanted to search all the documents, how could that be done efficiently. The only idea I've seen so far and sort of discussed in the original Zanzibar paper is checking and filtering each document that is returned from the search query, but that doesn't seem very efficient. I was wondering if there are some other recommendations.

@User that's the general recommendation, yes. If you believe the set of items for the user is going to be not too large, you can also call

LookupResources

for the user, then pass that list of IDs into your Elasticsearch, and set it to check the item ID in that set (and drop the relevancy if not found)