Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1058484 - [RFE][keystone]: Domain-specific backend support
Summary: [RFE][keystone]: Domain-specific backend support
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-keystone
Version: 4.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: z2
: 6.0 (Juno)
Assignee: RHOS Maint
QA Contact: Udi
URL: https://blueprints.launchpad.net/keys...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-27 21:36 UTC by Eric Rich
Modified: 2018-12-06 15:45 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-09 14:46:48 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Eric Rich 2014-01-27 21:36:44 UTC
Description of problem:

Is there a way to setup Authentication of OpenStack to use LDAP for User's however still have the service users defined as part of keystone (MySQL)? 

Currently it seems that OpenStack 4.0 with Active Directory 2012 has the ability to use Split Authentication / Roles Management. By configuring the following drivers: 

    [identity]
    driver = keystone.identity.backends.ldap.Identity

    [assignment]
    driver = keystone.assignment.backends.sql.Assignment

The Assignment feature (driver) enables a combination of LDAP and SQL for Identity Service authentication and authorization. Assignment enables administrators to manage project and role authorization within Identity Service's own SQL database, while still providing user authentication using an LDAP directory. The Assignment driver is enabled in keystone.conf alongside the LDAP driver as shown above (or in the attached keystone.conf.example file). 

Once this was in place we created Service Users in Active Directory for the following users (ceilometer, cinder, glance, neutron, nova, swift), with these users in place we were able to update the PASSWORD directive in the following configuration files (for each of the services)[to match that of the users password in active directory]: 

    - /etc/neutron/api-paste.ini 
    - /etc/neutron/neutron.conf 
    - /etc/nova/nova.conf 
    - /etc/glance/glance-api.conf 
    - /etc/glance/glance-registry.conf 
    - /etc/cinder/api-paste.ini 
    - /etc/ceilometer/ceilometer.conf 
    # passwd swift <password>

Once the passwords were updated we were able to restart all of the OpenStack Services to use the updated user definitions (note this restart also restarts keystone which now has the split assignments, defined in the keystone.conf): 

    # openstack-service restart

To test that everything is working (connecting up to the Active Directory, and using the split assignments) we set the following: 

    - NOTE: This uses the admin_token from /etc/keystone/keystone.conf for the admin user as well as looks at the IP of eth0 for the service endpoint 
             (please adjust for your environment). 

    # export OS_SERVICE_TOKEN=$(grep admin_token /etc/keystone/keystone.conf | grep -vP '^\s*#|^\s*$' | awk -F ' ' '{print $3}')
    # export OS_SERVICE_ENDPOINT="http://$(ip addr | grep net | grep eth0 | awk '{print $2}' | awk -F/ '{print $1}'):35357/v2.0/"

Then ran the following commands: 

    # keystone user-list
    # keystone tenant-list
    # keystone role-list

These commands above should show you your users in LDAP (plus our newly added service users). It should also show you the Tenants (projects) and Roles from the MySQL database that is backing keystone (this is what we want to see). If not let us know. 

After this we want to see if there is any mapping for our LDAP users (service users) to a project and what role they have. To do this we want to run the following: 

    # for NAME in cinder glance neutron nova swift ceilometer ;  do keystone user-role-list --user $NAME --tenant services ; done
      -- OR (manually one at a time) --
    # keystone user-role-list --user SERVICE_USER --tenant services

This should show us that we do not have any mappings, because of this we need to add them (using the following): 

    # for NAME in cinder glance neutron nova swift ceilometer ;  do keystone user-role-add --user $NAME --role admin --tenant services ; done
      -- OR (manually one at a time) -- 
    # keystone user-role-add --name SERVICE_USER --role admin --tenant services

Actual results:

This places all Users in LDAP, and all authentication is done via LDAP

Expected results:

Horizon Users should use LDAP authentication however Serices (nova, glance, etc) should use MySQL and Keystone authentication.

Additional info:

This seems to be accomplished via a blacklist (using a custom hybrid.py script, on grizzly +). 

https://gist.github.com/mapleoin/3176390  Created by suse

https://review.openstack.org/gitweb?p=openstack%2Fkeystone.git;a=commitdiff;h=1963ae3a5f43c59bf51440ca839f3ff2a67fc1cc

There is commits upstream but it has not been accepted into trunk. I think this may be because its not on the blueprint list for acceptable use cases https://wiki.openstack.org/wiki/KeystoneUseCases .

Comment 2 Nathan Kinder 2014-01-28 16:47:19 UTC
There is currently no ability to split the users between two authentication sources upstream.  It is likely not a common use-case, as most administrators want to centralize identity/authentication.

It would be helpful to get more details on the use-case.  Specifically, why not just add the service users to LDAP (AD)?  Is this a case where AD is controlled by a different team who does not want to add the service users?

One solution here would be to use Identity Management in RHEL (IPA) to synchronize users from AD, then add the service users directly to IdM.  Keystone could then be configured to use IdM for identity, which would contain all of the users.

Comment 6 Stephen Gordon 2014-09-11 18:42:15 UTC
As I have identified another customer with this use case I would ask that we re-assess.

Comment 7 Stephen Gordon 2014-09-11 18:45:16 UTC
Adam are you able to assist with reviewing the bug and the case I attached, I am trying to confirm that functionality, implemented in Juno covers this use case appropriately?

Comment 8 Nathan Kinder 2014-09-11 21:21:35 UTC
The multiple-bakend support that is landing in Juno is designed to deal with this problem.  What this new functionality allows at a high-level is:

- The SQL identity backend will map to the default Keystone domain, which will contain service users.
- Additional Keystone domains can be defined that have a 1:1 mapping with an LDAP server.

This keeps the service users our of the LDAP server, and is designed for the common use-case of LDAP being treated as a read-only data source for users.

Comment 10 Nathan Kinder 2014-10-08 22:15:23 UTC
The desired functionality described in this bug (allowing service users to be in SQL and other users in LDAP) is possible in Juno via the domain-specific backend functionality.  This will be available in the version or RHEL OSP that is based off of Juno.

Comment 14 Rich Megginson 2015-01-20 17:06:38 UTC
Which installers do we want to support?  staypuft/foreman?  packstack?  spinal stack?  Does the customer require installer support, or is the customer satisfied with going in manually after installation and configuring the services?

Comment 15 Rich Megginson 2015-01-30 16:07:57 UTC
(In reply to Rich Megginson from comment #14)
> Which installers do we want to support?  staypuft/foreman?  packstack? 
> spinal stack?  Does the customer require installer support, or is the
> customer satisfied with going in manually after installation and configuring
> the services?

ping - can someone answer these questions?

Comment 17 Nathan Kinder 2015-03-09 14:46:48 UTC
It is already possible to set up a multi-domain Keystone deployment with SQL and LDAP backends in RHEL OSP 6.0.  The configuration must be done manually after installation.  A kbase draft that details this setup is in progress.

Installer support for this type of deployment is being handled in separate bugs.  Closing this as CURRENTRELEASE.


Note You need to log in before you can comment on or make changes to this bug.