[Engine-devel] Managing permissions on network

Charlie medievalist at gmail.com
Wed Nov 14 17:01:58 UTC 2012


> On 11/13/2012 09:57 PM, Charlie wrote:
>>
>> Will any of these groups and/or permissions be drawn from LDAP?
>>
>> Frankly, system admins are not looking for yet another console to
>> manage permissions.

On Tue, Nov 13, 2012 at 11:28 PM, Itamar Heim <iheim at redhat.com> wrote:

> all users/groups come from LDAP.
> you just need to give permissions to these groups/users in ovirt.
> is that what you meant?

Yes, mostly.  :)

As long as you can give permissions to a set of LDAP groups (call them
oVirtSysAdmin, oVirtUser, oVirtNetAdmin, or whatever) and after that
never touch permissions again, that's perfect.

That way an HR employee or junior sysadmin can assign users to these
groups during user account creation, and you won't have to give
somebody in HR the ability to define permissions in oVirt, or tie up a
highly skilled admin with routine user account maintenance.

--Charlie


>
>>
>> --Charlie
>>
>>
>> On Tue, Nov 13, 2012 at 1:19 PM, Itamar Heim <iheim at redhat.com> wrote:
>>>
>>> On 11/13/2012 07:18 PM, Livnat Peer wrote:
>>>>
>>>>
>>>> On 13/11/12 15:39, Itamar Heim wrote:
>>>>>
>>>>>
>>>>> On 11/13/2012 03:37 PM, Livnat Peer wrote:
>>>>>>
>>>>>>
>>>>>> On 13/11/12 15:19, Itamar Heim wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 11/13/2012 12:45 PM, Livnat Peer wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Interesting point, I think that if a user has permission to create a
>>>>>>>> VM
>>>>>>>> from a specific template we should give him permission to use the
>>>>>>>> template networks on this VM implicitly upon the VM creation.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> having a permission to a template does not mean a permission to the
>>>>>>> default network of that VM, especially as we'll use templates more as
>>>>>>> instance types.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Another alternative is to require permission on the network as well as
>>>>>> the template.
>>>>>> I must say I don't really like it, although I agree with your comment,
>>>>>> we require too many operations for enabling a user to create a VM from
>>>>>> template (permission on the template, quota on the storage,
>>>>>> permissions
>>>>>> on the network, next we'll require a PHD ;)).
>>>>>>
>>>>>> Anyone has a better idea?
>>>>>
>>>>>
>>>>>
>>>>> I assume most networks would be given either to 'everyone' or groups of
>>>>> users, not per user (and if the network is per user/tenant, then it
>>>>> must
>>>>> be done per user.
>>>>
>>>>
>>>>
>>>> Which reminds that I wanted to propose adding a property on a network
>>>> which is called public.
>>>> It's just a UI feature to give a NetworkUser on this network to
>>>> 'everyone'. It makes making a network public easier for the user.
>>>>
>>>> In addition during upgrade we should make all existing networks public
>>>> networks and not allocate specific permissions for users on networks.
>>>>
>>>> In addition it also means a user is given permission on a network and
>>>> then he can use it for any VM he owns. Isn't that problematic? We can't
>>>> limit a user to use a network on a specific VM.
>>>
>>>
>>>
>>> I think that's fine.
>>> don't let user edit that vm if you don't trust them.
>>>
>>>
>>>>
>>>>> i may not remember correctly, but i thought when giving quota to user
>>>>> we
>>>>> also give some permissions with it (on cluster and storage)?
>>>>
>>>>
>>>>
>>>> I am not sure what is the current implementation as it changed a lot,
>>>> but last I tracked we checked for either quota or permissions we did not
>>>> give implicit permissions when creating a quota.
>>>>
>>>
>>> gilad/doron?
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>
>



More information about the Devel mailing list