rs_user_policy 0.1.10 → 0.1.11
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +8 -8
- data/LICENSE.txt +1 -1
- data/README.rdoc +73 -29
- data/lib/rs_user_policy/right_api/permission_utilities.rb +2 -2
- metadata +2 -2
checksums.yaml
CHANGED
|
@@ -1,15 +1,15 @@
|
|
|
1
1
|
---
|
|
2
2
|
!binary "U0hBMQ==":
|
|
3
3
|
metadata.gz: !binary |-
|
|
4
|
-
|
|
4
|
+
ODAwMDdlOGM2NDMzMzljMDQwZjZiNTkyODFlZmVlYTBjOGViMTczYg==
|
|
5
5
|
data.tar.gz: !binary |-
|
|
6
|
-
|
|
6
|
+
OGI0YTE4NTQ2MzAzNzJiOTg1ODIyNWQ1NzliZTM5NGJmNjkyZjY0Mw==
|
|
7
7
|
SHA512:
|
|
8
8
|
metadata.gz: !binary |-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
9
|
+
ZTM4Mjk0MjlkZTQ1N2NhMTM4ZDZmZGVjZGVhZjJmMDg5Njk1Yjc3YTMxZTMy
|
|
10
|
+
ZTM4NTY2MTkwOWUyZjk2NjBmN2YwY2QyYmYwMDgzNWIzMTU1OGQ2OWZjNjRj
|
|
11
|
+
NDRmNWVjNTU0OGE4NGE4ZTNkZTFlZDM5MTZjMDlhNDk3NWE2MGY=
|
|
12
12
|
data.tar.gz: !binary |-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
13
|
+
NTgyNWU1YmE0ODQwN2UyNGZkMmY3YzUyMTMxZDdlNjQ2NTg0NGI0NTZiMTRk
|
|
14
|
+
YmFlZjMxMDAwM2JkMmM3MmJiZTMwYWE4NmFiMGY3ZTkxNzYxZTE3ZTVhNmRl
|
|
15
|
+
ZTY1NWE0NWViYzMxMTA5NTcyN2M2MTkxNTFmNWQ2Yjc0MTY3ZDI=
|
data/LICENSE.txt
CHANGED
data/README.rdoc
CHANGED
|
@@ -7,19 +7,25 @@ While the tests are not exhaustive, the current build status is..
|
|
|
7
7
|
|
|
8
8
|
== Usage
|
|
9
9
|
|
|
10
|
-
You must pass in your RightScale authentication information, and a policy file.
|
|
10
|
+
You must pass in your RightScale authentication information, and a policy file.
|
|
11
|
+
You can also specify one or many RightScale accounts using the --rs-acct-num or
|
|
12
|
+
-a parameters. If an account that you specify is an Enterprise Master account,
|
|
13
|
+
all Enterprise Children accounts will automatically be discovered and included.
|
|
11
14
|
|
|
12
15
|
Options:
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
16
|
+
--rs-email, -r <s>: You RightScale User Email Address
|
|
17
|
+
--rs-pass, -s <s>: Your RightScale User Password
|
|
18
|
+
--rs-acct-num, -a <s>: A RightScale Enterprise Master Account ID
|
|
19
|
+
--policy, -p <s>: The path to a JSON file containing the role to permissions policy to enforce
|
|
20
|
+
--user-assignments, -u <s>: The path to a JSON file containing email address => role pairs for user assignments
|
|
21
|
+
--empty-user-assignments-fatal, -e: A flag which asserts that the provided user_assigments should contain at least one user_assignment mapping. If
|
|
22
|
+
there are 0 user assignments found, rs_user_policy will terminate.
|
|
23
|
+
--audit-dir, -d <s>: A directory where audit logs will be stored. By default this is the current working directory.
|
|
24
|
+
--dry-run, -y: A flag indicating that no changes should be made, only the user_assignments.json should be evaluated (or
|
|
25
|
+
created) and the audit_log.json produced
|
|
26
|
+
--authority, -t: A flag indicating that all users in the user_assignments file "MUST" exist, and will always be created.
|
|
27
|
+
Effectively asserting that the user_assignments is your canonical authority for users.
|
|
28
|
+
--help, -h: Show this message
|
|
23
29
|
|
|
24
30
|
Example (One account)
|
|
25
31
|
rs_user_policy -r "foo@bar.baz" -s "password" -p policy.json -u user_assignments.json -a 12345
|
|
@@ -29,7 +35,9 @@ Example (Multiple accounts)
|
|
|
29
35
|
|
|
30
36
|
=== Managing existing user permissions
|
|
31
37
|
|
|
32
|
-
The binary contained in this gem accepts two files as inputs to determine it's
|
|
38
|
+
The binary contained in this gem accepts two files as inputs to determine it's
|
|
39
|
+
behavior. The first, is a policy JSON file which specifies the permissions to
|
|
40
|
+
be applied to users.
|
|
33
41
|
|
|
34
42
|
Policy JSON should be in the following format
|
|
35
43
|
|
|
@@ -40,11 +48,15 @@ Policy JSON should be in the following format
|
|
|
40
48
|
}
|
|
41
49
|
}
|
|
42
50
|
|
|
43
|
-
Here the "role_name" is what can be assigned to a user. The keys of the hash
|
|
51
|
+
Here the "role_name" is what can be assigned to a user. The keys of the hash
|
|
52
|
+
("default" and "/api/accounts/12345") refer to the account(s) the role should
|
|
53
|
+
have access to, and the value for those keys is an array of permissions that
|
|
54
|
+
should be assigned for that role in that account.
|
|
44
55
|
|
|
45
56
|
The "default" account will apply to all accounts encountered.
|
|
46
57
|
|
|
47
|
-
The second input file is the user assignments JSON file which assigns users to
|
|
58
|
+
The second input file is the user assignments JSON file which assigns users to
|
|
59
|
+
roles using their email.
|
|
48
60
|
|
|
49
61
|
User Assignment JSON should be in the following format
|
|
50
62
|
|
|
@@ -56,8 +68,11 @@ User Assignment JSON should be in the following format
|
|
|
56
68
|
}
|
|
57
69
|
}
|
|
58
70
|
|
|
59
|
-
There are two default roles which do not need to be defined in the policy file.
|
|
60
|
-
|
|
71
|
+
There are two default roles which do not need to be defined in the policy file.
|
|
72
|
+
"immutable" which indicates that no changes should be performed on the user,
|
|
73
|
+
and "delete" which indicates that all permissions should be removed for the
|
|
74
|
+
user in all accounts. Both "immutable" and "delete", if present will take
|
|
75
|
+
precedence over any other roles assigned to the user.
|
|
61
76
|
|
|
62
77
|
So, given a policy file like;
|
|
63
78
|
|
|
@@ -88,14 +103,20 @@ And a user assignments file like;
|
|
|
88
103
|
}
|
|
89
104
|
|
|
90
105
|
And operating on the accounts 12345 and 23456;
|
|
91
|
-
user1 will be assigned observer and actor rights on account 23456, and
|
|
92
|
-
|
|
106
|
+
user1 will be assigned observer and actor rights on account 23456, and
|
|
107
|
+
observer, actor, server_login, and admin rights on account 12345
|
|
108
|
+
user2 will be assigned observer and lite_user rights on account 12345, and
|
|
109
|
+
observer and actor rights on account 23456
|
|
93
110
|
|
|
94
111
|
Got that? Cool!
|
|
95
112
|
|
|
96
113
|
=== Creating new users
|
|
97
114
|
|
|
98
|
-
This tool can also be used to create net-new users who have either never used
|
|
115
|
+
This tool can also be used to create net-new users who have either never used
|
|
116
|
+
RightScale, or who have never been associated with one of the accounts targetted
|
|
117
|
+
by the tool. For those type of users some additional parameters are necessary
|
|
118
|
+
in the user_assignments source file. The minimum set of properties is
|
|
119
|
+
["roles", "company", "first_name", "last_name", "phone"]
|
|
99
120
|
|
|
100
121
|
{
|
|
101
122
|
"net@new.user": {
|
|
@@ -108,34 +129,57 @@ This tool can also be used to create net-new users who have either never used Ri
|
|
|
108
129
|
}
|
|
109
130
|
}
|
|
110
131
|
|
|
111
|
-
The order of the additional parameters does not matter. The properties list
|
|
132
|
+
The order of the additional parameters does not matter. The properties list
|
|
133
|
+
can also include "identity_provider_href" and "principal_uid" or "password" to
|
|
134
|
+
specify the users authentication details. If no authentication details are
|
|
135
|
+
supplied a random secure password will be generated, and written to the output
|
|
136
|
+
user_assignments.json file.
|
|
112
137
|
|
|
113
138
|
*NOTE:* See the Authority section below for details on the "create" property
|
|
114
139
|
|
|
115
|
-
If a user with the specified email already exists, but that user does not have
|
|
140
|
+
If a user with the specified email already exists, but that user does not have
|
|
141
|
+
any permissions in the account(s) targetted by the tool, these additional
|
|
142
|
+
properties are still required, but will be ignored.
|
|
116
143
|
|
|
117
144
|
==== Authority
|
|
118
145
|
|
|
119
|
-
By default, rs_user_policy assumes that RightScale is the authority for the
|
|
146
|
+
By default, rs_user_policy assumes that RightScale is the authority for the
|
|
147
|
+
existence of users. Meaning, if a user exists in the user_assigments, but does
|
|
148
|
+
not exist in RightScale, the user will not be created by rs_user_policy. In
|
|
149
|
+
order to override this there are two options.
|
|
120
150
|
|
|
121
|
-
1. Specifying the --authority commandline option implies that ALL users who are
|
|
122
|
-
|
|
151
|
+
1. Specifying the --authority commandline option implies that ALL users who are
|
|
152
|
+
in the user_assignments should be created with the provided parameters
|
|
153
|
+
2. For individual users in the user_assignments, you can add a property named
|
|
154
|
+
"create" with any value. The user will be created, and the "create" property
|
|
155
|
+
will be removed.
|
|
123
156
|
|
|
124
157
|
== Output
|
|
125
158
|
|
|
126
159
|
When the script is run, it will produce two JSON files as output.
|
|
127
160
|
|
|
128
|
-
First is the audit_log-<timestamp>.json file. This will contain a history of
|
|
161
|
+
First is the audit_log-<timestamp>.json file. This will contain a history of
|
|
162
|
+
all actions taken on all users. If --dry-run is specified, it will show the
|
|
163
|
+
changes which *would* have been performed.
|
|
129
164
|
|
|
130
|
-
Second is the user_assignments-<timestamp>.json file. This will be a
|
|
165
|
+
Second is the user_assignments-<timestamp>.json file. This will be a
|
|
166
|
+
combination of the users read in from JSON in file specified by the
|
|
167
|
+
--user-assignments option, plus any new users discovered in the accounts
|
|
168
|
+
operated on. New users will be assigned the "immutable" role. This allows you
|
|
169
|
+
to run rs_user_policy with the --dry-run option, or with no user assignments
|
|
170
|
+
input to discover users, then assign roles to those users in the produced JSON,
|
|
171
|
+
then use that file as the --user-assignments input for a subsequent run.
|
|
131
172
|
|
|
132
173
|
== TODO
|
|
133
174
|
|
|
134
|
-
* In absence of a policy.json, create a new policy.json with base roles for
|
|
175
|
+
* In absence of a policy.json, create a new policy.json with base roles for
|
|
176
|
+
each account discovered (I.E. Admin, Observer, Designer, etc)
|
|
135
177
|
* Perhaps allow a role to inherit from another, or be a concatenation of several?
|
|
136
178
|
* Provide a mechanism for "temporary" users with an expiration date
|
|
137
|
-
* Perhaps allow the user to enter a different role after the expiration date,
|
|
138
|
-
|
|
179
|
+
* Perhaps allow the user to enter a different role after the expiration date,
|
|
180
|
+
rather than being removed completely?
|
|
181
|
+
* Optionally do not discover child accounts, but only use specified accounts.
|
|
182
|
+
* Extend multi_client to perform tasks concurrently in multiple threads.
|
|
139
183
|
|
|
140
184
|
== Copyright
|
|
141
185
|
|
|
@@ -112,7 +112,7 @@ module RsUserPolicy
|
|
|
112
112
|
def self.create_permissions(permissions, client)
|
|
113
113
|
permissions.each do |user_href,perm_ary|
|
|
114
114
|
user_perms_hash = Hash[perm_ary.keys.map{|p| [p, user_href]}]
|
|
115
|
-
RsUserPolicy::Utilities.
|
|
115
|
+
RsUserPolicy::Utilities.yield_on_keys_in_order(['observer'], user_perms_hash) do |role_title,user_href|
|
|
116
116
|
created_permission = client.permissions.create(
|
|
117
117
|
{
|
|
118
118
|
'permission[user_href]' => user_href,
|
|
@@ -127,4 +127,4 @@ module RsUserPolicy
|
|
|
127
127
|
|
|
128
128
|
end
|
|
129
129
|
end
|
|
130
|
-
end
|
|
130
|
+
end
|
metadata
CHANGED
|
@@ -1,14 +1,14 @@
|
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
|
2
2
|
name: rs_user_policy
|
|
3
3
|
version: !ruby/object:Gem::Version
|
|
4
|
-
version: 0.1.
|
|
4
|
+
version: 0.1.11
|
|
5
5
|
platform: ruby
|
|
6
6
|
authors:
|
|
7
7
|
- Ryan J. Geyer
|
|
8
8
|
autorequire:
|
|
9
9
|
bindir: bin
|
|
10
10
|
cert_chain: []
|
|
11
|
-
date: 2014-
|
|
11
|
+
date: 2014-12-02 00:00:00.000000000 Z
|
|
12
12
|
dependencies:
|
|
13
13
|
- !ruby/object:Gem::Dependency
|
|
14
14
|
name: right_api_client
|