Explicit Domain Ids

Change-Id: I49bdc1b051f0beb5e0c1fb19a749c8c6a546db92
This commit is contained in:
Adam Young 2018-10-16 20:23:53 -04:00
parent bc79138906
commit bf8a22f46a
1 changed files with 185 additions and 0 deletions

View File

@ -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