Re: [Users] API read-only access / roles
- Original Message - > From: "Itamar Heim" > To: "Sven Kieske" , "Users@ovirt.org List" > , "Yair Zaslavsky" > > Sent: Wednesday, March 26, 2014 12:46:28 PM > Subject: Re: [Users] API read-only access / roles > > On 03/26/2014 06:39 AM, Sven Kieske wrote: > > > > > > Am 26.03.2014 11:21, schrieb Itamar Heim: > >> On 03/26/2014 06:16 AM, Sven Kieske wrote: > >>> Hi, > >>> > >>> as we now have setup ldap, now the question which > >>> never got answered in the first place: > >>> > >>> 1. > >>> which rights do I need for read only access? > >>> > >>> as stated in BZ just login rights won't suffice. > >> > >> an admin role with login? why not? > >> i thought we even pre-created such a default read only role by now: > >> Bug 1038222 - [RFE] Read Only Admin role in AP > >> > >> (and you can create one yourself in 3.3 as well iirc) > >> > > What would happen if I create this user myself > > and I want to upgrade to 3.4 somewhere in time? > > > > My guess would be the upgrade would fail if this > > user gets added automatically, because it is already > > there? > > > > its not a user. its a system defined role. > you can create a user defined role (with a different name) > you should do this via the GUI in 3.3, not via the db (then the uuid > will be different as well, and no upgrade issues) Regarding your upgrade question - I would like to add that although we have a hard-coded internal admin user, your "read only" user (that is, a user you assigned the role you created) is not a hard coded one. I don't think we will go for a strategy of adding another "hardcoded" user for read only , so you should not have upgrade issues. > ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] API read-only access / roles
Thanks again, it seems to work quite well (couldn't test everything). Am 26.03.2014 11:46, schrieb Itamar Heim: > its not a user. its a system defined role. > you can create a user defined role (with a different name) > you should do this via the GUI in 3.3, not via the db (then the uuid > will be different as well, and no upgrade issues) -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] API read-only access / roles
On 03/26/2014 06:39 AM, Sven Kieske wrote: Am 26.03.2014 11:21, schrieb Itamar Heim: On 03/26/2014 06:16 AM, Sven Kieske wrote: Hi, as we now have setup ldap, now the question which never got answered in the first place: 1. which rights do I need for read only access? as stated in BZ just login rights won't suffice. an admin role with login? why not? i thought we even pre-created such a default read only role by now: Bug 1038222 - [RFE] Read Only Admin role in AP (and you can create one yourself in 3.3 as well iirc) What would happen if I create this user myself and I want to upgrade to 3.4 somewhere in time? My guess would be the upgrade would fail if this user gets added automatically, because it is already there? its not a user. its a system defined role. you can create a user defined role (with a different name) you should do this via the GUI in 3.3, not via the db (then the uuid will be different as well, and no upgrade issues) ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] API read-only access / roles
Am 26.03.2014 11:21, schrieb Itamar Heim: > On 03/26/2014 06:16 AM, Sven Kieske wrote: >> Hi, >> >> as we now have setup ldap, now the question which >> never got answered in the first place: >> >> 1. >> which rights do I need for read only access? >> >> as stated in BZ just login rights won't suffice. > > an admin role with login? why not? > i thought we even pre-created such a default read only role by now: > Bug 1038222 - [RFE] Read Only Admin role in AP > > (and you can create one yourself in 3.3 as well iirc) > What would happen if I create this user myself and I want to upgrade to 3.4 somewhere in time? My guess would be the upgrade would fail if this user gets added automatically, because it is already there? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] API read-only access / roles
Well Doron replied to me with another information here: https://bugzilla.redhat.com/show_bug.cgi?id=1067036#c1 I did not know of BZ 1038 nor did anybody point me there. How to create it myself in 3.3, directly via the SQL Command? Is this safe on a 3.3.3-2 el6? See the attached SQL Am 26.03.2014 11:21, schrieb Itamar Heim: > > an admin role with login? why not? > i thought we even pre-created such a default read only role by now: > Bug 1038222 - [RFE] Read Only Admin role in AP > > (and you can create one yourself in 3.3 as well iirc) -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen Create or replace FUNCTION __temp_insert_read_only_admin_role() 1 RETURNS VOID 2 AS $procedure$ 3 DECLARE 4 v_ROLE_ID UUID; 5 BEGIN 6 v_ROLE_ID := 'DEFC----DEFC'; 7 8 DELETE FROM roles_groups WHERE role_id = v_ROLE_ID; 9 INSERT INTO roles(id,name,description,is_readonly,role_type,allows_viewing_children,app_mode) SELECT v_ROLE_ID, 'ReadOnlyAdmin', 'Read Only Administrator Role', true, 1, true, 1 10 WHERE NOT EXISTS (SELECT id,name,description,is_readonly,role_type 11 FROM roles 12 WHERE id = v_ROLE_ID 13 AND name='ReadOnlyAdmin' 14 AND description='Read Only Administrator Role' 15 AND is_readonly=true 16 AND role_type=1); 17 18 -- Allowing this role to login 19 INSERT INTO roles_groups(role_id,action_group_id) VALUES(v_ROLE_ID, 1300); 20 21 RETURN; 22 END; $procedure$ 23 LANGUAGE plpgsql; 24 25 SELECT __temp_insert_read_only_admin_role(); 26 DROP function __temp_insert_read_only_admin_role(); ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] API read-only access / roles
On 03/26/2014 06:16 AM, Sven Kieske wrote: Hi, as we now have setup ldap, now the question which never got answered in the first place: 1. which rights do I need for read only access? as stated in BZ just login rights won't suffice. an admin role with login? why not? i thought we even pre-created such a default read only role by now: Bug 1038222 - [RFE] Read Only Admin role in AP (and you can create one yourself in 3.3 as well iirc) 2. I want to create a user who has just the right to open the vnc/spice connection to every vm, is this possible? but not start/stop VMs? via admin or user portal (changed the type of role you need to give admin/user) just create a role with: login, connect vm, and give it at system level to the user ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] API read-only access / roles
Hi, as we now have setup ldap, now the question which never got answered in the first place: 1. which rights do I need for read only access? as stated in BZ just login rights won't suffice. 2. I want to create a user who has just the right to open the vnc/spice connection to every vm, is this possible? Thanks in advance -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] API read-only access / roles
Hi, will this interface for 3.5 be production ready or just a first release /draft ? Would it be possible to add a read only user for 3.4.x releases? Am 23.02.2014 09:52, schrieb Alon Bar-Lev: > > > - Original Message - >> From: "Yair Zaslavsky" >> To: "Juan Hernandez" >> Cc: "Sven Kieske" , "Users@ovirt.org List" >> , "Itamar Heim" , >> "Alon Bar-Lev" >> Sent: Sunday, February 23, 2014 8:55:07 AM >> Subject: Re: [Users] API read-only access / roles >> >> >> >> - Original Message - >>> From: "Juan Hernandez" >>> To: "Sven Kieske" , "Users@ovirt.org List" >>> >>> Cc: "Itamar Heim" , "Yair Zaslavsky" >>> >>> Sent: Saturday, February 22, 2014 2:22:14 PM >>> Subject: Re: [Users] API read-only access / roles >>> >>> On 02/20/2014 04:51 PM, Itamar Heim wrote: >>>> On 02/20/2014 05:24 PM, Sven Kieske wrote: >>>>> Hi, >>>>> >>>>> is nobody interested in this feature at all? >>>>> it would be a huge security gain, while lowering >>>>> the bars for having a read only user if this could get shipped with 3.4: >>>> >>>> we are very interested, but we want to do this based on the >>>> authentication re-factoring, which in itself, barely made the 3.4 >>>> timeline. >>>> Yair - are we "pluggable" yet, that someone could add such a user by >>>> dropping a jar somewhere, or still on going work towards 3.5? >> >> As Juan mentioned in his email, it should be possible to plug in at 3.4 as >> well. >> However, we're changing the configuration format at 3.5 as we're changing the >> mechanism to use the extensions mechanism - both Directory and Authenticator >> are extensions, the configuration for >> directory (authorization extension) and authenciator (authentication >> extension) will look a bit different. > > Hello, > > Until we announce public interface for aaa (authentication, authorization, > accounting) the implementation is internal and should not be used by external > projects. > > We are heading for publishing the interface within 3.5 timeline. > > Thanks, > Alon > >> >> >> >> >>>> >>> >>> Pugglability of authentication already works in 3.4. By default it uses >>> the previous mechanism, but the administrator can change this. In order >>> to change you need to create the /etc/ovirt-engine/auth.conf.d directory >>> and then create inside one or more "authentication profiles" >>> configuration files. An authentication profile is a combination of an >>> "authenticator" and a "directory". The authenticator is used to check >>> the credentials (the user name and password) and the "directory" is used >>> to search users and their details. For example, if you want to use local >>> authentication (the users, passwords, and groups of the OS) you can >>> create a "local.conf" file with the following content: >>> >>> # >>> # The name of the profile. This is what will be displayed in the >>> # combo box in the login page. >>> # >>> name=local >>> >>> # >>> # Needed to enable the profile, by default all profiles are >>> # disabled. >>> # >>> enabled=true >>> >>> # >>> # The configuration of the authenticator used by the profile. The >>> # type and the module are mandatory, the rest are optional and >>> # the default values are as shown below. >>> # >>> authenticator.type=ssh >>> authenticator.module=org.ovirt.engine.core.authentication.ssh >>> # authenticator.host=localhost >>> # authenticator.port=22 >>> # authenticator.timeout=10 >>> >>> # >>> # The configuration of the directory: >>> # >>> directory.type=nss >>> directory.module=org.ovirt.engine.core.authentication.nss >>> >>> For this to work you need to install some additional modules, which >>> aren't currently part of the engine. This is where plugabillity comes in >>> place. This modules can be built externally. I created modules for SSH >>> authentication and NSS (Name Service Switch) directory. The source is >>> available here: >>> >>> https://github.co
Re: [Users] API read-only access / roles
First, thanks for all the insightful replies. As we would want to use this user in production I'm not very interested in testing the mentioned API from Juan (although I appreciate the work). It's cool to hear UNIX users will be supported. However it seems quite some overhead to implement it for just one read only user and it might not work at all, given the maturity of the code. So I'd like to ask again if a built in user would be possible for 3.4 or 3.4.1 I guess many people would use it. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] API read-only access / roles
- Original Message - > From: "Yair Zaslavsky" > To: "Juan Hernandez" > Cc: "Sven Kieske" , "Users@ovirt.org List" > , "Itamar Heim" , > "Alon Bar-Lev" > Sent: Sunday, February 23, 2014 8:55:07 AM > Subject: Re: [Users] API read-only access / roles > > > > - Original Message - > > From: "Juan Hernandez" > > To: "Sven Kieske" , "Users@ovirt.org List" > > > > Cc: "Itamar Heim" , "Yair Zaslavsky" > > > > Sent: Saturday, February 22, 2014 2:22:14 PM > > Subject: Re: [Users] API read-only access / roles > > > > On 02/20/2014 04:51 PM, Itamar Heim wrote: > > > On 02/20/2014 05:24 PM, Sven Kieske wrote: > > >> Hi, > > >> > > >> is nobody interested in this feature at all? > > >> it would be a huge security gain, while lowering > > >> the bars for having a read only user if this could get shipped with 3.4: > > > > > > we are very interested, but we want to do this based on the > > > authentication re-factoring, which in itself, barely made the 3.4 > > > timeline. > > > Yair - are we "pluggable" yet, that someone could add such a user by > > > dropping a jar somewhere, or still on going work towards 3.5? > > As Juan mentioned in his email, it should be possible to plug in at 3.4 as > well. > However, we're changing the configuration format at 3.5 as we're changing the > mechanism to use the extensions mechanism - both Directory and Authenticator > are extensions, the configuration for > directory (authorization extension) and authenciator (authentication > extension) will look a bit different. Hello, Until we announce public interface for aaa (authentication, authorization, accounting) the implementation is internal and should not be used by external projects. We are heading for publishing the interface within 3.5 timeline. Thanks, Alon > > > > > > > > > > > Pugglability of authentication already works in 3.4. By default it uses > > the previous mechanism, but the administrator can change this. In order > > to change you need to create the /etc/ovirt-engine/auth.conf.d directory > > and then create inside one or more "authentication profiles" > > configuration files. An authentication profile is a combination of an > > "authenticator" and a "directory". The authenticator is used to check > > the credentials (the user name and password) and the "directory" is used > > to search users and their details. For example, if you want to use local > > authentication (the users, passwords, and groups of the OS) you can > > create a "local.conf" file with the following content: > > > > # > > # The name of the profile. This is what will be displayed in the > > # combo box in the login page. > > # > > name=local > > > > # > > # Needed to enable the profile, by default all profiles are > > # disabled. > > # > > enabled=true > > > > # > > # The configuration of the authenticator used by the profile. The > > # type and the module are mandatory, the rest are optional and > > # the default values are as shown below. > > # > > authenticator.type=ssh > > authenticator.module=org.ovirt.engine.core.authentication.ssh > > # authenticator.host=localhost > > # authenticator.port=22 > > # authenticator.timeout=10 > > > > # > > # The configuration of the directory: > > # > > directory.type=nss > > directory.module=org.ovirt.engine.core.authentication.nss > > > > For this to work you need to install some additional modules, which > > aren't currently part of the engine. This is where plugabillity comes in > > place. This modules can be built externally. I created modules for SSH > > authentication and NSS (Name Service Switch) directory. The source is > > available here: > > > > https://github.com/jhernand/ovirt-engine-ssh-authenticator > > https://github.com/jhernand/ovirt-engine-nss-directory > > > > The NSS directory also needs JNA (Java Native Access): > > > > https://github.com/jhernand/ovirt-engine-jna-module > > > > Installing these extensions is very easy, just build from source and > > uncompress the generated .zip files to /usr/share/ovirt-engine/modules. > > In case you don't want to build from source you can use the RPMs th
Re: [Users] API read-only access / roles
- Original Message - > From: "Yair Zaslavsky" > To: "Juan Hernandez" > Cc: "Users@ovirt.org List" > Sent: Sunday, February 23, 2014 8:55:07 AM > Subject: Re: [Users] API read-only access / roles > > > > - Original Message - > > From: "Juan Hernandez" > > To: "Sven Kieske" , "Users@ovirt.org List" > > > > Cc: "Itamar Heim" , "Yair Zaslavsky" > > > > Sent: Saturday, February 22, 2014 2:22:14 PM > > Subject: Re: [Users] API read-only access / roles > > > > On 02/20/2014 04:51 PM, Itamar Heim wrote: > > > On 02/20/2014 05:24 PM, Sven Kieske wrote: > > >> Hi, > > >> > > >> is nobody interested in this feature at all? > > >> it would be a huge security gain, while lowering > > >> the bars for having a read only user if this could get shipped with 3.4: > > > > > > we are very interested, but we want to do this based on the > > > authentication re-factoring, which in itself, barely made the 3.4 > > > timeline. > > > Yair - are we "pluggable" yet, that someone could add such a user by > > > dropping a jar somewhere, or still on going work towards 3.5? > > As Juan mentioned in his email, it should be possible to plug in at 3.4 as > well. > However, we're changing the configuration format at 3.5 as we're changing the > mechanism to use the extensions mechanism - both Directory and Authenticator > are extensions, the configuration for > directory (authorization extension) and authenciator (authentication > extension) will look a bit different. CC'ed Sven as well, In addition bare in mind as Directory and Authenticator will be extensions, there will be some interface change. Yair > > > > > > > > > > > Pugglability of authentication already works in 3.4. By default it uses > > the previous mechanism, but the administrator can change this. In order > > to change you need to create the /etc/ovirt-engine/auth.conf.d directory > > and then create inside one or more "authentication profiles" > > configuration files. An authentication profile is a combination of an > > "authenticator" and a "directory". The authenticator is used to check > > the credentials (the user name and password) and the "directory" is used > > to search users and their details. For example, if you want to use local > > authentication (the users, passwords, and groups of the OS) you can > > create a "local.conf" file with the following content: > > > > # > > # The name of the profile. This is what will be displayed in the > > # combo box in the login page. > > # > > name=local > > > > # > > # Needed to enable the profile, by default all profiles are > > # disabled. > > # > > enabled=true > > > > # > > # The configuration of the authenticator used by the profile. The > > # type and the module are mandatory, the rest are optional and > > # the default values are as shown below. > > # > > authenticator.type=ssh > > authenticator.module=org.ovirt.engine.core.authentication.ssh > > # authenticator.host=localhost > > # authenticator.port=22 > > # authenticator.timeout=10 > > > > # > > # The configuration of the directory: > > # > > directory.type=nss > > directory.module=org.ovirt.engine.core.authentication.nss > > > > For this to work you need to install some additional modules, which > > aren't currently part of the engine. This is where plugabillity comes in > > place. This modules can be built externally. I created modules for SSH > > authentication and NSS (Name Service Switch) directory. The source is > > available here: > > > > https://github.com/jhernand/ovirt-engine-ssh-authenticator > > https://github.com/jhernand/ovirt-engine-nss-directory > > > > The NSS directory also needs JNA (Java Native Access): > > > > https://github.com/jhernand/ovirt-engine-jna-module > > > > Installing these extensions is very easy, just build from source and > > uncompress the generated .zip files to /usr/share/ovirt-engine/modules. > > In case you don't want to build from source you can use the RPMs that I > > created. The source for the .spec files is here: > > > > https://github.com/jhernand/ovirt-engine-rpms > > > > If you don't want to build form source you can use a yum repository th
Re: [Users] API read-only access / roles
- Original Message - > From: "Juan Hernandez" > To: "Sven Kieske" , "Users@ovirt.org List" > > Cc: "Itamar Heim" , "Yair Zaslavsky" > Sent: Saturday, February 22, 2014 2:22:14 PM > Subject: Re: [Users] API read-only access / roles > > On 02/20/2014 04:51 PM, Itamar Heim wrote: > > On 02/20/2014 05:24 PM, Sven Kieske wrote: > >> Hi, > >> > >> is nobody interested in this feature at all? > >> it would be a huge security gain, while lowering > >> the bars for having a read only user if this could get shipped with 3.4: > > > > we are very interested, but we want to do this based on the > > authentication re-factoring, which in itself, barely made the 3.4 timeline. > > Yair - are we "pluggable" yet, that someone could add such a user by > > dropping a jar somewhere, or still on going work towards 3.5? As Juan mentioned in his email, it should be possible to plug in at 3.4 as well. However, we're changing the configuration format at 3.5 as we're changing the mechanism to use the extensions mechanism - both Directory and Authenticator are extensions, the configuration for directory (authorization extension) and authenciator (authentication extension) will look a bit different. > > > > Pugglability of authentication already works in 3.4. By default it uses > the previous mechanism, but the administrator can change this. In order > to change you need to create the /etc/ovirt-engine/auth.conf.d directory > and then create inside one or more "authentication profiles" > configuration files. An authentication profile is a combination of an > "authenticator" and a "directory". The authenticator is used to check > the credentials (the user name and password) and the "directory" is used > to search users and their details. For example, if you want to use local > authentication (the users, passwords, and groups of the OS) you can > create a "local.conf" file with the following content: > > # > # The name of the profile. This is what will be displayed in the > # combo box in the login page. > # > name=local > > # > # Needed to enable the profile, by default all profiles are > # disabled. > # > enabled=true > > # > # The configuration of the authenticator used by the profile. The > # type and the module are mandatory, the rest are optional and > # the default values are as shown below. > # > authenticator.type=ssh > authenticator.module=org.ovirt.engine.core.authentication.ssh > # authenticator.host=localhost > # authenticator.port=22 > # authenticator.timeout=10 > > # > # The configuration of the directory: > # > directory.type=nss > directory.module=org.ovirt.engine.core.authentication.nss > > For this to work you need to install some additional modules, which > aren't currently part of the engine. This is where plugabillity comes in > place. This modules can be built externally. I created modules for SSH > authentication and NSS (Name Service Switch) directory. The source is > available here: > > https://github.com/jhernand/ovirt-engine-ssh-authenticator > https://github.com/jhernand/ovirt-engine-nss-directory > > The NSS directory also needs JNA (Java Native Access): > > https://github.com/jhernand/ovirt-engine-jna-module > > Installing these extensions is very easy, just build from source and > uncompress the generated .zip files to /usr/share/ovirt-engine/modules. > In case you don't want to build from source you can use the RPMs that I > created. The source for the .spec files is here: > > https://github.com/jhernand/ovirt-engine-rpms > > If you don't want to build form source you can use a yum repository that > I created with binaries for Fedora 20 (should work in CentOS as well): > > http://jhernand.fedorapeople.org/repo > > So, to summarize: > > # cat > /etc/yum.repos.d/my.repo <<. > [my] > name=my > baseurl=http://jhernand.fedorapeople.org/repo > enabled=1 > gpgcheck=0 > . > > # yum -y install \ > ovirt-engine-ssh-authenticator \ > ovirt-engine-nss-directory > > # mkdir -p /etc/ovirt-engine/auth.conf.d > > # cat > /etc/ovirt-engine/auth.conf.d/local.conf <<. > name=local > enabled=true > authenticator.type=ssh > authenticator.module=org.ovirt.engine.core.authentication.ssh > directory.type=nss > directory.module=org.ovirt.engine.core.authentication.nss > . > > # systemctl restart ovirt-engine > > Then you can login with admin@internal, add some local users and > permissions, and
Re: [Users] API read-only access / roles
On 02/20/2014 04:51 PM, Itamar Heim wrote: > On 02/20/2014 05:24 PM, Sven Kieske wrote: >> Hi, >> >> is nobody interested in this feature at all? >> it would be a huge security gain, while lowering >> the bars for having a read only user if this could get shipped with 3.4: > > we are very interested, but we want to do this based on the > authentication re-factoring, which in itself, barely made the 3.4 timeline. > Yair - are we "pluggable" yet, that someone could add such a user by > dropping a jar somewhere, or still on going work towards 3.5? > Pugglability of authentication already works in 3.4. By default it uses the previous mechanism, but the administrator can change this. In order to change you need to create the /etc/ovirt-engine/auth.conf.d directory and then create inside one or more "authentication profiles" configuration files. An authentication profile is a combination of an "authenticator" and a "directory". The authenticator is used to check the credentials (the user name and password) and the "directory" is used to search users and their details. For example, if you want to use local authentication (the users, passwords, and groups of the OS) you can create a "local.conf" file with the following content: # # The name of the profile. This is what will be displayed in the # combo box in the login page. # name=local # # Needed to enable the profile, by default all profiles are # disabled. # enabled=true # # The configuration of the authenticator used by the profile. The # type and the module are mandatory, the rest are optional and # the default values are as shown below. # authenticator.type=ssh authenticator.module=org.ovirt.engine.core.authentication.ssh # authenticator.host=localhost # authenticator.port=22 # authenticator.timeout=10 # # The configuration of the directory: # directory.type=nss directory.module=org.ovirt.engine.core.authentication.nss For this to work you need to install some additional modules, which aren't currently part of the engine. This is where plugabillity comes in place. This modules can be built externally. I created modules for SSH authentication and NSS (Name Service Switch) directory. The source is available here: https://github.com/jhernand/ovirt-engine-ssh-authenticator https://github.com/jhernand/ovirt-engine-nss-directory The NSS directory also needs JNA (Java Native Access): https://github.com/jhernand/ovirt-engine-jna-module Installing these extensions is very easy, just build from source and uncompress the generated .zip files to /usr/share/ovirt-engine/modules. In case you don't want to build from source you can use the RPMs that I created. The source for the .spec files is here: https://github.com/jhernand/ovirt-engine-rpms If you don't want to build form source you can use a yum repository that I created with binaries for Fedora 20 (should work in CentOS as well): http://jhernand.fedorapeople.org/repo So, to summarize: # cat > /etc/yum.repos.d/my.repo <<. [my] name=my baseurl=http://jhernand.fedorapeople.org/repo enabled=1 gpgcheck=0 . # yum -y install \ ovirt-engine-ssh-authenticator \ ovirt-engine-nss-directory # mkdir -p /etc/ovirt-engine/auth.conf.d # cat > /etc/ovirt-engine/auth.conf.d/local.conf <<. name=local enabled=true authenticator.type=ssh authenticator.module=org.ovirt.engine.core.authentication.ssh directory.type=nss directory.module=org.ovirt.engine.core.authentication.nss . # systemctl restart ovirt-engine Then you can login with admin@internal, add some local users and permissions, and then use them to login to the GUI or the API. Take into account that I created these modules as a way to test the new authentication infrastructure, so they may have limitations or issues. I appreciate any feedback. >> >> Am 19.02.2014 15:32, schrieb Sven Kieske:> I just looked into my test vm >> with the 3.4 beta >>> and I can't see such an user there. >>> >>> I created an RFE at: https://bugzilla.redhat.com/show_bug.cgi?id=1067036 >>> >>> >>> I really hope this can get included in 3.4 (I know it's late) >>> as it should be a very very minor change at engine-setup. >>> >>> Thanks >>> >>> Am 19.02.2014 14:55, schrieb Sven Kieske: Hi, reiterating on this somewhat old mail: Is there a read only user integrated in 3.4? Because it's a huge overhead to install somewhere e.g. a freeipa server just to get read only access. Am 21.11.2013 09:52, schrieb Sander Grendelman: > Hi Doron, > > The user I've defined in [1] works for me. > A built-in login-/read-only role would be nice, > but it's quite easy to define a custom role so > more of a nice-to-have instead of a must-have. > > Thanks for asking! > > Sander. > > On Wed, Nov 20, 2013 at 5:40 PM, Doron Fediuck >> wrote: >> Hi Sander, >> We're closing the ovirt 3.4 scope, and wondering if you're handling >> Zabbix based on [1]. >>
Re: [Users] API read-only access / roles
On 02/20/2014 05:24 PM, Sven Kieske wrote: Hi, is nobody interested in this feature at all? it would be a huge security gain, while lowering the bars for having a read only user if this could get shipped with 3.4: we are very interested, but we want to do this based on the authentication re-factoring, which in itself, barely made the 3.4 timeline. Yair - are we "pluggable" yet, that someone could add such a user by dropping a jar somewhere, or still on going work towards 3.5? Am 19.02.2014 15:32, schrieb Sven Kieske:> I just looked into my test vm with the 3.4 beta and I can't see such an user there. I created an RFE at: https://bugzilla.redhat.com/show_bug.cgi?id=1067036 I really hope this can get included in 3.4 (I know it's late) as it should be a very very minor change at engine-setup. Thanks Am 19.02.2014 14:55, schrieb Sven Kieske: Hi, reiterating on this somewhat old mail: Is there a read only user integrated in 3.4? Because it's a huge overhead to install somewhere e.g. a freeipa server just to get read only access. Am 21.11.2013 09:52, schrieb Sander Grendelman: Hi Doron, The user I've defined in [1] works for me. A built-in login-/read-only role would be nice, but it's quite easy to define a custom role so more of a nice-to-have instead of a must-have. Thanks for asking! Sander. On Wed, Nov 20, 2013 at 5:40 PM, Doron Fediuck wrote: Hi Sander, We're closing the ovirt 3.4 scope, and wondering if you're handling Zabbix based on [1]. If so please let me know and I'll update the 3.4 features list. Thanks, Doron [1] http://lists.ovirt.org/pipermail/users/2013-November/017946.html ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] API read-only access / roles
Hi, is nobody interested in this feature at all? it would be a huge security gain, while lowering the bars for having a read only user if this could get shipped with 3.4: Am 19.02.2014 15:32, schrieb Sven Kieske:> I just looked into my test vm with the 3.4 beta > and I can't see such an user there. > > I created an RFE at: https://bugzilla.redhat.com/show_bug.cgi?id=1067036 > > > I really hope this can get included in 3.4 (I know it's late) > as it should be a very very minor change at engine-setup. > > Thanks > > Am 19.02.2014 14:55, schrieb Sven Kieske: >> Hi, >> >> reiterating on this somewhat old mail: >> >> Is there a read only user integrated in 3.4? >> >> Because it's a huge overhead to install somewhere >> e.g. a freeipa server just to get read only access. >> >> Am 21.11.2013 09:52, schrieb Sander Grendelman: >>> Hi Doron, >>> >>> The user I've defined in [1] works for me. >>> A built-in login-/read-only role would be nice, >>> but it's quite easy to define a custom role so >>> more of a nice-to-have instead of a must-have. >>> >>> Thanks for asking! >>> >>> Sander. >>> >>> On Wed, Nov 20, 2013 at 5:40 PM, Doron Fediuck wrote: Hi Sander, We're closing the ovirt 3.4 scope, and wondering if you're handling Zabbix based on [1]. If so please let me know and I'll update the 3.4 features list. Thanks, Doron [1] http://lists.ovirt.org/pipermail/users/2013-November/017946.html >> > -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] API read-only access / roles
Hello Sander, where can I find more informations about your zabbix monitoring plugin? We are using zabbix and also rhev and ovirt so I can (and would like to) test it. thanks Jiri Dne 18.11.2013 16:46, Sander Grendelman napsal(a): I'm working on (Zabbix) monitoring through the RESTful API. Which role should I assign to the monitoring user? The user only needs read access to the data but it looks like I nead to assign at least an "Admin" role to the user to be able to read data through the API. For this I've created a "AdminLoginOnly" role that only has System->Configure System->Login Permissions access. Is this the way to go for this king of configuration? Or is there a way to further minimize the permissions of this user? Another issue is that a "Login" event is generated every time the user connects through the API. This makes the "Events" pane less useful / readable. Is there a way to disable this for some users/roles? ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users <> smime.p7s Description: Elektronicky podpis S/MIME ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] API read-only access / roles
I just looked into my test vm with the 3.4 beta and I can't see such an user there. I created an RFE at: https://bugzilla.redhat.com/show_bug.cgi?id=1067036 I really hope this can get included in 3.4 (I know it's late) as it should be a very very minor change at engine-setup. Thanks Am 19.02.2014 14:55, schrieb Sven Kieske: > Hi, > > reiterating on this somewhat old mail: > > Is there a read only user integrated in 3.4? > > Because it's a huge overhead to install somewhere > e.g. a freeipa server just to get read only access. > > Am 21.11.2013 09:52, schrieb Sander Grendelman: >> Hi Doron, >> >> The user I've defined in [1] works for me. >> A built-in login-/read-only role would be nice, >> but it's quite easy to define a custom role so >> more of a nice-to-have instead of a must-have. >> >> Thanks for asking! >> >> Sander. >> >> On Wed, Nov 20, 2013 at 5:40 PM, Doron Fediuck wrote: >>> Hi Sander, >>> We're closing the ovirt 3.4 scope, and wondering if you're handling >>> Zabbix based on [1]. >>> If so please let me know and I'll update the 3.4 features list. >>> >>> Thanks, >>> Doron >>> >>> [1] http://lists.ovirt.org/pipermail/users/2013-November/017946.html > -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] API read-only access / roles
Hi, reiterating on this somewhat old mail: Is there a read only user integrated in 3.4? Because it's a huge overhead to install somewhere e.g. a freeipa server just to get read only access. Am 21.11.2013 09:52, schrieb Sander Grendelman: > Hi Doron, > > The user I've defined in [1] works for me. > A built-in login-/read-only role would be nice, > but it's quite easy to define a custom role so > more of a nice-to-have instead of a must-have. > > Thanks for asking! > > Sander. > > On Wed, Nov 20, 2013 at 5:40 PM, Doron Fediuck wrote: >> Hi Sander, >> We're closing the ovirt 3.4 scope, and wondering if you're handling >> Zabbix based on [1]. >> If so please let me know and I'll update the 3.4 features list. >> >> Thanks, >> Doron >> >> [1] http://lists.ovirt.org/pipermail/users/2013-November/017946.html -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] API read-only access / roles
On Tue, 2013-11-19 at 09:55 +0100, Sander Grendelman wrote: > On Mon, Nov 18, 2013 at 5:18 PM, René Koch (ovido) wrote: > > Very nice - do you use my check_rhev3 Nagios plugin > > (https://github.com/ovido/check_rhev3) or are you working on > > your own script? > > At the moment: both. The problem with using Nagios scripts in Zabbix is that > the trigger/alarm decision is made in different places. In Nagios this is done > in the check scripts / on the "client" side while Zabbix mainly > collects data and > fires triggers if certain conditions in that data are met. Yes that's true. Maybe adding a Zabbix compatibility mode for check_rhev3 could also be an option where no decisions about the status is done in the script so you can let Zabbix triggers handle this? Anyway I think you're much more experienced with Zabbix then I am, so you properly know better what's the best solution for monitoring oVirt with Zabbix... > > New(er) Zabbix versions also have a feature called "low level discovery" that > automatically creates items. > > It also seems that there is better RESTful/ovirt API support in python > so I'm giving > that a try too. Although perl is usually my poison of choice too ;) Yes, the Python SDK is really good. But as I'm more experienced with Perl I don't use it often... > > >> For this I've created a "AdminLoginOnly" role that only has > >> System->Configure System->Login Permissions access. > >> > >> Is this the way to go for this king of configuration? Or is there > >> a way to further minimize the permissions of this user? > > > > I create a custom role with these permissions for Nagios monitoring, > > too. > > I was thinking that in oVirt 3.3 there should be a predefined > > viewers-role, but can't find it in my setup :( > > OK, that would have been nice, do you have any history on this one? > > >> Another issue is that a "Login" event is generated every time > >> the user connects through the API. This makes the "Events" > >> pane less useful / readable. Is there a way to disable this for > >> some users/roles? > > > > > > It depends if you have your own script or check_rhev3: > > - check_rhev3 1.2: use option -o > > - check_rhev3 1.3: you should not see any login information in this > > version anymore > > - custom script: see this page on information how to use the JSESSIONID > > cookie: http://www.ovirt.org/Features/RESTSessionManagement > > Thanks for the info I'll look into this. > > It does make the logic in the script a bit harder because you have to store > the sessionid somewhere and check if the session is still valid. I'm not sure if Session management works out of the box in Python SDK (I think so), so maybe the Python SDK can be the best solution when starting new scripts for Zabbix... Regards, René ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] API read-only access / roles
- Original Message - > From: "Sander Grendelman" > To: "Doron Fediuck" > Cc: "users" > Sent: Thursday, November 21, 2013 10:52:26 AM > Subject: Re: [Users] API read-only access / roles > > Hi Doron, > > The user I've defined in [1] works for me. > A built-in login-/read-only role would be nice, > but it's quite easy to define a custom role so > more of a nice-to-have instead of a must-have. > > Thanks for asking! > > Sander. > > On Wed, Nov 20, 2013 at 5:40 PM, Doron Fediuck wrote: > > Hi Sander, > > We're closing the ovirt 3.4 scope, and wondering if you're handling > > Zabbix based on [1]. > > If so please let me know and I'll update the 3.4 features list. > > > > Thanks, > > Doron > > > > [1] http://lists.ovirt.org/pipermail/users/2013-November/017946.html > Thanks Sander, other than that anything else needed for Zabbix monitoring? Rene mentioned this in his request: Zabbix monitoring Monitoring the oVirt environment should work with my check_rhev3 plugin by adding it as an external check to Zabbix. I'll test this and if it's working I'll provide a short guide on how to do it. Displaying data/triggers in oVirt isn't possible yet with my Monitoring UI-plugin, but on the feature list (help is welcome)... So I'm wondering what should be done in order to satisfy the request? ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] API read-only access / roles
Hi Doron, The user I've defined in [1] works for me. A built-in login-/read-only role would be nice, but it's quite easy to define a custom role so more of a nice-to-have instead of a must-have. Thanks for asking! Sander. On Wed, Nov 20, 2013 at 5:40 PM, Doron Fediuck wrote: > Hi Sander, > We're closing the ovirt 3.4 scope, and wondering if you're handling > Zabbix based on [1]. > If so please let me know and I'll update the 3.4 features list. > > Thanks, > Doron > > [1] http://lists.ovirt.org/pipermail/users/2013-November/017946.html ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] API read-only access / roles
Hi Sander, We're closing the ovirt 3.4 scope, and wondering if you're handling Zabbix based on [1]. If so please let me know and I'll update the 3.4 features list. Thanks, Doron [1] http://lists.ovirt.org/pipermail/users/2013-November/017946.html ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] API read-only access / roles
On Mon, Nov 18, 2013 at 5:18 PM, René Koch (ovido) wrote: > Very nice - do you use my check_rhev3 Nagios plugin > (https://github.com/ovido/check_rhev3) or are you working on > your own script? At the moment: both. The problem with using Nagios scripts in Zabbix is that the trigger/alarm decision is made in different places. In Nagios this is done in the check scripts / on the "client" side while Zabbix mainly collects data and fires triggers if certain conditions in that data are met. New(er) Zabbix versions also have a feature called "low level discovery" that automatically creates items. It also seems that there is better RESTful/ovirt API support in python so I'm giving that a try too. Although perl is usually my poison of choice too ;) >> For this I've created a "AdminLoginOnly" role that only has >> System->Configure System->Login Permissions access. >> >> Is this the way to go for this king of configuration? Or is there >> a way to further minimize the permissions of this user? > > I create a custom role with these permissions for Nagios monitoring, > too. > I was thinking that in oVirt 3.3 there should be a predefined > viewers-role, but can't find it in my setup :( OK, that would have been nice, do you have any history on this one? >> Another issue is that a "Login" event is generated every time >> the user connects through the API. This makes the "Events" >> pane less useful / readable. Is there a way to disable this for >> some users/roles? > > > It depends if you have your own script or check_rhev3: > - check_rhev3 1.2: use option -o > - check_rhev3 1.3: you should not see any login information in this > version anymore > - custom script: see this page on information how to use the JSESSIONID > cookie: http://www.ovirt.org/Features/RESTSessionManagement Thanks for the info I'll look into this. It does make the logic in the script a bit harder because you have to store the sessionid somewhere and check if the session is still valid. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] API read-only access / roles
On Mon, 2013-11-18 at 16:46 +0100, Sander Grendelman wrote: > I'm working on (Zabbix) monitoring through the RESTful API. Very nice - do you use my check_rhev3 Nagios plugin (https://github.com/ovido/check_rhev3) or are you working on your own script? > > Which role should I assign to the monitoring user? > > The user only needs read access to the data but it looks like > I nead to assign at least an "Admin" role to the user to be > able to read data through the API. > > For this I've created a "AdminLoginOnly" role that only has > System->Configure System->Login Permissions access. > > Is this the way to go for this king of configuration? Or is there > a way to further minimize the permissions of this user? I create a custom role with these permissions for Nagios monitoring, too. I was thinking that in oVirt 3.3 there should be a predefined viewers-role, but can't find it in my setup :( > > Another issue is that a "Login" event is generated every time > the user connects through the API. This makes the "Events" > pane less useful / readable. Is there a way to disable this for > some users/roles? It depends if you have your own script or check_rhev3: - check_rhev3 1.2: use option -o - check_rhev3 1.3: you should not see any login information in this version anymore - custom script: see this page on information how to use the JSESSIONID cookie: http://www.ovirt.org/Features/RESTSessionManagement Regards, René > ___ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] API read-only access / roles
I'm working on (Zabbix) monitoring through the RESTful API. Which role should I assign to the monitoring user? The user only needs read access to the data but it looks like I nead to assign at least an "Admin" role to the user to be able to read data through the API. For this I've created a "AdminLoginOnly" role that only has System->Configure System->Login Permissions access. Is this the way to go for this king of configuration? Or is there a way to further minimize the permissions of this user? Another issue is that a "Login" event is generated every time the user connects through the API. This makes the "Events" pane less useful / readable. Is there a way to disable this for some users/roles? ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
