Open Stack

On 26/11/2012 18:23, heckj wrote:
>
> On Nov 25, 2012, at 12:46 PM, David Chadwick
> <d.w.chadwick at kent.ac.uk> wrote:
>> Firstly I agree with Henry that segmenting an openstack
>> installation into multiple independent domains is an important
>> functionality to provide. But coupled with this, we should also
>> have the ability to provide interdomain access as well. Otherwise
>> you end up with un-interoperable silos. For example, two
>> organisations may have separate domains on the same openstack
>> system, and later decide they want to cooperate and have some of
>> their users share information. This should be achievable with
>> configuration or policy changes without having to rebuild the
>> entire openstack system. So I would extend Henry's no 1 goal to be
>> "interoperable domains"  rather than standalone domains.
>>
>> It seems to me that Henry's second goal can be relatively easily
>> achieved by having a proper RBAC/ABAC interface between the service
>> (PEP) and the policy engine (PDP). This will allow different PDPs
>> to be plugged in that support much more fine grained and
>> sophisticated policies e.g. conditions based on time of
>> day/week/month, different authentication levels etc without the
>> user's role(s) necessarily needing to change. And this naturally
>> leads onto the comments made by Joe.
>>
>> Joe, if we have a set of goals of varying levels of importance and
>> priority, rather than picking the top priority goal and making a
>> tailored solution to it, that solves this goal and only this goal,
>> isnt it better to produce a more generic abstracted solution that
>> can also solve many of the other goals as well?
>
> I would only give a highly qualified yes as an answer to that
> question. A generic, abstracted solution often incurs so much
> complexity overhead to understand the solution that a simpler, less
> complete solution is more amenable because it's easy to understand
> (faults and all) and gets 80% of the job done. I'm all for having a
> vision of where we can go and driving it there, but it must be with
> pragmatic, usable stepping stones and clear goals of "why".
>
> I'm passionate about AuthN/Z - and primarily that it's functional,
> interoperable, and clear to understand as the highest priorities.
>
>> The former leads to more spaghetti code with different special
>> parameters and APIs for different goals ie. a complex system that
>> is very difficult to understand, whereas the latter leads to a
>> conceptually much simpler system with cleaner code and more
>> flexibility.
>>
>> Here is a case in point. The current RBAC interface requires in
>> your words "all the data that comes in from the roles (name, user,
>> tenant, etc).....to provide authorization". This requires many
>> different special parameters to be passed to the policy engine via
>> the API, and if you want to add groups in the future, then this
>> causes yet another parameter to be added to the interface. However,
>> if you go up a level of abstraction and say that you pass a set of
>> subject attributes to the policy engine, and the API is written in
>> this way, then you have an infinitely extensible interface that
>> does not need to change when groups are added. Group is just
>> another subject attribute that can be passed along with role, user,
>> tenant, name etc. The API design is future proof to whichever new
>> subject attributes come along next year or next decade.
>>
>> Joe, the above should also help to answer your question about
>> type/value pairs. In the subject attributes example above, the type
>> value pairs passed via the API might be name=David user=1234
>> tenant=xyz role=prof Once you have this type of ABAC interface, it
>> becomes trivial to add new features, by simply adding a new
>> attribute type and value to those passed to the PDP, for example,
>> to base authz also on the strength of authentication, you might
>> add LOA=2 (level of assurance as per the NIST recommendation) to
>> the set of subject attributes. A flexible policy based PDP can
>> easily take this new attribute into account when policies are
>> written and decisions are made, without needing to change the
>> policy code base. You simply change the policy. You will of course
>> need to change the service PEP, since it will need to pick up this
>> new attribute from the Keystone authentication service, and pass it
>> to the policy engine.
>
> I like and appreciate the simplicity of the attribute based
> approach.
>
> With making the attributes as arbitrary setups, what changes do you
> see to the REST interface that presents these as interpreted
> abstractions such as groups, domains, users, and projects today? Any?

This is a quick (uninformed) initial response. I need to talk to Kristy 
on Wednesday to correct any mistakes I am making now. But I am assuming 
that the current API uses a JSON structure which has a fixed number of 
set fields such as user, tenant, role etc. The ABAC API in comparison 
would have a JSON stucture which was defined as a zero to many set of 
attributes, where each attribute is defined as a type and value. So the 
client software could then populate this structure with whatever 
type/value pairs it wanted to. In a separate Keystone specification we 
would define a set of standard attributes and their meanings (e.g. role, 
group, tenant, name etc) that must, should or may be supported by 
clients. As the backend Keystone implementation grows in sophistication, 
then more attributes would be added to this standard set. So the API 
would not change, but the supporting code and documentation would grow 
with time.


