cedar-policy-cli 4.10.0

CLI interface for the Cedar Policy language.
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125

# Sandbox A

This sandbox contains some simple policies and entities for the example
PhotoFlash application.

None of the entities in this sandbox have attributes, so all the policies
are purely RBAC policies: they are based on the entity hierarchy itself.

## policies_1.cedar

With this policy set, everyone in `UserGroup::"jane_friends"` can view a
specific photo (`Photo::"VacationPhoto94.jpg"`), but one specific user
(`User::"tim"`) is explicitly forbidden from any action on that photo via a
`forbid` policy which overrides the `permit` policy.

All operations on any other resources are implicitly forbidden, because
Cedar's default is always to deny access unless some policy specifically
allows it.

Try the following authorization request:

```shell
cargo run authorize \
    --principal 'User::"alice"' \
    --action 'Action::"view"' \
    --resource 'Photo::"VacationPhoto94.jpg"' \
    --policies policies_1.cedar \
    --entities entities.json
```

This should be allowed, because `alice` is in the group `jane_friends`.

On the other hand, if you replace `User::"alice"` with `User::"tim"`, this request
should be denied, due to the `forbid` policy.

If you try `User::"bob"`, the request should still be denied, but this time it's
because `bob` is not in the group `jane_friends`.

## policies_2.cedar

This policy set demonstrates how one policy can apply to a explicit list of
actions on a resource or group of resources.

Try the following authorization request:

```shell
cargo run authorize \
    --principal 'User::"alice"' \
    --action 'Action::"view"' \
    --resource 'Photo::"VacationPhoto94.jpg"' \
    --policies policies_2.cedar \
    --entities entities.json
```

By adjusting the `--action`, you should see that `alice` is allowed to `view`,
`edit`, or `delete` the photo.  (Or, any other resources `in` the
`jane_vacation` album.)  However, she's not allowed to `comment`, because
`Action::"comment"` isn't explicitly listed in the policy.

With this policy set, you should also see that `bob` is allowed to `view`
resources in the `jane_vacation` album, but unlike `alice`, `bob` can only
`view`, he cannot `edit` or `delete`.

## policies_3.cedar

This policy set allows public (`view`) access to the resources in the
`jane_vacation` album, and also to take the `listPhotos` action on the album
itself.

Try this request, with any `--principal`, to see that `view` access is allowed to
everyone:

```shell
cargo run authorize \
    --principal 'User::"alice"' \
    --action 'Action::"view"' \
    --resource 'Photo::"VacationPhoto94.jpg"' \
    --policies policies_3.cedar \
    --entities entities.json
```

And, see that anyone is also allowed the `listPhotos` action on the album
itself:

```shell
cargo run authorize \
    --principal 'User::"tim"' \
    --action 'Action::"listPhotos"' \
    --resource 'Album::"jane_vacation"' \
    --policies policies_3.cedar \
    --entities entities.json
```

## Policy validation

You can validate if a policy conforms with the schema. Try the following:

```shell
cargo run validate \
  --policies policies_1.cedar \
  --schema schema.cedarschema
```

Validation should pass. If you look at the `schema.cedarschema` file, you will see it has two kinds of declarations: `entity` declarations and `action` declarations. The `entity` declarations describe the legal entity types, including member relationships. For example, we see that entities of type `Photo` can be members of entities of type `Account` or `Album`.

The `action` declarations in the schema define all of the legal actions (each of which has entity type `Action`, not shown), and the principal and resource types of entities that are allowed in authorization requests for that action. We can see that there are four legal actions, and each one has the same assumptions: only `User` entities can be passed in as principals in requests, and either `Photo`, `Album`, or `Video` entities can be passed in as resources.

Now try validation on `policies_1_bad.cedar`. You will see that validation fails, indicating that entity type `UsrGroup` is unrecognized; this is because it is not listed in the `entityTypes` section (it was meant to be `UserGroup` but there was a typo).

## Evaluation

You can evaluate a Cedar expression using the `evaluate` command. Try the
following:

```shell
cargo run evaluate \
    --principal 'User::"alice"' \
    --action 'Action::"listPhotos"' \
    --resource 'Album::"jane_vacation"' \
    --entities entities.json \
   "resource in Account::\"jane\""
```

Now, continue on to `sandbox_b`, where we'll consider ABAC policies, that
examine the attributes of various entities.