Open Stack

On 21 November 2014 10:35, Antonio Messina <antonio.s.messina at gmail.com>
wrote:

> Hi all,
>
> I'm running a Juno testbed with Neutron, ml2 and ovs. We have use
> cases where we would like to create a shared vlan network and directly
> attach a VM on this network. This is not hard to do, and I've
> described how I did at this page:
> http://www.s3it.uzh.ch/blog/openstack-neutron-vlan/
>
> However, there are a few issues with this implementation:
>
> 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.


>
> 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.
As far as I can remember project_name is not among those, but tenant_id is.

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.
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>)))

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]



>
> 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?


>
> Is there a way to do it? What variables can be used in the policy.json
> file, apart from the standard "project_id" and "user_id"?
>
> Thank you in advance for your precious help
>
> Cheers,
> Antonio
>

[1] https://review.openstack.org/#/c/132661/

>
> --
> antonio.s.messina at gmail.com
> antonio.messina at 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 at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20141121/eae32b55/attachment.html>