<div dir="ltr">Yes, the recommended approach is to update the ACLs to wathever fits your use-case. Note that users may have access to the API, and nothing would prevent them manage the VNET objects, even though you disable the Sunstone button <div><br></div><div>Cheers</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 28, 2014 at 10:20 PM, Hamada, Ondrej <span dir="ltr"><<a href="mailto:ondrej.hamada@acision.com" target="_blank">ondrej.hamada@acision.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I see. Well if the users are controlling the VMs only via sunstone, you can disable the 'add nic' function for the 'user/cloud' view. But I suppose that replacing the default ACLs is the best option.<br>
<span class="im HOEnZb"><br>
-----Original Message-----<br>
From: Pavel Tankov [mailto:<a href="mailto:pavel.tankov@strategyobject.com">pavel.tankov@strategyobject.com</a>]<br>
</span><div class="HOEnZb"><div class="h5">Sent: Tuesday, October 28, 2014 12:59 PM<br>
To: Hamada, Ondrej; <a href="mailto:users@lists.opennebula.org">users@lists.opennebula.org</a><br>
Subject: Re: [one-users] How to protect a virtual network from being used by users?<br>
<br>
That's exactly what I had done. The problem is that users are able to change the network when they instantiate the template. They can add/remove networks at will.<br>
<br>
Pavel Tankov<br>
<br>
On 10/27/2014 11:11 PM, Hamada, Ondrej wrote:<br>
> Hi Pavel,<br>
><br>
> Create two templates - first one uses the public network and all users are allowed to instantiate this template. The second template uses the restricted network and is allowed to be used only by admins.<br>
><br>
> Ondra<br>
><br>
> -----Original Message-----<br>
> From: Pavel Tankov [mailto:<a href="mailto:pavel.tankov@strategyobject.com">pavel.tankov@strategyobject.com</a>]<br>
> Sent: Monday, October 27, 2014 11:16 AM<br>
> To: Hamada, Ondrej; <a href="mailto:users@lists.opennebula.org">users@lists.opennebula.org</a><br>
> Subject: Re: [one-users] How to protect a virtual network from being used by users?<br>
><br>
> I don't understand what is "to solve the network separation on template level". Could you, please, clarify?<br>
><br>
> Pavel Tankov<br>
><br>
> On 10/24/2014 05:18 PM, Hamada, Ondrej wrote:<br>
>> Hi Pavel,<br>
>><br>
>> Well, I suppose it is the default. I was also struggling with it and finally I had to replace the default ACLs with more strict ones.<br>
>><br>
>> You can try to solve the network separation on template level if you don't want to play with ACLs.<br>
>><br>
>> Ondra<br>
>><br>
>> -----Original Message-----<br>
>> From: Pavel Tankov [mailto:<a href="mailto:pavel.tankov@strategyobject.com">pavel.tankov@strategyobject.com</a>]<br>
>> Sent: Friday, October 24, 2014 4:01 PM<br>
>> To: Hamada, Ondrej; <a href="mailto:users@lists.opennebula.org">users@lists.opennebula.org</a><br>
>> Subject: Re: [one-users] How to protect a virtual network from being used by users?<br>
>><br>
>> Hello Ondra,<br>
>><br>
>> You are right, I just saw the ACLs. They are by default created like this:<br>
>><br>
>> $ oneacl list<br>
>> ID USER RES_VHNIUTGDCOZ RID OPE_UMAC ZONE<br>
>> 0 @1 V-NI-T---O- * ---c #0<br>
>> 1 * ----------Z * u--- *<br>
>> 2 @1 -H--------- * -m-- #0<br>
>> 3 @1 --N----D--- * u--- #0<br>
>><br>
>> (or see the attached screen shot)<br>
>><br>
>> The group named "users" is denoted by @1. So, it looks like in the very first ALC (ID 0) the group @1 (users) is granted a "CREATE" permission on all Virtual Networks (Resource ID *). Which may be OK or not, it depends what you want.<br>
>><br>
>> But then ACL (ID 3) grants the group @1 (users) the permission to use any Virtual Network (RID *). The ACLs have permissive nature so once granted I can't restrict it with a later rule. I could only re-write the default ACLs completely, which I am not quite willing to try.<br>
>><br>
>> The documentation says<br>
>> (<a href="http://docs.opennebula.org/4.8/administration/users_and_groups/manage_acl.html" target="_blank">http://docs.opennebula.org/4.8/administration/users_and_groups/manage_acl.html</a>):<br>
>><br>
>> Please note: the ACL rules is an advanced mechanism. For most use cases, you should be able to rely on the built-in resource permissions and the ACL Rules created automatically when a group is created, and when a resource provider is added.<br>
>><br>
>> But it looks like *all* Vritual Networks are meant to be used by<br>
>> *anyone* by default and there is not much I can do about it with the normal means, namely with the resource permissions.<br>
>><br>
>> Is that so, indeed, or where am I wrong?<br>
>><br>
>> Pavel Tankov<br>
>><br>
>> On 10/24/2014 04:33 PM, Hamada, Ondrej wrote:<br>
>>> Hi Pavel,<br>
>>><br>
>>> Have you checked ACLs as well? I guess that one of the default ACL grants all users the 'use' permission for all 'networks'.<br>
>>><br>
>>> Ondra<br>
>>><br>
>>> -----Original Message-----<br>
>>> From: Users [mailto:<a href="mailto:users-bounces@lists.opennebula.org">users-bounces@lists.opennebula.org</a>] On Behalf Of<br>
>>> Pavel Tankov<br>
>>> Sent: Friday, October 24, 2014 12:09 PM<br>
>>> To: <a href="mailto:users@lists.opennebula.org">users@lists.opennebula.org</a><br>
>>> Subject: [one-users] How to protect a virtual network from being used by users?<br>
>>><br>
>>> Hello,<br>
>>><br>
>>> I (as oneadmin) have configured two virtual networks:<br>
>>> - one named "default" for use by regular users to deploy disposable<br>
>>> test VMs<br>
>>> - one named "SPECIAL" for use by the admin to create servers that<br>
>>> will not be disposable but will stay always ON<br>
>>><br>
>>> Both networks have different IP ranges so that you could easily tell whether it's a server or a disposable test VM by looking at it's IP address.<br>
>>><br>
>>> I have set up Opennebula with LDAP authentication. LDAP users authenticate just fine and are able to create themselves VMs using those templates that the admin has allowed for them. Now, I'd like to make so that only "default" virtual network is exposed to regular users, and "SPECIAL" is not seen by them.<br>
>>><br>
>>> Currently, both networks have the following permissions:<br>
>>><br>
>>> - Owner: use, manage<br>
>>> - Group <none><br>
>>> - Other: <none><br>
>>><br>
>>> Users still can use both of these when they deploy a test VM although permissions clearly state they shouldn't be able to see any of them.<br>
>>><br>
>>> What is wrong with the permissions?<br>
>>><br>
>>> --<br>
>>> Pavel Tankov<br>
>>> _______________________________________________<br>
>>> Users mailing list<br>
>>> <a href="mailto:Users@lists.opennebula.org">Users@lists.opennebula.org</a><br>
>>> <a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a><br>
>>> ________________________________<br>
>>> This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.<br>
>>> _______________________________________________<br>
>>> Users mailing list<br>
>>> <a href="mailto:Users@lists.opennebula.org">Users@lists.opennebula.org</a><br>
>>> <a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a><br>
>>><br>
>> ________________________________<br>
>> This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.<br>
>><br>
> ________________________________<br>
> This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.<br>
><br>
________________________________<br>
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opennebula.org">Users@lists.opennebula.org</a><br>
<a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div><span style="color:rgb(102,102,102)">Ruben S. Montero, PhD</span><br></div></div><font color="#666666">Project co-Lead and Chief Architect</font><div><font color="#666666">OpenNebula - Flexible Enterprise Cloud Made Simple<br><a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:rsmontero@opennebula.org" target="_blank">rsmontero@opennebula.org</a> | @OpenNebula</font></div></div></div>
</div>