Open Stack

Hi,

(2014/04/17 21:29), CARVER, PAUL wrote:
> Akihiro Motoki wrote:
>
>> To cope with such cases, allowed-address-pairs extension was implemented.
>> http://docs.openstack.org/api/openstack-network/2.0/content/allowed_address_pair_ext_ops.html
>
> Question on this in particular: Is a tenant permitted to do this? If so, what exactly is the iptables rule accomplishing? If the intent was to prevent the tenant from spoofing someone else's IP then forcing the tenant to take an extra step of making an API call prior to attempting to spoof doesn't really stop them.

In my understanding, the answer is Yes and it is a topic specific to one 
tenant.

When we talk about a security model about security groups, we need to 
assume three roles:
- tenant user, who deploys applications on a tenant provided by "tenant 
admin"
- tenant admin, who uses OpenStack API to manage a tenant topology 
(instances, networks, volumes...)
- infra administator, who provides OpenStack services and coordindate 
multiple tennats

According to my understanding, security group rules and spoofing rules 
are defined
by tenant admin to prevent "tenant user" from communicating unintended 
peers or
spoofing other IP addresses. Thus, I think allowed_address_pairs feature 
does not break
the existing security model.

Isolation among tenants should be guaranteed at infra level and it is 
the role of infra administrator.
Generally speaking, in neutron concept, a tenant can use any IP and MAC 
addresses as it wants.

Note that 'flat' networking has a limitation and the isolation among tenants
depends on these spoofing rules and IP uniqueness, so it should not be used
for such situations.

>
> Question in general: Is there an easy way to see the whole API broken out by privilege level? I'd like to have a clear idea of all the functionality that requires a cloud operator/admin to perform vs the functionality that a tenant can perform. Obviously Horizon looks different for an admin than it does for a tenant, but I'm not as clear on how to identify differences in the API.

AFAIK there is no API summary broken out by priviledge level.
In Neutron API, there is no explicit difference between tenant and admin 
API.
It is controlled by policy.json and looking at this file is the easiest 
way to check it.
The default policy is determined based on general use cases discussed 
during development
(mainly from the point view of tenant isolation including security model).
Cloud administrators (with keystone admin role) can see all resources 
and extra attributes by default.
It is common in most OpenStack projects.

In Horizon, admin and project dashboards have different views.
Horizon developers map/classify features into admin or project dashboards,
there are many gray zones and RBAC mechanism based on the above policy
mechanism has been introduced in Icehouse Horizon.


I don't think I answered all of your questions but I hope it answer most.

Thanks,
Akihiro

>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev