Hi Salvatore, thank you for answering, On Fri, Nov 21, 2014 at 11:57 AM, Salvatore Orlando <sorla...@nicira.com> wrote: > On 21 November 2014 10:35, Antonio Messina <antonio.s.mess...@gmail.com> > wrote: >> 1) *any* tenant can attach VM directly to this network. I would like >> to be able to only allow specific tenants to do it. Can I update >> the policy.json rule "network:attach_external_network" with >> something like: >> >> "network:attach_external_network": "project_name:'Project1' or >> project_name:'Project2'" >> >> will it work? > > > Nope... sorry.
Care to explain? I don't expect the exact rule to work, but any rule with more or less the same meaning (e.g., replacing project_name with tenant_id would be fine) >> 2) *any* external/shared network will share the same permissions, >> while I would like to have a few "special" vlan networks as >> described before, and a "standard" external network to be used for >> floating IPs. >> >> Ideally, I would like to update the previous policy rule with something >> like: >> >> "admin_api or (network_name: 'vlan842' and >> project_name:'project1')" >> >> but I don't know which "variables" can be used inside the >> policy.json file. > > > You can use either fields like "name" for a network or attributes > from the request context. Ah, good, so I can identify the network at least. I played with pdb but I couldn't find any network-related attribute in the `context` variable, when the function nova.network.neutronv2.api.API._check_external_network_attach function is called. One step further: how can I know, in general, which variables are available for a specific rule? > As far as I can remember project_name is not among those, but > tenant_id is. It's fine either way. > Your rule can therefore become fields:networks:name='vlan842' and > tenant_id:<project1_uuid> Still you can't apply that to > "attach_external_network" as the policy engine does not understand > it. Sorry, my knowledge of the policy engine is too limited to understand your sentence: why it is not understood in "attach_external_network"? Where can it be understood, and what's the difference? It's because "fields:networks:name" will only work for neutron rules, while "attach_external_network" is a rule related to nova? > There is a workaround, and it would be to define a rule on port creation. > I am not sure if this can work for you, but perhaps it's worth trying > > create_port: admin or (field:networks:router:external=False or ( > (fields:networks:name='vlan842' and tenant_id:<project1_uuid>))) Sounds good too, I will give it a try. > Caveat: I have not tested this rule. The meaning of it should be > that a tenant can create a port (or attach a vm) on a network if: > * is an admin, or > * the network is not external or > * the network is called vlan842 regardless of whether it is external or not > but only if the tenant is 'tenant_1' > > One issue with this rule is that if vlan842 is not external anyone > can plug into it. But maybe this can solved by making the rule a bit > more convoluted. > > This process however requires a lot of manual steps and probably requires > the admin to have too many insights in neutron internals. > Looking to the future, there is a work in progress to simplify this [1] That's good to hear! >> 3) I don't know if this is a bug or was caused by my changes, but >> after the change I've made in `network:attach_external_network` an >> unprivileged user on a demo tenant can also see a tenant network >> (not external) created by admin *without* `--shared` on the `admin` >> tenant. The user cannot, however, see the details of the network, >> nor attach any interface to it (either router or VM interface). > > > network:attach_external_network should be just ignored by the policy engine. > If this triggers an error which then causes rule processing to be stopped > then it might be a bug. > Did you also remove any rule? I don't think so, I just emptied the rule "network:attach_external_network". I'm planning to reinstall from scratch in the next week or two, I will try again with a vanilla policy.json Thank you very much for your help! Ciao, Antonio -- antonio.s.mess...@gmail.com antonio.mess...@uzh.ch +41 (0)44 635 42 22 S3IT: Service and Support for Science IT http://www.s3it.uzh.ch/ University of Zurich Winterthurerstrasse 190 CH-8057 Zurich Switzerland _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack