entity slice validation

[mwhicks1]

Validating policies for entity slices using levels

Rendered

[oflatt]

Nice idea, and much simpler than entity manifests.
We should add a note about how this is related to #74. Given a type-annotated entity manifest, calculating the level is easy

[shaobo-he-aws]

Pretty cool.

[mwhicks1]

Nice idea, and much simpler than entity manifests. We should add a note about how this is related to #74. Given a type-annotated entity manifest, calculating the level is easy

Thanks! I've updated the RFC to compare the two, landing on the position that we should ultimately have both.

[D-McAdams]

Thanks for adding the cross-link to Entity Manifests in #74.
Agree that they are best as a pair. Entity Manifests give instructions on what to load, and Entity Slice Validation (this RFC) ensures the instructions are practical by capping the complexity of incoming policies.

Also agree the alternatives in this RFC are less necessary when both techniques are used together.

[khieta]

Left a few small comments, but I like this proposal in general. I think it makes sense as a first step before RFC 74.

[khieta]

Not a fan of this alternative. I think it will make the validator behavior more difficult for users to understand.

[patjakdev]

I generally find RFC 74 to be a more appealing approach to slicing. I think that were RFC 74 to be accepted, this one wouldn't have much utility given the cost to implement and (IMO) unlikeliness for it to apply well generally.

If you've got some real-world use cases where validation-time depth limitations would have solved performance problems for users in a way that RFC 74 wouldn't or couldn't, I'd definitely be open to changing my mind.

The one that springs to mind is maliciously authored policies, but I wonder if that wouldn't be something better guarded against in the Cedar library implementations rather than as part of the schema.

[patjakdev]

Having read through the motivation section, I'm not entirely convinced of the overall utility of this proposal, especially in a world where RFC 74 is implemented.

The proposal seems to consider a narrow dimension of policy evaluation performance (entity graph depth) in such a coarse-grained way that it feels unlikely to be a solution to anyone's specific policy performance problems. I'd like to see some justification for this proposal working in the 80% case. We can easily imagine lumpy or extremely wide entity graphs wherein a single level number provides almost no utility to the slicer and a great frustration to the policy author who needs to go just one level deeper than is allowed.

Something like RFC 74 seems to give a lot more flexibility to both policy authors and slicers since slicers don't have to be so coarse-grained, although they might choose to be. You could imagine implementing the depth traversal limit proposed here in the entity loader interface proposed in that RFC if the entity type level proposed here were passed along, although that would end up being an evaluation error rather than a validation error, which perhaps would be undesirable.

[patjakdev]

Also, I'm curious if there are real-world examples which motivated this proposal. If so, I think it would be useful to include them.

[andrewmwells-amazon]

I agree that #74 is likely to be more suitable for most consumers of Cedar. This RFC gives a less granular tool for describing the entity data that needs to be included in the slice. Sometimes, being more granular is better.

The usecase I find most compelling for this RFC is one where one party writes the entity slicing algorithm and another writes the policies (e.g., you offer a service where end-users can author Cedar policies). With #74, the entity slicing potentially needs to be changed whenever policies change (because we were passing in only the entities needed). With this RFC, we pass in some entity data that may be unused, but this means policies can change freely as long as they continue to only use the entity data at level n.

[andrewmwells-amazon]

"End-users writing policies" is (in vague terms) the real-world example that motivated this.

[patjakdev]

The drawback is that policy writers cannot look in one place to know the limits on the policies they can write.

I don't think this is so awful. The error message from the validator will tell the author what the limit is, if they hit it. This also allows for more flexibility in granularity of level validation in the future without having to change the Cedar language.

[andrewmwells-amazon]

After implementing this (cedar-policy/cedar#1146) I am inclined towards making this a parameter.

Arguments for:

• In the non-JSON schema format, level can occur at the top of any namespace. This makes finding level annoying. We error if level occurs more than once, but we could just take it as a single parameter to validate.
• The JSON schema format has the same issue, but JSON isn't ordered, so it feels more native.
• Schema format remains unchanged and we can add level to the schema later if desired. In particular, adding the per-entity level as described in alternatives would require new syntax (something like @level(1), as proposed in the alternative). Delaying this decision will let us hear if more people would prefer that and a global level or something similar.

Arguments against:

• Keep data in one place.
• Easier to change schema than to change code (but the entity slicing code would still need to change).