conjur-asset-dsl2 0.3.0 → 0.3.1
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/.gitignore +1 -0
- data/CHANGELOG +6 -1
- data/README.md +46 -89
- data/lib/conjur/command/dsl2.rb +3 -2
- data/lib/conjur/dsl2/executor/permit.rb +1 -1
- data/lib/conjur-asset-dsl2-version.rb +1 -1
- metadata +2 -2
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA1:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: e915d65bc1f467993ab51ed838e84588d8598ca1
|
4
|
+
data.tar.gz: 0afcc5306330c1cb033860029b3b2cc66211a85a
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 5a20646d032545e0a9a0ba18420287b6c10931cdfa50f4c6286b4cc06f1b2162eaa74cf6ede6dd1c9fb08ceff21f5ac95fb43f336b992676adbb2eb6f04613a6
|
7
|
+
data.tar.gz: 70bab16389541cb67e40981fa7677b10a7717cf2aa9a90a6d57cf1022b469cd6f4c029c319b7f6d0e79276bd4e31b8ce0cbdee9cf9fd59e4dd81f585103fc26c
|
data/.gitignore
CHANGED
data/CHANGELOG
CHANGED
data/README.md
CHANGED
@@ -21,24 +21,46 @@ Also possible:
|
|
21
21
|
* Revoke roles
|
22
22
|
* Deny privileges
|
23
23
|
|
24
|
+
# Installation
|
25
|
+
|
26
|
+
DSL2 is available as a conjur plugin (via rubygems). You can install it with the following command:
|
27
|
+
|
28
|
+
```ssh-session
|
29
|
+
conjur plugin install dsl2
|
30
|
+
```
|
31
|
+
|
32
|
+
Upon successful installation, running `conjur help` should show a toplevel `policy2` command.
|
33
|
+
|
34
|
+
# Command Line Usage
|
35
|
+
|
36
|
+
Conjur DSL2 accepts policies in the new YAML format, described below.
|
37
|
+
|
38
|
+
The `policy2` command has two subcommands, `load` and `import`. The `load` command is used to load a policy file
|
39
|
+
in one shot, or to "preview" the actions that would be taken if the policy were loaded (using the `--dry-run` option).
|
40
|
+
|
41
|
+
For details on the usage of this command, run `conjur help policy2 load`.
|
42
|
+
|
43
|
+
The `conjur policy2 import` command can be used to execute a plan produced by the `conjur policy2 load --dry-run --format yaml`
|
44
|
+
command.
|
45
|
+
|
46
|
+
# Examples
|
47
|
+
|
48
|
+
You can find many examples of the new YAML syntax in the
|
49
|
+
[Conjur enterprise example repo](https://github.com/conjurdemos/enterprise-example/tree/dsl2/policy). Note that only
|
50
|
+
the YAML syntax is currently supported, not the ruby DSL.
|
51
|
+
|
52
|
+
You can also find examples in the [test fixtures](https://github.com/conjurinc/conjur-asset-dsl2/tree/master/spec/lib/fixtures)
|
53
|
+
for this project. These fixtures embed the policy in a yaml document that also describes the initial state of the
|
54
|
+
Conjur server, the expected plan, and the expected execution (or in the case of a fixture that is expected to fail,
|
55
|
+
the expected exception).
|
56
|
+
|
57
|
+
|
24
58
|
# Functionality overview
|
25
59
|
|
26
60
|
## `policy`
|
27
61
|
|
28
62
|
A `policy` definition creates a versioned policy role and resource. The policy role is the owner of all new records contained with in it.
|
29
63
|
|
30
|
-
In Ruby, when a DSL is loaded as a policy, the policy record is already created an in scope. Policy fields such as `id`, `records`, `permissions` etc can be populated directly.
|
31
|
-
|
32
|
-
```ruby
|
33
|
-
policy "myapp/v1" do
|
34
|
-
body do
|
35
|
-
group "secrets-managers"
|
36
|
-
|
37
|
-
layer "webserver"
|
38
|
-
end
|
39
|
-
end
|
40
|
-
```
|
41
|
-
|
42
64
|
In YAML:
|
43
65
|
|
44
66
|
```yaml
|
@@ -48,18 +70,6 @@ In YAML:
|
|
48
70
|
|
49
71
|
## Create and Update Records
|
50
72
|
|
51
|
-
In Ruby, record create/update is enclosed in a `records` block. Each record is created by calling a function with the record `kind`, passing the record id as the argument. Attributes and annotations can be set in a block.
|
52
|
-
|
53
|
-
|
54
|
-
```ruby
|
55
|
-
user "alice"
|
56
|
-
|
57
|
-
user "bob" do
|
58
|
-
uidnumber 1001
|
59
|
-
annotation "email", "bob@mycorp.com"
|
60
|
-
end
|
61
|
-
```
|
62
|
-
|
63
73
|
Here's how to create two users in YAML:
|
64
74
|
|
65
75
|
```yaml
|
@@ -76,56 +86,30 @@ The type of record that you want to create is indicated by the YAML tag. The id
|
|
76
86
|
|
77
87
|
An example in which `alice` and the `ops` group are the only members of the `developers` group.
|
78
88
|
|
79
|
-
```ruby
|
80
|
-
grant do
|
81
|
-
role group("developers")
|
82
|
-
member user("alice")
|
83
|
-
member group("ops)", admin:true
|
84
|
-
exclusive true
|
85
|
-
end
|
86
|
-
```
|
87
|
-
|
88
|
-
And in YAML:
|
89
|
-
|
90
|
-
|
91
89
|
```yaml
|
92
90
|
- !grant
|
93
91
|
role: !group developers
|
94
92
|
members:
|
95
93
|
- !user alice
|
96
|
-
-
|
94
|
+
- !member
|
97
95
|
role: !group ops
|
98
96
|
admin: true
|
99
|
-
|
97
|
+
replace: true
|
100
98
|
```
|
101
99
|
|
102
100
|
A member is composed of the `role` (or `roles`) being granted and the `member` (or `members`) which will get the role.
|
103
101
|
|
104
102
|
The `member` can be a plain role (again using the YAML tag to indicate the record type), if the role is granted without admin capability. To grant a role with admin, the role member is a structured entry composed of the `role` and the `admin` flag.
|
105
103
|
|
106
|
-
Note that when the `
|
104
|
+
Note that when the `replace` feature is used, any existing role members that are **not** specified in the policy will be revoked. So in the example above, `!user alice` and `!group ops` will be the *only* members of `!group developers`.
|
107
105
|
|
108
106
|
## Permissions
|
109
107
|
|
110
108
|
Like `grant` is used to grant roles, `permit` is used to give permissions on a resource.
|
111
109
|
|
112
|
-
```ruby
|
113
|
-
permit %w(read execute) do
|
114
|
-
resource variable("db-password")
|
115
|
-
role group("developers")
|
116
|
-
role layer("app-server")
|
117
|
-
end
|
118
|
-
|
119
|
-
permit "update" do
|
120
|
-
resource variable("db-password")
|
121
|
-
role group("developers")
|
122
|
-
exclusive: true
|
123
|
-
end
|
124
|
-
```
|
125
|
-
|
126
110
|
```yaml
|
127
111
|
# developers group and the app-server layer are
|
128
|
-
#
|
112
|
+
# granted permission to read and execute the secret.
|
129
113
|
- !permit
|
130
114
|
resource: !variable db-password
|
131
115
|
privilege: [ read, execute ]
|
@@ -138,20 +122,11 @@ end
|
|
138
122
|
resource: !variable db-password
|
139
123
|
privilege: update
|
140
124
|
role: !group developers
|
141
|
-
|
125
|
+
replace: true
|
142
126
|
```
|
143
127
|
|
144
128
|
Use `deny` to remove a privilege without affecting the other privileges:
|
145
129
|
|
146
|
-
```ruby
|
147
|
-
deny %w(read execute) do
|
148
|
-
resource variable("db-password")
|
149
|
-
role layer("app-server")
|
150
|
-
end
|
151
|
-
```
|
152
|
-
|
153
|
-
In YAML:
|
154
|
-
|
155
130
|
```yaml
|
156
131
|
- !deny
|
157
132
|
resource: !variable dev/db-password
|
@@ -163,13 +138,6 @@ In YAML:
|
|
163
138
|
|
164
139
|
Ownership of a record (or group of records) can be assigned using the `owner` field:
|
165
140
|
|
166
|
-
```ruby
|
167
|
-
variable "db_password" do
|
168
|
-
owner group("developers")
|
169
|
-
end
|
170
|
-
```
|
171
|
-
|
172
|
-
In YAML:
|
173
141
|
|
174
142
|
```yaml
|
175
143
|
- !variable
|
@@ -208,38 +176,27 @@ These are the benefits of the policy DSL, as imagined internally by the Conjur t
|
|
208
176
|
* Deprovisioning of users is robust, and does not violate consistency of the database
|
209
177
|
* Export and import of permission models will be very straightforward, making it possible to implement Conjur “staging” setups.
|
210
178
|
|
211
|
-
# Examples
|
212
|
-
|
213
|
-
For many examples of sample policy files, see the [examples directory](https://github.com/conjurinc/conjur-asset-dsl2/tree/master/spec/lib/round-trip).
|
214
|
-
|
215
179
|
# Policy conflicts
|
216
180
|
|
217
181
|
Please note that it's pretty easy to write policies which say contradictory things. For example, Policy A might use `!members` to control the members of the developers group. Another Policy B might use `!grant` to add a specific user to the developers group. When Policy B runs, it will add the user to the group. When Policy A runs, it will revoke the user. If B is run again, the user will be re-added.
|
218
182
|
|
219
|
-
So usually good ensure that the members of a role and the privileges on a resource are managed by one approach or the other, but not both.
|
220
|
-
|
221
|
-
## Installation
|
183
|
+
So it's usually good ensure that the members of a role and the privileges on a resource are managed by one approach or the other, but not both.
|
222
184
|
|
223
|
-
Add the plugin to Conjur:
|
224
|
-
|
225
|
-
```sh-session
|
226
|
-
$ sudo -E conjur plugin install dsl2
|
227
|
-
```
|
228
185
|
|
229
186
|
## Development
|
230
187
|
|
231
|
-
After
|
232
|
-
|
233
|
-
To install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org).
|
188
|
+
After cloning this repo, run `bundle install` to install dependencies, and `rspec` to run the specs. Note that development
|
189
|
+
typically requires a properly configured Conjur appliance, although the specs should work without one.
|
234
190
|
|
235
191
|
## Todo
|
192
|
+
|
193
|
+
* Better error messages.
|
194
|
+
* More checks, for example, conflicts and permissions.
|
236
195
|
|
237
|
-
* Planner : implement change of ownership for roles.
|
238
|
-
* Planner : verify that all records referenced by permissions and grants will exist (either pre-existing, or will be created by the policy).
|
239
196
|
|
240
197
|
## Contributing
|
241
198
|
|
242
|
-
Bug reports and pull requests are welcome on GitHub at https://github.com/
|
199
|
+
Bug reports and pull requests are welcome on GitHub at https://github.com/conjurinc/conjur-asset-dsl2.
|
243
200
|
|
244
201
|
|
245
202
|
## License
|
data/lib/conjur/command/dsl2.rb
CHANGED
@@ -61,9 +61,10 @@ class Conjur::Command::DSL2 < Conjur::DSLCommand
|
|
61
61
|
mod.const_get "Loader"
|
62
62
|
end
|
63
63
|
|
64
|
-
def self.execute api, records
|
64
|
+
def self.execute api, records, options = {}
|
65
65
|
actions = []
|
66
66
|
records.each do |record|
|
67
|
+
executor_class = Conjur::DSL2::Executor.class_for(record)
|
67
68
|
executor = Conjur::DSL2::Executor.class_for(record).new(record, actions, Conjur::Core::API.conjur_account)
|
68
69
|
executor.execute
|
69
70
|
end
|
@@ -167,7 +168,7 @@ command. Therefore, a policy can be loaded in three steps, if desired:
|
|
167
168
|
|
168
169
|
filename = args.pop
|
169
170
|
script = script_from_filename filename
|
170
|
-
actions = YAML.load(script, filename)
|
171
|
+
actions = Conjur::DSL2::YAML::Loader.load(script, filename)
|
171
172
|
execute api, actions, options
|
172
173
|
end
|
173
174
|
end
|
@@ -5,7 +5,7 @@ module Conjur::DSL2::Executor
|
|
5
5
|
class Permit < Base
|
6
6
|
def execute
|
7
7
|
parameters = { "privilege" => statement.privilege, "role" => statement.role.role.roleid(default_account) }
|
8
|
-
parameters['grant_option'] = admin unless statement.role.admin.nil?
|
8
|
+
parameters['grant_option'] = statement.role.admin unless statement.role.admin.nil?
|
9
9
|
action({
|
10
10
|
'method' => 'post',
|
11
11
|
'path' => "#{resource_path(statement.resource)}?permit",
|
metadata
CHANGED
@@ -1,14 +1,14 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: conjur-asset-dsl2
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version: 0.3.
|
4
|
+
version: 0.3.1
|
5
5
|
platform: ruby
|
6
6
|
authors:
|
7
7
|
- Kevin Gilpin
|
8
8
|
autorequire:
|
9
9
|
bindir: exe
|
10
10
|
cert_chain: []
|
11
|
-
date: 2016-01-
|
11
|
+
date: 2016-01-22 00:00:00.000000000 Z
|
12
12
|
dependencies:
|
13
13
|
- !ruby/object:Gem::Dependency
|
14
14
|
name: safe_yaml
|