[Kimchi-devel] [RFC] LDAP integration in kimchi

[Aline Manera]

On 10/15/2014 05:19 AM, Zhou Zheng Sheng wrote:
> on 2014/10/15 11:07, Royce Lv wrote:
>> On 2014年10月14日 21:03, Aline Manera wrote:
>>> On 10/14/2014 03:59 AM, Royce Lv wrote:
>>>> On 2014年10月14日 01:15, Aline Manera wrote:
>>>>> On 10/13/2014 03:43 AM, Royce Lv wrote:
>>>>>> LDAP supports connect to it (bind) for authentication,
>>>>>> usr/group/role add/delete for authorization.
>>>>>> For kimchi-LDAP integration we need to address following issues:
>>>>>>
>>>>>> 1. LDAP set up scripts for kimchi:
>>>>>> We need to add initial users: guest, admin; roles: netadmin,
>>>>>> hostadmin, guestadmin in LDAP server.
>>>>>> Adding these schema for user maybe a burden, we may supply a script
>>>>>> to init LDAP server configuration
>>>>>>
>>>>> We should be able to work with LDAP setup as it is, ie, without
>>>>> requiring any special configuration in the LDAP server for it.
>>>>> Today we only have 2 types of users: admin (with full access) and
>>>>> normal user (with restricted access).
>>>>> Later, when we support more type of users who will assign roles to
>>>>> users will be the admin users.
>>>>> Example: I am a "admin" user and I give you admin privileges to the
>>>>> network tab. I hope to have an UI for it. So user can assign roles
>>>>> to users in the UI. (But it is for later)
>>>>>
>>>>> So my suggestion is have a list of admin IDs in the Kimchi
>>>>> configuration file when the authentication method is LDAP.
>>>>> Example:
>>>>>
>>>>> On /etc/kimchi.conf we will have:
>>>>>
>>>>> [authentication]
>>>>> method = ldap | pam
>>>>>
>>>>> For LDAP method we will have addition config parameters:
>>>>>
>>>>> # For LDAP authentication
>>>>> ldap_server = ""
>>>>> ldap_search_base = ""
>>>>> ldap_search_filter = "mail=%(username)s"
>>>>> ldap_admin_users = "alinefm at linux.vnet.ibm.com
>>>>> lvroyce at linux.vnet.ibm.com"
>>>>>
>>>>> So after the logging we verify the user against the ldap_admin_users
>>>>> to know if this specific user has or not admin privileges.
>>>>> That way, we can support login using LDAP and also identify what are
>>>>> the admin users without special configuration in the LDAP server.
>>>> Well, I still think there are some advantages of using dedicate LDAP
>>>> for authentication and authorization.
>>>>
>>>> 1. If this LDAP is not for kimchi role maintainence, it can just
>>>> cover authentication not authorization.
>>> Yeap. I think that is the point we are diverging.
>>>
>>> We will use LDAP server *only for authentication*.
>>> Authorization will be handle by Kimchi - in a similar way we do for
>>> PAM authentication.
>>>
>>>> Authorization as you listed above spread over hosts, making role
>>>> maintenance difficult.
>>>> Thinking about a cluster of hosts, if you want add an admin like
>>>> alinefm at br.ibm.com, you change every config in these hosts.
>>> It will be part of the Kimchi configuration.
>>>
>>>> 2. Not convenient for role extension
>>>> If you want to levels like: virtualzation_admin(can create/destroy
>>>> vm), guest_admin(can start/stop vm),guest_user(can use vm)
>>>> We need to extend this configuration and this need kimchi upgrade
>>>> while keep it in LDAP you just add LDAP schema.
>>>>
>>> Thinking about PAM authentication: when we support more user roles,
>>> the map user/role will be store internally on Kimchi - let's say on
>>> objectstore.
>>> So we will provide some APIs to an admin user set/change an user role.
>>> We can do the same for LDAP authentication.
>>>
>>>> Also openstack-keystone both have dedicate LDAP to maintain its
>>>> users/roles.
>>>> http://www.ibm.com/developerworks/cloud/library/cl-ldap-keystone/index.html
>>>>
>>>>
>>>>
>>>> I suggest we aggregate authorization and authentication as they do
>>>> for extendibility and integrity of functionality.
>>> We don't need to integrate both to have functional setup.
>>> As I said before, we will handle Kimchi authorization inside Kimchi
>>> for PAM or LDAP authentication as it is only related to Kimchi and a
>>> LDAP server has more proposal than it.
>> Why do we do for our own (use objstore to store role/group) which LDAP
>> already be able to cover?
>>
>> LDAP is extensible if we have a cluster to maintain, put authorization
>> in configuration totally lose this extensibility, admin need to change
>> configuration hosts one by one,
>> which objstore also does not able to handle this extendibility.
>>
>> I can't say this approach brings us/users any benefit.
>> Also take a look at openstack, why we can't use the method they already
>> verified to be effective?
> I have some comments for your consideration.
>
> Kimchi is a small project targeting for
> small/testing/development/on-ramp use case, that is to say, Kimchi
> should be polite and noninvasive to the environment. Kimchi has to
> prepare itself to co-exist with other tools. OpenStack is a huge project
> union which dominates the environment. So not everything that OpenStack
> can do is what Kimchi also can do. Agree?
>
> A company may already have an ldap setup in production, for evaluating
> Kimchi, the admin may neither want to change the ldap configuration nor
> give write access to Kimchi. Kimchi may only read the ldap to do
> authentication. For example, suppose you are in a company named BigBlur
> ;-), and BigBlur has an ldap containing all the staff information. This
> ldap is under control of a world wide team, and the fields are fixed.
> Now a guy in Beijing lab wants to use Kimchi to manage 4 hosts, and he
> wants to use BigBlur ldap to allow only some of his colleagues to use
> Kimchi. If Kimchi has to store extended information in ldap, just
> considering how complicated the process is to communicate with the ldap
> team, he may just give up ldap and use PAM...
>
> I agree to Aline's suggestion. Kimchi can use an outside ldap just to
> authenticate users. Kimchi can use an inside objectstore to store the
> authorization matrix, and the groups. This gives us the flexibility to
> use any authorization scheme, for example, though you and me might be
> peers in BigBlur's ldap, but you can be the admin and I can be the user
> in Kimchi. This is just like how Jenkins-ci uses ldap.

