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 CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA1:
3
- metadata.gz: 1f54a2250aa76f9ecd167caa91122a99ffeb388b
4
- data.tar.gz: 2084a24c0bc0c6c64d4c7c91a552039e033edfd7
3
+ metadata.gz: e915d65bc1f467993ab51ed838e84588d8598ca1
4
+ data.tar.gz: 0afcc5306330c1cb033860029b3b2cc66211a85a
5
5
  SHA512:
6
- metadata.gz: de9819ba823e23fda6e4ee2053d369c3b981343eb933efac1b57e974ed9bf781626a3ecca761e6a30e2efe6bb0e466da2a461e336edfe9379428ac1533d741a8
7
- data.tar.gz: 8792bf0c8f7208fdf60c4ab5854c8add51911f073e28e83f5a10555112c437a4ce7db336f20064432e9fdfecdb79ca9e8b3dc97596e0d769b893a50f70d90c76
6
+ metadata.gz: 5a20646d032545e0a9a0ba18420287b6c10931cdfa50f4c6286b4cc06f1b2162eaa74cf6ede6dd1c9fb08ceff21f5ac95fb43f336b992676adbb2eb6f04613a6
7
+ data.tar.gz: 70bab16389541cb67e40981fa7677b10a7717cf2aa9a90a6d57cf1022b469cd6f4c029c319b7f6d0e79276bd4e31b8ce0cbdee9cf9fd59e4dd81f585103fc26c
data/.gitignore CHANGED
@@ -12,3 +12,4 @@ plan*.yml
12
12
  /spec/reports/
13
13
  /tmp/
14
14
  /features/reports/
15
+ .idea
data/CHANGELOG CHANGED
@@ -1 +1,6 @@
1
- * 0.3.0 Initial stable version
1
+ # 0.3.1
2
+
3
+ * Fix bug in executor for permissions
4
+
5
+ # 0.3.0
6
+ * Initial stable version
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
- exclusive: true
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 `exclusive` 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`.
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
- # the only roles which can read and execute the secret.
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
- exclusive: true
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 checking out the repo, run `bin/setup` to install dependencies. Then, run `rake rspec` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.
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/[USERNAME]/conjur-asset-dsl2.
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
@@ -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",
@@ -1,7 +1,7 @@
1
1
  module Conjur
2
2
  module Asset
3
3
  module DSL2
4
- VERSION = "0.3.0"
4
+ VERSION = "0.3.1"
5
5
  end
6
6
  end
7
7
  end
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.0
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 00:00:00.000000000 Z
11
+ date: 2016-01-22 00:00:00.000000000 Z
12
12
  dependencies:
13
13
  - !ruby/object:Gem::Dependency
14
14
  name: safe_yaml