Cedar is an open source policy language and evaluation engine

by mooreds • 3 years ago

72 17 3 years ago

thayne• 3 years ago

How does this compare to Open Policy Agent, or oso? Why would I use this instead?

sarahcec• 3 years ago

The main benefits of Cedar are: *Verifiable/Analyzable *Deterministic Low Latencies *No Security Sandboxing Needed *Ergonomic (easily readable) *Enables parallel execution More here: https://www.youtube.com/watch?t=1798&v=k6pPcnLuOXY&feature=y...

alexeldeib2• 3 years ago

I love the dual implementation, I hadn’t heard of Dafny.

Can you speak to the point about latency? I wasn’t aware it made performance guarantees

candiddevmike• 3 years ago

If you're all in on AWS, use it, if not, use OPA. Lots of vendors support OPA/rego, I can't think of anything I use outside of AWS that supports Cedar.

mooreds3• 3 years ago

I think that is part of why they open sourced it, to try to get more folks to use it. :)

mritun• 3 years ago

The challenge with authorization is that mistakes are catastrophic.

The foremost benefit of Cedar is that the implementation is formally proven. Which means that you are extremely unlikely to have to deal with unexpected behavior! Of course, the modeling needs to be reviewed manually for completeness, but the verifier can tell if the model is buggy or inconsistent.

bebop• 3 years ago

The company announcement was posted last week and also has some discussion here: https://news.ycombinator.com/item?id=35890784

lalaithion• 3 years ago

It would be nice to have performance numbers. Right now the only thing I can find on performance is "Cedar is fast and scalable. The policy structure allows your policies to be indexed for quick retrieval. The design also supports fast, scalable, real-time evaluation with bounded latency." which doesn't tell me if it is will respond within 100 ms with 100,000 entities or within 10 ms for 100 million entities.

NegativeLatency• 3 years ago

Looks neat, one of the places I've seen open source systems like this trip on is when you need to know: what principals can do a certain thing

Went through a big Ory Keto implementation to get stuck on not being able to do this last crucial bit, so we ended up implementing our own role based access control

mooreds3• 3 years ago

what principals can do a certain thing

Hmmm. What's an example of this?

SgtBastard• 3 years ago

Policy: Transactions under $X can be raised and approved by the same person. >X requires an independent approver with permission “supervisor”.

Activity: Alice (a supervisor), raises a transaction >X, Bob is a supervisor, Eve is not.

Problem: “Who can approve the transaction?”

(As humans the answer is obviously Bob, but for typical implementation approaches to AuthZ policy, this is challenging to determine. Typically it’s done out of band and then makes a decision when requested by Bob (allow) or Eve (deny))

jwineinger• 3 years ago

I find a few things about Cedar exciting. The formal verification and automated reasoning stuff sound great!

Unfortunately, there doesn't seem to be much of a story here to solve authz-aware searching/listing for object/row level access. Since Cedar/AVP doesn't come with an entity store, it seems I'd have to send my entire database(s) on each call so that the policies have the right data to evaluate. If that's true, then it seems like this would be only be useful on small data sets.

I'm struggling to come up with use cases for "fine-grained permissions and authorization" (what AVP bills itself as) that don't involve some sort of listing or searching of things.

restricted_keys• 3 years ago

Evaluated this recently for my company.

Pros

1. Cedar is great and very expressive and fits many many use case.

Cons

1. The price. Was too expensive for our scale

2. As another commenter has pointed, Cedar/AVP expects you to send all the contextual data as part of the Authz request. It only persists the policy.

3. There is no concept of role based lookup. E.g I cannot query who has what access

donavanm• 3 years ago

I have some experience with previous AWS IAM policy language and evaluation, but not cedar directly. Some context that might help:

C2a: think of the use case around a centralized policy & identity store with lots of independent services consuming that. The services dont know or care how individual users create/store/update their policies. Nor how other services perform authorization. Each service is the only source of truth for that services requests, and must supply the necessary API request context etc. C2b In addition you could certainly build a “cedar service” that owned identity policy and identity context then joined that with the services context to perform the access evaluation. C2c: Conversely if your service is much more monolithic, with no central trust or trusted peers, you could do all of the above inside your mono-service. But batteries are not included here.

C3: I actually dont know how to feasibly accomplish this with a capability based system. As youve mentioned authorization is very dependent on context, which is typically dynamic. Eg it might include time checks, source/dest network address, or even things like the machine identity that sent the request. It seems youd need to populate all the potential context to perform an evaluation, and a simple index/enumeration doesnt fit. Very interested if you have counter examples.

Cedar is an open source policy language and evaluation engine

Related Stories