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

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(a)linux.vnet.ibm.com >>>>> lvroyce(a)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(a)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(a)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. >>>>> >>>>> >>>>> >>>>> >>>>>