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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