When we support more user roles, the idea is to have a new tab on Kimchi 
to handle that configuration.
So in that tab, an admin user can set/change user role for LDAP or PAM 
users.

> As regard to the multi-host configuration problem, I think now that we
> already have peer discovering, we may also have configuration
> synchronization. For example, when a new Kimchi host is up, the user can
> "import" the authentication matrix from the other Kimchi host.

Yeap! That is a good idea.
I will add it to our backlog.

>>>>>
>>>>>> 2. Configuration of using LDAP:
>>>>>> Configured to use PAM/LDAP, Connecting to a dedicate LDAP server
>>>>>> address(As we may use an LDAP to store information of clustered
>>>>>> machine, address can be modified).
>>>>>> If this LDAP server does not exist, ask user if they want to setup
>>>>>> one, and help them with setup scripts.
>>>>>> For this release just support one LDAP per host.
>>>>>>
>>>>> No!
>>>>> The LDAP must be setup prior to use it as Kimchi authentication method.
>>>>> LDAP configuration is a system admin responsibility.
>>>> user may not a LDAP professional and schema writing may be error prone.
>>> The user can choose between PAM and LDAP. I don't expect to have
>>> non-LDAP expert using this type of authentication.
>>>
>>>>>> 3. Module for LDAP operation wrapping:
>>>>>> A dedicate module to encapsulate LDAP operations, such as
>>>>>> bind/unbind, adding, deleting, query groups/roles.
>>>>> I will not add/delete user from a LDAP directory.
>>>> See above.
>>>>>> 4. authentication:
>>>>>> We need to abstract authenticate class to be compatible with both
>>>>>> PAM and LDAP, and call bind/unbind to implement authentication.
>>>>>>
>>>>>> 5. authorization:
>>>>>> Abstract authentication module to distiguish PAM and LDAP, user
>>>>>> name still from cherrypy session, when using LDAP, user/role
>>>>>> information are all retrieved from LDAP server.
>>>>>>
>>>>> The username will get from the LDAP server but it is not true for
>>>>> user role as I explained above.
>>>>>
>>>>>> 6. user/role maintenance:
>>>>>> Manipulate LDAP to add user, delete user, authorize user with a
>>>>>> role, add role/delete role, and so on.
>>>>>> This part will not be covered in this release.
>>>>> No! We will not add/delete any information from the LDAP directory.
>>>>> We will only use it for query proposals.
>>>>>
>>>>>> _______________________________________________
>>>>>> Kimchi-devel mailing list
>>>>>> Kimchi-devel at ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>>>>
>>>>> Other point that is important is: how set a user/group to a VM?
>>>>> On UI, for PAM authentication, we list all users and groups and let
>>>>> user selects which he/she wants to user.
>>>>> This approach is unfeasible for a LDAP perspective.
>>>> If group design for control of a set of vms or resources(views)?
>>> To control vms - which users and groups will have access to a specific vm
>>>
>>>>> The users, from a LDAP perspective, will be the user mail, for
>>>>> example, so in this case we could only provide the user a filter box
>>>>> and list the available matches in the LDAP server.
>>>>>
>>>>> For groups, the values will come from LDAP search base and filter ?
>>>> That is why I want dedicate LDAP for authorization,
>>>> groups/roles/users all supplied.
>>>> If we just have user, we need to suplement this part in another data
>>>> store, I suppose.
>>> The authorization will be handle in the same way for PAM or LDAP
>>> authentication, ie, store it internally on Kimchi using objectstore or
>>> other type of data structure.
>>>
>>>>> We need to find a good and consistent way to do that independent of
>>>>> the authentication method to make the UI simpler.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>