rs_user_policy 0.1.10 → 0.1.11
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- 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
|