> Or are you focused on the internal representation as attributes and
> passing these with an updated interface (i.e. the token interface) to
> the policy engines?

I would like to update the interface to the policy engines to be of the 
generic ABAC type, so that it is infinitely extensible. Each implementor 
of a policy engine would document the set of attributes that his 
implementation requires in order to make authz decisions. (In fact our 
PDP does not need/require any attributes and can accept all and every 
type of attribute since these are configured into the implementation at 
runtime via an XML policy)

  How would you propose to extend/modify the token
> based interface to support additional interesting attributes for ABAC
> that can then be parsed and used by the policy engines? We must keep
> backwards compatibility here.

Backwards compatibility might be difficult. It might be that for a while 
you have to run two APIs in parallel, and eventually deprecate the 
existing RBAC API and finally phase it out once everyone has migrated to 
the new API.

>

> The attribute based mechanism could pretty clearly provide nice
> support for multi-factor or any "multiple attributes asserted"
> authentication mechanism. How does it also play into supporting
> interoperable domains?

My idea for this is as follows. Since authz is based on a set of 
attributes, then a domain that wants to limit access to its own users 
only would require the following attributes to be passed to the policy 
engine in order for a grant to be returned
role=A
tenant=B
domain=C

A domain that wanted to let users from other domains and tenants access 
some of its resources would return grant to requests containing just
role=X

A domain that wanted to allow inter-tenant access (say tenants A and B 
to access each others resources) might require
role=A
Tenant=A or B
domain=C

So the answer is, it all depends upon the policy that the domain sets 
for access to its resources. The domain/resource administrator sets up 
the policy and specifies which attributes are needed to get access to 
which resources. Some resources in the domain could be limited to 
role/tenant/domain, and others to just role, as he wishes.


  I could see adding a "groupname" attribute and
> providing a REST interface around that for manipulating the groups,
> but how does that cascade down into doing the equivalent of asserting
> that I want all folks in group "computeadmin" to have the role
> "computeadmin" and having that interpreted by the policy engine as
> such?

This would not be dealt with by the policy engine, but by the role 
mapping service of Keystone. We have published a blueprint for this 
already. Have you seen it? The policy engine would simply say that 
role=computeadmin is needed. That's all. How a user gets the 
computeadmin role is determined by the role mapping service.

>
> Are the policy engine and ABAC mechanism/interface changes a
> pre-requisite for this to happen in a reasonable form?

They are independent. YOu can use the existing RBAC interface with the 
proposed role mapping service to get the groups feature.

 From what Henry said, its the management of the "policies" that is 
crucial. The openstack admin administers the access control policies 
(ie. sets it to role=computeadmin) whereas the organisation admin 
administers the role mapping policy (says that his group=computeadmin is 
to be mapped to role=computeadmin)


>
> Part of what I'm trying to understand is how much work we're talking
> about, and where it needs to occur to enable this good stuff.

I would say, start with the role mapping service, since this is a new 
add on which does not effect backwards compatibility, but enables lots 
of good stuff once it is available. Then define the ABAC API to the 
policy engine, and have this run in parallel to the existing RBAC one 
(sorry but I dont know Python or the APIs sufficiently to know if a 
super API that is backwards compatible can be created or not. If it can 
then this would be fantastic).



  We have
> a V3 API we're getting out there now with milestone-1, and a clear
> need to provide a few significant improvements in this release cycle
> - including a solid V3 API. Is what we're talking about here focused
> on slight modifications to the V3 API and implementation to make it
> solid, or deeper/longer changes that we expect to land out in H or I
> release cycles?

This is where your experience and Kristy's are far superior than mine. I 
am an architect rather than an implementer. So I dont know the answer in 
short.

regards

David

