Open Stack

On 11/29/2012 06:08 AM, David Chadwick wrote:
> It seems to me that rather than asking for piecemeal extensions to the
> current RBAC model, such as the addition of groups, domains, scoping 
> etc. we first need a model of the access control system that we want 
> to implement (eventually). Without a comprehensive access control 
> model we will simply end up patching bits of spaghetti to the existing 
> system until we will end with an unspecified model and/or a system 
> that no-one really understands, which will lead to access control 
> "holes" through which attackers can easily penetrate (and which might 
> be difficult to fix). So I would call first and foremost for a 
> comprehensive access control model to be documented in a blueprint 
> before any further "enhancements" are made to the code base - 
> regardless of the perceived urgency of each enhancement. It is 
> critically important for a security system, that people (especially 
> administrators) can understand it, so that they can manage it 
> effectively. The more bolt ons and add ons that are made without a 
> clear description of what the overall model is, the more difficult it 
> will be for administrators to correctly administer.
I'm with you here, and I think we are heading toward that.

I like the division of Access Control into Policy and Mechanism, and I 
think that ABAC is the right mechanism.  I liken it to SELinux: it is 
the lowest level tool that enforces everything we need to be done.  I 
think SE Linux is a good comparison other here.  Yes, it is all 
powerful.  Yes, you can do many custom things with it.  Yes, it "breaks 
things" by too strict enforcement.  But you need to think really, 
really, really hard before you implement a custom policy.

So,  despite the need to push toward an ABAC based enforcement system, 
we still need to have the policy discussions.  This involves the 
standard set of attributes that we enforce in default deployment, and 
that we make easy for users to build on top of.  The grouping attributes 
that we have discussed thus far:  tenants, roles, groups, domains, 
services and endpoints are all still relevant, as they map to business 
entities or business processes.

That said, I couldn't agree with David more on the need for "a 
comprehensive access control model to be documented in a blueprint"

I've primed the pump here.
https://etherpad.openstack.org/access-control


>
> regards
>
> David
>
> On 29/11/2012 08:21, Henry Nash wrote:
>> Hi
>>
>> One of the requests from the summit was for allowing the scoping of a
>> token to multiple projects, and this is being worked on for Grizzly.
>> However, I would like us to re-visit (or maybe just re-clarify) this
>> requirement - whilst also considering the option of scoping to a
>> domain (see blueprint at :
>> https://blueprints.launchpad.net/keystone/+spec/domain-scoping).
>>
>> Now the whole point of scoping to anything, is to make it possible
>> (and in some cases easier) to execute operations on the granularity
>> that you have "scoped to". It seems to me that now we have a domain
>> as the logical container for users and projects, clearly one of the
>> common usages will be operations that want to look at all the
>> projects (or some aspect of projects) in a domain - hence the idea of
>> scoping to a domain.  This would provide a somewhat simpler, both
>> request & response, than an appropriately scoped token than an
>> arbitrary list of projects (where you end up returning a nested set
>> of projects and their domains in the response, for example).
>> Further, if we had this, would we really need the ability to scope to
>> multiple projects from different domains (which is technically the
>> request on the table right now)?  Remember, scoping is defining the
>> access rights - just allowing a suitable granularity of scope for
>> upcoming operations - so you only really need a complex scope if the
>> you have some operation that needs to carried out across that complex
>> set of objects.  Are there such a set of operations that people have
>> in mind?
>>
>> I raise this so that we just look at whether there is some
>> simplification to the expansion of ability to scoping, before we go
>> too far.
>>
>> Henry
>>
>>
>> _______________________________________________ OpenStack-dev mailing
>> list OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev