[Openstack] [neutron] Fine grained access control on external networks

Antonio Messina antonio.s.messina at gmail.com
Fri Nov 21 11:17:30 UTC 2014


Hi Salvatore, thank you for answering,

On Fri, Nov 21, 2014 at 11:57 AM, Salvatore Orlando <sorlando at nicira.com> wrote:
> On 21 November 2014 10:35, Antonio Messina <antonio.s.messina at 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.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




More information about the Openstack mailing list