Merge "Explicit Domain Ids"
This commit is contained in:
commit
8b3cda6078
|
@ -0,0 +1,185 @@
|
||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
===================
|
||||||
|
Explicit Domain IDs
|
||||||
|
===================
|
||||||
|
|
||||||
|
`Explicit Domain IDs <https://bugs.launchpad.net/keystone/+bug/1794527>`_
|
||||||
|
|
||||||
|
|
||||||
|
Problem Description
|
||||||
|
===================
|
||||||
|
|
||||||
|
Many organizations are deploying multiple OpenStack deployments. There
|
||||||
|
are many reasons that these systems are not shared into on large cluster.
|
||||||
|
Some are owned by different sub organizations. Others are kept separate
|
||||||
|
due to application life cycle. Some are physically isolated from each other.
|
||||||
|
All of these issues prevent co-operation across clusters.
|
||||||
|
|
||||||
|
If the organization uses LDAP for the user backend, the user entry in
|
||||||
|
the id_mapping table gets a new local_id generated as a hash of the
|
||||||
|
domain_id and the unique Identifier from the LDAP server. If the
|
||||||
|
Domain ID is different in two different deployments, the user ends up
|
||||||
|
with two distinct user IDs. An attempt to build an Audit train across
|
||||||
|
multiple deployments then has to correlate the user IDs across
|
||||||
|
different Keystone servers.
|
||||||
|
|
||||||
|
To avoid this, operators want to keep the LDAP users in a domain with
|
||||||
|
a consistant ID across deployments. The only domain with a
|
||||||
|
predictable ID, however, is `default.` THe default domain is used
|
||||||
|
during the initial install, and thus has service users. Thus, it is
|
||||||
|
inpractical to put the LDAP users in the default domain. If a site
|
||||||
|
wished to have two LDAP servers in domain specific backends, only one
|
||||||
|
could be put in default.
|
||||||
|
|
||||||
|
Today, if a depoloyer desires to keep two Keystone servers in sync
|
||||||
|
while avoiding Database replication, they must hack the database to
|
||||||
|
update the Domain ID so that entries match. Domain ID is then used for
|
||||||
|
LDAP mapped IDs, and if they don't match, the user IDs are
|
||||||
|
different. It should be possible to add a domain with an explicit ID,
|
||||||
|
so that the two servers can match User IDs.
|
||||||
|
|
||||||
|
An additional effort is underway to make the Federated Identity
|
||||||
|
sources use the same mechanism as LDAP. This effort is hampered
|
||||||
|
by the same domain_id restrictions as LDAP.
|
||||||
|
|
||||||
|
Making the identifiers consistant across multiple deployments will aid
|
||||||
|
in several use cases:
|
||||||
|
|
||||||
|
It will make it easier to synchronize role assignments across two
|
||||||
|
distinct deployments, as the user ID from the first can be used in the
|
||||||
|
second.
|
||||||
|
|
||||||
|
Applications will now be able to predict what user-id a user would
|
||||||
|
have in a cluster, even before that user visits the cluster. This
|
||||||
|
allows the system to pre-create user records, and have them link to
|
||||||
|
the identity source when the user does finally authenticate to the
|
||||||
|
Keystone server.
|
||||||
|
|
||||||
|
One structure that can be used for multiple depoloyments is for each
|
||||||
|
Keystone server to represent a different region, and for each region
|
||||||
|
to have a set of domains for which it is the system of record. This
|
||||||
|
allows local writes and avoids conflicts. In order for a central
|
||||||
|
system to keep track of the domain IDs, and to synchronize them across
|
||||||
|
different servers, one of the systems needs to be able to explicitly
|
||||||
|
assign them.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Proposed Change
|
||||||
|
===============
|
||||||
|
|
||||||
|
When creating a domain, the user can pass the optional parameter
|
||||||
|
`explicit_domain_id` to be used when creating the domain. A domain
|
||||||
|
created this way will not use an autogenerated id, but will use the id
|
||||||
|
passed in instead.
|
||||||
|
|
||||||
|
Identifiers passed in this way must conform to the existing ID
|
||||||
|
generation scheme: UUID4 without dashes.
|
||||||
|
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
Galera Sync of the database between sites. This will only scale to a
|
||||||
|
small number of locations. With local HA requirements of 3 nodes per
|
||||||
|
site, this will likely scale to a single digit number of locations.
|
||||||
|
|
||||||
|
Make Domain names immutable and change the scheme to use the names.
|
||||||
|
This will break all the existing LDAP deployments, as well as break
|
||||||
|
API backwards compatibility.
|
||||||
|
|
||||||
|
K2K Federation has been discussed as a way to help manage multiple
|
||||||
|
sites, but it does not address the need to make the User ID consistent
|
||||||
|
for Audit purposes. In addition, K2K adds an additional layer of SAML
|
||||||
|
indirection, without providing additional value here: it solves the
|
||||||
|
problem where users are stored in one Keystone server, but need access
|
||||||
|
to a separate cloud. As such, K2K will suffer from all the same
|
||||||
|
problems as any of Federated Identity Provider.
|
||||||
|
|
||||||
|
|
||||||
|
Security Impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
This should have little to no direct security impact. It will,
|
||||||
|
however, greatly aid in auditability, as user IDs can be correlated
|
||||||
|
across multiple deployments.
|
||||||
|
|
||||||
|
There is little risk of a domain administrator abusing this new option.
|
||||||
|
Creating a Domain is a rare operation, reserved for Cloud Admins. As such,
|
||||||
|
they are keeping domain IDs in sync to aid their own organizational goals.
|
||||||
|
If they chose to not sync a domain, it will only affect their own cluster, and
|
||||||
|
not the others. The degenerate case for Auditing will be the current state.
|
||||||
|
|
||||||
|
|
||||||
|
The IDs for users will now fall into the category of
|
||||||
|
"predictable-but-not-settable." Since the uuid is a hash of the
|
||||||
|
string, and not explicitly setable, the will not be a potential for
|
||||||
|
"User_ID squatting." where a user pre-allocates an entry to block
|
||||||
|
another user.
|
||||||
|
|
||||||
|
|
||||||
|
Notifications Impact
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Other End User Impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
|
||||||
|
Performance Impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Other Deployer Impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Developer Impact
|
||||||
|
----------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
|
||||||
|
Primary assignee:
|
||||||
|
Adam Young <ayoung>
|
||||||
|
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
Change to Keystone Server
|
||||||
|
Change to Openstack SDK
|
||||||
|
Change to OpenStack CLI
|
||||||
|
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Documentation Impact
|
||||||
|
====================
|
||||||
|
|
||||||
|
New option needs to be in documentation, including an update to the
|
||||||
|
LDAP and Federation docs.
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
None
|
Loading…
Reference in New Issue