>
> If that's the case, we need to be able to clearly separate actions
> we're taking to make the grizzly release effective and usable (which
> is where I saw Henry's original requests) and longer term goals for
> more interoperability and cleaner interfaces.
>
> -joe
>
>> On 23/11/2012 13:06, Henry Nash wrote:
>>> Hi
>>>
>>> So I'll let others, e.g. David, perhaps provide a more detailed
>>> description of ABAC etc., but setting out the high level goals is
>>> an excellent approach.
>>>
>>> For me the highest level goal is to improve the acceptability of
>>> openstack in the enterprise market so as to grow the % of
>>> installations based on it, both for public and private clouds.
>>> In such installations "multi-tenancy" is crucial - unfortunately
>>> that word is much over used.  What I mean by it in this context
>>> is that a cloud provider can logically segment their openstack
>>> installation in order to give their customers (e.g. different
>>> enterprises hosted on a single public cloud, or, say, company
>>> divisions in a private cloud) what appears to be their own cloud,
>>> even though it is hosted on a shared openstack installation.  The
>>> cloud provider should be able to delegate the administration of
>>> appropriate aspects of the customers, so that they can
>>> self-administer.  For Keystone, as the security fabric, the focus
>>> should be around using Domains as the underpinning of this and
>>> extending them to provide the flexibility needed for the above.
>>> Further, we need to connect that concept to the other parts of
>>> openstack - e.g. images, objects, availability zones, quotas
>>> etc. so that a cloud provider can really provide the logical view
>>> required by customers while getting the most use of the h/w used
>>> to back the whole cloud and keeping their admin costs low.  This,
>>> for me, is priorty #1
>>>
>>> As the above succeeds, then enterprises will start running up
>>> against some of the flexibility limitations we have in access
>>> control.  The larger the enterprise, generally, the more problem
>>> they'll find - and this is priority #2.  One that we are already
>>> hitting is the issue of needing an organisation role or group
>>> (which I consider the most glaring hole right now).  But let's
>>> look beyond that at a rather trivial flexibility issue.  A large
>>> enterprise (that will almost certainly be regularly audited)
>>> wants to minimise its exposure by limiting the access that
>>> certain users have during key production cycles (e.g time of
>>> day/week/month or whatever) - perhaps to remove modification
>>> rights to certain assets.  In today's keystone model there is no
>>> way of doing this without either a) A given user have different
>>> accounts they log in as at different times, or b) the
>>> administrator changing the role assignments each time.  Maybe
>>> they also want to insist on extra authentication items for
>>> ultra-sensitive operations and pretty soon you end up creating
>>> many different roles that you try and assign the user for
>>> particular situations - leading to what is called "role
>>> explosion".  This becomes increasingly hard to manage.  ABAC
>>> tries to provide a more flexible, granular and dynamic equivalent
>>> of today's static role assignment.  There are some that argue
>>> that all ABAC is really saying is "run this dynamic check using a
>>> pre-defined bunch of attributes" every time you need to validate
>>> access and if you replace today's static role assignment with
>>> that, you end up in the same place.  I'll let others comment on
>>> that.
>>>
>>> Given the above priorities,  I believe we should: - Really flesh
>>> out the implications of domains across openstack - If there is
>>> low hanging fruit within our current RBAC that will have dramatic
>>> effect on enterprise acceptability, let's grab it -
>>> Investigate/experiment how a more flexible attribute model could
>>> be introduced, potentially as some extension to RBAC
>>>
>>> Henry
>>>
>>>
>>> On 22 Nov 2012, at 20:24, Joseph Heck wrote:
>>>
>>>> Since we're listing out limitations (and this looks to be a
>>>> pretty good list), can we also define the goals that you are
>>>> after and why?
>>>>
>>>> I get the obvious management goals of supporting groups, but
>>>> I'm far less clear on what we're gaining by putting in the
>>>> effort to evolve to an ABAC system, as architecturally clear as
>>>> that sounds. I'm not deep on the literature or details of RBAC,
>>>> ABAC, and assorted systems - so some simplified clarity in
>>>> goals and what this will let us achieve would help me
>>>> contribute to this conversation significantly.
>>>>
>>>> So more specific points - does it matter if we have a "pure"
>>>> RBAC system or not?
>>>>
>>>> Roles today are an arbitrary (and currently globally unique)
>>>> identifier of a user to a project or domain (or perhaps group)
>>>> - can you give me an idea of what type/value pairs are and how
>>>> they're used for authorization? Today we have all the data
>>>> that comes in from the roles (name, user, tenant, etc) that can
>>>> be used along with the policy files (simple rule sets that
>>>> compare requested action to parameters provided by the
>>>> authorization token) to provide authorization - all of which
>>>> occurs currently at the service level. Does some of this
>>>> translater to type/value pairs? I'm not familiar with what is
>>>> meant by these or what an example might be.
>>>>
>>>> - joe
>>>>
>>>>
>>>> On Nov 22, 2012, at 11:26 AM, David Chadwick
>>>> <d.w.chadwick at kent.ac.uk> wrote:
>>>>> Hi Henry
>>>>>
>>>>> so why dont we start by discussing/listing/recording the
>>>>> limitations in the current RBAC system as a first step.
>>>>>
>>>>> Here is my initial list which I am sure you can supplement.
>>>>> BTW, is there a wiki page where we could create a standing
>>>>> document listing these limitations, so that they can be
>>>>> ticked off once solutions have been implemented (or added to
>>>>> when new ones are discovered?)
>>>>>
>>>>> 1. Roles have to be global and cannot be locally created by
>>>>> a cloud service 2. Roles only comprise a value, whereas in
>>>>> general you need type/value pairs for authorisation
>>>>> (sometimes this is called parameterised roles in the
>>>>> literature). 3. The current system limits the user to having
>>>>> to be a particular tenant, so this cannot be called a "pure"
>>>>> RBAC system, since more than roles control access. 4. There
>>>>> is no role-mapping capability which is needed for
>>>>> scalability, flexibility and federation. This  is referred to
>>>>> in the literature as separating organisation roles from
>>>>> workflow roles 5. The current system does not support
>>>>> delegation of authority whereby a role holder can delegate a
>>>>> role to another user.
>>>>>
>>>>> That's an initial first draft
>>>>>
>>>>> regards
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>> On 22/11/2012 18:07, Henry Nash wrote:
>>>>>> Hi David,
>>>>>>
>>>>>> So on the idea of using suffix/prefixes for user and
>>>>>> domain names to remove the need to add a parameter to the
>>>>>> API - I did think about that for a while.  Since it is only
>>>>>> the one API (the authentication by username/password) that
>>>>>> requires the parameter and that there is no equivalent of
>>>>>> "local site login" as in your example, I am not sure the
>>>>>> concatenation of the strings buys us much.  I also thought
>>>>>> about a system when the domain name is automatically
>>>>>> added/stripped from user/project names - but in the end
>>>>>> this seems fraught with the usual problems that such
>>>>>> schemes have.  I think it is also important that we are
>>>>>> clear about can and cannot be used as a unique tag by the
>>>>>> users of keystone.
>>>>>>
>>>>>> On your more general comment on a wider discussion on RBAC
>>>>>> & ABAC should be used, I think that is a good idea.  I
>>>>>> think we need to discuss a few things, e.g.:
>>>>>>
>>>>>> 1) We have RBAC now, similar to many such systems.  How
>>>>>> much more extensible do we need to make it? 2) Is ABAC our
>>>>>> eventual destination?  I actually think it should be.  But
>>>>>> what does that mean?  a) As a replacement for RBAC (i.e.
>>>>>> since you should be able to implement any RBAC scheme
>>>>>> within a broader ABAC implementation).  Or b) is it to
>>>>>> stand alongside RBAC (i.e. a cloud provider could chose
>>>>>> which they use)?  If we were designing from a clean sheet
>>>>>> of paper, then a) might be the obvious answer - but of
>>>>>> course we're not.  It might still be the right path, but
>>>>>> we'd have to handle the migration very carefully and as
>>>>>> well as really understand what happens to the existing
>>>>>> APIs.
>>>>>>
>>>>>> I think 2) will take some serious discussion - but I'm all
>>>>>> for it.  However, we can't ignore 1).  There are
>>>>>> restrictions today in our RBAC that will prevent
>>>>>> enterprises using Openstack OTB (Out of The Box), some
>>>>>> listed in these blueprints as well as others like the one
>>>>>> on "groups of users".  I think we need to keep pushing such
>>>>>> improvements forward (we all want market share for
>>>>>> Openstack), while keeping an eye to make sure we can
>>>>>> sensibly represent them in ABAC form in the future.  A
>>>>>> good example is indeed that  groups of users blueprint
>>>>>> (https://blueprints.launchpad.net/keystone/+spec/user-groups).
>>>>>>
>>>>>>
This is really about allowing the creation of local (i.e. to
>>>>>> the domain) organizational role/attributes (I happen to
>>>>>> call it a group) that can be mapped to global roles (since
>>>>>> that's all we support today as roles are shared secrets
>>>>>> between services and keystone).
>>>>>>
>>>>>> Henry
>>>>>>
>>>>>> On 22 Nov 2012, at 13:00, David Chadwick wrote:
>>>>>>
>>>>>>> Hi Henry
>>>>>>>
>>>>>>> On 21/11/2012 19:59, Henry Nash wrote:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> I have been working, with others, on a set of
>>>>>>>> blueprints (some already discussed on this list) that
>>>>>>>> enhance the definition and use of domains to make
>>>>>>>> Openstack more successful and acceptable to enterprise
>>>>>>>> customers (both when being hosted by a openstack-based
>>>>>>>> cloud provider as well as for private clouds).  I would
>>>>>>>> welcome comments/suggestions:
>>>>>>>>
>>>>>>>> *Optional private name spaces for domains*.  The
>>>>>>>> initial draft of this proposal has been discussed here
>>>>>>>> before, but I have now added details of the proposed
>>>>>>>> changes :
>>>>>>>> https://blueprints.launchpad.net/keystone/+spec/domain-name-spaces
>>>>>>>
>>>>>>>
>>>>>>>>
>>
>>>>>>>>
I fully support your spec for domain-name-spaces from a conceptual 
perspective. It makes eminent sense. Concerning the implementation 
details, I am more agnostic. Have you considered for example, that 
usernames, projects etc. that have private names, could be simply 
converted into global names by prefixing them (or suffixing them) with 
the global domain name, without creating an extra "domain_name" 
parameter on the APIs. Would that work? Eduroam for example uses a 
similar scheme, by allowing local usernames to be used for 
authentication when you are logging in to the local site/domain, but you 
must use username at dns.name when logging in to a remote site (where 
dns.name is the DNS name of your domain).
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> *Token scoping to a domain*.  More easily enabling the
>>>>>>>> operation of domain-wide admin roles:
>>>>>>>> https://blueprints.launchpad.net/keystone/+spec/domain-scoping
>>>>>>>
>>>>>>>
>>>>>>>>
>>
>>>>>>>>
No comments on this spec for now
>>>>>>>
>>>>>>>>
>>>>>>>> *Domain role assignment.*  Providing more flexibility
>>>>>>>> in terms of what the current functionality means to
>>>>>>>> assign a role to a user-domain pair:
>>>>>>>> https://blueprints.launchpad.net/keystone/+spec/domain-role-assignment
>>>>>>>
>>>>>>>
>>>>>>>>
>>
>>>>>>>>
I would like to open up this whole discussion to "how is RBAC or ABAC to 
be used in general" ie. how are roles to be assigned, how are 
permissions to be granted etc. It seems that you are only addressing one 
small aspect of a much larger discussion in your current document.
>>>>>>>
>>>>>>> One could consider for example that roles can have global
>>>>>>> or local names, just like usernames and projects can have
>>>>>>> in your first blueprint above. What follows from this
>>>>>>> would be
>>>>>>>
>>>>>>> i) if a role has a globally unique name it can
>>>>>>> potentially give privileged access to all resources in
>>>>>>> all domains on all clouds (rather like the dollar gives
>>>>>>> me access to resources all over the world)
>>>>>>>
>>>>>>> ii) if a role has a local name then it can only give
>>>>>>> privileged access to resources that are within the same
>>>>>>> name space as itself.
>>>>>>>
>>>>>>> iii) a local role can be converted into a global role by
>>>>>>> prefixing it with the name of its name space
>>>>>>>
>>>>>>> Another issue to consider is, why are users restricted
>>>>>>> to only accessing resources within their own tenant? This
>>>>>>> is a needless restriction, and will cause us problems
>>>>>>> when we come to delegation of authority. A user with a
>>>>>>> globally unique role should potentially have access to
>>>>>>> all resources in all tenants (subject to the policy of
>>>>>>> the cloud service provider).
>>>>>>>
>>>>>>> Perhaps if we try to take a more global look at the
>>>>>>> current RBAC mechanism we can specify a less
>>>>>>> restrictive, conceptually simpler, ABAC scheme that is a
>>>>>>> superset of the current restrictive RBAC scheme. And then
>>>>>>> try to migrate towards this
>>>>>>>
>>>>>>> regards
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>>
>>>>>>>> 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
>>>>>
>>>>>
>>>>>>
>>
>>>>>>
_______________________________________________
>>>>> 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
>>>>
>>>
>>>
>>>
>>>>
_______________________________________________ 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
>
>
> _______________________________________________ OpenStack-dev mailing
> list OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>