Browse Source

Merge "Explicit Domain Ids"

Zuul 6 months ago
parent
commit
8b3cda6078
1 changed files with 185 additions and 0 deletions
  1. 185
    0
      specs/keystone/stein/explicit-domains-ids.rst

+ 185
- 0
specs/keystone/stein/explicit-domains-ids.rst View File

@@ -0,0 +1,185 @@
1
+..
2
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
3
+ License.
4
+
5
+ http://creativecommons.org/licenses/by/3.0/legalcode
6
+
7
+===================
8
+Explicit Domain IDs
9
+===================
10
+
11
+`Explicit Domain IDs <https://bugs.launchpad.net/keystone/+bug/1794527>`_
12
+
13
+
14
+Problem Description
15
+===================
16
+
17
+Many organizations are deploying multiple OpenStack deployments. There
18
+are many reasons that these systems are not shared into on large cluster.
19
+Some are owned by different sub organizations. Others are kept separate
20
+due to application life cycle. Some are physically isolated from each other.
21
+All of these issues prevent co-operation across clusters.
22
+
23
+If the organization uses LDAP for the user backend, the user entry in
24
+the id_mapping table gets a new local_id generated as a hash of the
25
+domain_id and the unique Identifier from the LDAP server.  If the
26
+Domain ID is different in two different deployments, the user ends up
27
+with two distinct user IDs.  An attempt to build an Audit train across
28
+multiple deployments then has to correlate the user IDs across
29
+different Keystone servers.
30
+
31
+To avoid this, operators want to keep the LDAP users in a domain with
32
+a consistant ID across deployments.  The only domain with a
33
+predictable ID, however, is `default.`  THe default domain is used
34
+during the initial install, and thus has service users.  Thus, it is
35
+inpractical to put the LDAP users in the default domain.  If a site
36
+wished to have two LDAP servers in domain specific backends, only one
37
+could be put in default.
38
+
39
+Today, if a depoloyer desires to keep two Keystone servers in sync
40
+while  avoiding Database replication, they must hack the database to
41
+update the Domain ID so that entries match. Domain ID is then used for
42
+LDAP mapped IDs, and if they don't match, the user IDs are
43
+different. It should be possible to add a domain with an explicit ID,
44
+so that the two servers can match User IDs.
45
+
46
+An additional effort is underway to make the Federated Identity
47
+sources use the same mechanism as LDAP.  This effort is hampered
48
+by the same domain_id restrictions as LDAP.
49
+
50
+Making the identifiers consistant across multiple deployments will aid
51
+in several use cases:
52
+
53
+It will make it easier to synchronize role assignments across two
54
+distinct deployments, as the user ID from the first can be used in the
55
+second.
56
+
57
+Applications will now be able to predict what user-id a user would
58
+have in a cluster, even before that user visits the cluster.  This
59
+allows the system to pre-create user records, and have them link to
60
+the identity source when the user does finally authenticate to the
61
+Keystone server.
62
+
63
+One structure that can be used for multiple depoloyments is for each
64
+Keystone server to represent a different region, and for each region
65
+to have a set of domains for which it is the system of record.  This
66
+allows local writes and avoids conflicts.  In order for a central
67
+system to keep track of the domain IDs, and to synchronize them across
68
+different servers, one of the systems needs to be able to explicitly
69
+assign them.
70
+
71
+
72
+
73
+Proposed Change
74
+===============
75
+
76
+When creating a domain, the user can pass the optional parameter
77
+`explicit_domain_id` to be used when creating the domain.  A domain
78
+created this way will not use an autogenerated id, but will use the id
79
+passed in instead.
80
+
81
+Identifiers passed in this way must conform to the existing ID
82
+generation scheme:  UUID4 without dashes.
83
+
84
+
85
+Alternatives
86
+------------
87
+
88
+Galera Sync of the database between sites.  This will only scale to a
89
+small number of locations.  With local HA requirements of 3 nodes per
90
+site, this will likely scale to a single digit number of locations.
91
+
92
+Make Domain names immutable and change the scheme to use the names.
93
+This will break all the existing LDAP deployments, as well as break
94
+API backwards compatibility.
95
+
96
+K2K Federation has been discussed as a way to help manage multiple
97
+sites, but it does not address the need to make the User ID consistent
98
+for Audit purposes.  In addition, K2K adds an additional layer of SAML
99
+indirection, without providing additional value here:  it solves the
100
+problem where users are stored in one Keystone server, but need access
101
+to a separate cloud.  As such, K2K will suffer from all the same
102
+problems as any of Federated Identity Provider.
103
+
104
+
105
+Security Impact
106
+---------------
107
+
108
+This should have little to no direct security impact.  It will,
109
+however, greatly aid in auditability, as user IDs can be correlated
110
+across multiple deployments.
111
+
112
+There is little risk of a domain administrator abusing this new option.
113
+Creating a Domain is a rare operation, reserved for Cloud Admins.  As such,
114
+they are keeping domain IDs in sync to aid their own organizational goals.
115
+If they chose to not sync a domain, it will only affect their own cluster, and
116
+not the others.  The degenerate case for Auditing will be the current state.
117
+
118
+
119
+The IDs for users will now fall into the category of
120
+"predictable-but-not-settable."  Since the uuid is a hash of the
121
+string, and not explicitly setable, the will not be a potential for
122
+"User_ID squatting." where a user pre-allocates an entry to block
123
+another user.
124
+
125
+
126
+Notifications Impact
127
+--------------------
128
+
129
+None
130
+
131
+Other End User Impact
132
+---------------------
133
+
134
+None
135
+
136
+
137
+Performance Impact
138
+------------------
139
+
140
+None
141
+
142
+Other Deployer Impact
143
+---------------------
144
+
145
+None
146
+
147
+Developer Impact
148
+----------------
149
+
150
+None
151
+
152
+Implementation
153
+==============
154
+
155
+Assignee(s)
156
+-----------
157
+
158
+
159
+Primary assignee:
160
+Adam Young <ayoung>
161
+
162
+
163
+Work Items
164
+----------
165
+
166
+Change to Keystone Server
167
+Change to Openstack SDK
168
+Change to OpenStack CLI
169
+
170
+
171
+Dependencies
172
+============
173
+
174
+None
175
+
176
+Documentation Impact
177
+====================
178
+
179
+New option needs to be in documentation, including an update to the
180
+LDAP and Federation docs.
181
+
182
+References
183
+==========
184
+
185
+None

Loading…
Cancel
Save