<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div>That was really helpful background. Thanks!</div>
<div><br>
</div>
<div>I’d be happy to look into using Congress to implement what we’ve discussed: caching policy.json files, updating them periodically, and answering queries about the roles required to be granted access to a certain kind of action. I think we have the right
algorithms sitting around. </div>
<div><br>
</div>
<div>Let me know if that would help or if you’d prefer a different approach.</div>
<div><br>
</div>
<div>Tim</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
<div>
<div>On Oct 14, 2014, at 10:31 AM, Morgan Fainberg <<a href="mailto:morgan.fainberg@gmail.com">morgan.fainberg@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) What role(s) do I need to perform a particular action?<br>
<br>
For me, the second question is more interesting. A user likely already<br>
has an idea of a task that they want to perform. With question number<br>
1, what do I do as a user if the response says that I'm not allowed to<br>
perform the task I'm trying to accomplish? The answer really doesn't<br>
give me a way to move forward and perform my task.<br>
<br>
With question 2, I'm able to find out what exact roles are needed to<br>
perform a specific action. With this information, I could request a<br>
Keystone token with a subset of my roles that is authorized to perform<br>
the task while leaving out roles that might have a higher level of<br>
authorization. For instance, why should I need to send a token with the<br>
'admin' role to Nova just to launch an instance if '_member_' is all<br>
that's required?<br>
<br>
Another real use case is determining what roles are needed when creating<br>
a trust in Keystone. If I want to use a trust to allow a service like<br>
Heat or Neutron's LBaaS to perform an action on my behalf, I want to<br>
minimize the authorization that I'm delegating to those services.<br>
Keystone trusts already have the ability to explicitly define the roles<br>
that will be present in the issues trust tokens, but I have no way of<br>
knowing what roles are required to perform a particular action without<br>
consulting the policy</blockquote>
<div> </div>
<div>This sums up the large(er) part of or starting this conversation.</div>
<div> </div>
</blockquote>
<blockquote type="cite">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-NGK<br>
<br>
><br>
> Tim<br>
><br>
><br>
><br>
> On Oct 14, 2014, at 1:56 AM, David Chadwick <<a href="javascript:;" onclick="_e(event, 'cvml', 'd.w.chadwick@kent.ac.uk')">d.w.chadwick@kent.ac.uk</a>> wrote:<br>
><br>
>><br>
>><br>
>> On 14/10/2014 01:25, Nathan Kinder wrote:<br>
>>><br>
>>><br>
>>> On 10/13/2014 01:17 PM, Morgan Fainberg wrote:<br>
>>>> Description of the problem: Without attempting an action on an<br>
>>>> endpoint with a current scoped token, it is impossible to know what<br>
>>>> actions are available to a user.<br>
>>>><br>
>><br>
>> This is not unusual in the physical world. If you think about all the<br>
>> authz tokens you carry around in your pocket (as plastic cards), very<br>
>> few of them (if any) list what you are entitled to do with them. This<br>
>> gives the issuers and SPs flexibility to dynamically change your<br>
>> accesses rights without changing your authorisation. What you can do, in<br>
>> general terms, may be written in policy documents that you can consult<br>
>> if you wish. So you may wish to introduce a service that is equivalent<br>
>> to this (i.e. user may optionally consult some policy advice service).<br>
>><br>
>> If you introduce a service to allow a user to dynamically determine his<br>
>> access rights (absolutely), you have to decide what to do about the<br>
>> dynamics of this service compared to the lifetime of the keystone token,<br>
>> as the rights may change more quickly than the token's lifetime.<br>
>><br>
>>>><br>
>>>> Horizon makes some attempts to solve this issue by sourcing all of<br>
>>>> the policy files from all of the services to determine what a user<br>
>>>> can accomplish with a given role. This is highly inefficient as it<br>
>>>> requires processing the various policy.json files for each request<br>
>>>> in multiple places and presents a mechanism that is not really<br>
>>>> scalable to understand what a user can do with the current<br>
>>>> authorization. Horizon may not be the only service that (in the<br>
>>>> long term) would want to know what actions a token can take.<br>
>>><br>
>>> This is also extremely useful for being able to actually support<br>
>>> more restricted tokens as well. If I as an end user want to request<br>
>>> a token that only has the roles required to perform a particular<br>
>>> action, I'm going to need to have a way of knowing what those roles<br>
>>> are. I think that is one of the main things missing to allow the<br>
>>> "role-filtered tokens" option that I wrote up after the last Summit<br>
>>> to be a viable approach:<br>
>>><br>
>>> <a href="https://urldefense.proofpoint.com/v1/url?u=https://blog-nkinder.rhcloud.com/?p%3D101&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=XcBszEjYqiYgkoy9iUk3baKeyYoE%2Bb20k6zm3jIXGAs%3D%0A&s=ff78352cef9982b47c9e6cca97aa001f38b13837387332a38b56ce30e1394b87" target="_blank">
https://urldefense.proofpoint.com/v1/url?u=https://blog-nkinder.rhcloud.com/?p%3D101&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=XcBszEjYqiYgkoy9iUk3baKeyYoE%2Bb20k6zm3jIXGAs%3D%0A&s=ff78352cef9982b47c9e6cca97aa001f38b13837387332a38b56ce30e1394b87</a><br>
>>><br>
>>>><br>
>>>> I would like to start a discussion on how we should improve our<br>
>>>> policy implementation (OpenStack wide) to help make it easier to<br>
>>>> know what is possible with a current authorization context<br>
>>>> (Keystone token). The key feature should be that whatever the<br>
>>>> implementation is, it doesn’t require another round-trip to a third<br>
>>>> party service to “enforce” the policy which avoids another scaling<br>
>>>> point like UUID Keystone token validation.<br>
>><br>
>> Presumably this does not rule out the user, at his option, calling<br>
>> another service to ask for advice "what can I do with this token",<br>
>> bearing in mind that the response will be advice and not a definite<br>
>> answer (since the PDP will always be the one to provide the definitive<br>
>> answer).<br>
>><br>
>><br>
>><br>
>>>><br>
>>>> Here are a couple of ideas that we’ve discussed over the last few<br>
>>>> development cycles (and none of this changes the requirements to<br>
>>>> manage scope of authorization, e.g. project, domain, trust, ...):<br>
>>>><br>
>>>> 1. Keystone is the holder of all policy files. Each service gets<br>
>>>> it’s policy file from Keystone and it is possible to validate the<br>
>>>> policy (by any other service) against a token provided they get the<br>
>>>> relevant policy file from the authoritative source (Keystone).<br>
>><br>
>> Can I suggest that this is made more abstract, to say, there is a<br>
>> central policy administration service that stores all policies and<br>
>> allows them to be updated, deleted, created, inherited etc.<br>
>><br>
>> Whether this service is combined with keystone or not in the<br>
>> implementation is a separate issue. Conceptually it is a new type of<br>
>> policy administration service for OpenStack.<br>
>><br>
>>>><br>
>>>> Pros: This is nearly completely compatible with the current policy<br>
>>>> system. The biggest change is that policy files are published to<br>
>>>> Keystone instead of to a local file on disk. This also could open<br>
>>>> the door to having keystone build “stacked” policies<br>
>>>> (user/project/domain/endpoint/service specific) where the deployer<br>
>>>> could layer policy definitions (layering would allow for stricter<br>
>>>> enforcement at more specific levels, e.g. users from project X<br>
>>>> can’t terminate any VMs).<br>
>>><br>
>>> I think that there are a some additional advantages to centralizing<br>
>>> policy storage (not enforcement).<br>
>>><br>
>>> - The ability to centralize management of policy would be very nice.<br>
>>> If I want to update the policy for all of my compute nodes, I can do<br>
>>> it in one location without the need for external configuration<br>
>>> management solutions.<br>
>>><br>
>>> - We could piggy-back on Keystone's signing capabilities to allow<br>
>>> policy to be signed, providing protection against policy tampering on<br>
>>> an individual endpoint.<br>
>>><br>
>>>><br>
>>>> Cons: This doesn’t ease up the processing requirement or the need<br>
>>>> to hold (potentially) a significant number of policy files for each<br>
>>>> service that wants to evaluate what actions a token can do.<br>
>><br>
>> if you separate out an optional advice service from the<br>
>> decision/enforcement service, this might provide the flexibility and<br>
>> performance that you need. E.g. the advice service could cache results<br>
>> and computations, whilst the decision service would not. The advice<br>
>> service could be part of the policy administration service, and separate<br>
>> from the decision/enforcement service.<br>
>><br>
>>><br>
>>> Are you thinking of there being a call to keystone that answers<br>
>>> "what can I do with token A against endpoint B"? This seems similar<br>
>>> in concept to the LDAP "get effective rights" control. There would<br>
>>> definitely be some processing overhead to this though you could set<br>
>>> up multiple keystone instances and replicate the policy to spread out<br>
>>> the load. It also might be possible to index the enforcement points<br>
>>> by role in an attempt to minimize the processing for this sort of<br>
>>> call.<br>
>>><br>
>>>><br>
>>>><br>
>>>> 2. Each enforcement point in a service is turned into an<br>
>>>> attribute/role, and the token contains all of the information on<br>
>>>> what a user can do (effectively shipping the entire policy<br>
>>>> information with the token).<br>
>>>><br>
>>>> Pros: It is trivial to know what a token provides access to: the<br>
>>>> token would contain something like `{“nova”: [“terminate”, “boot”],<br>
>>>> “keystone”: [“create_user”, “update_user”], ...}`. It would be<br>
>>>> easily possible to allow glance “get image” nova “boot” capability<br>
>>>> instead of needing to know the roles for policy.json for both<br>
>>>> glance and nova work for booting a new VM.<br>
>>>><br>
>>>> Cons: This would likely require a central registry of all the<br>
>>>> actions that could be taken (something akin to an IANA port list).<br>
>>>> Without a grouping to apply these authorizations to a user (e.g.<br>
>>>> keystone_admin would convey “create_project, delete_project,<br>
>>>> update_project, create_user, delete_user, update_user, ...”) this<br>
>>>> becomes unwieldy. The “roles” or “attribute” that convey<br>
>>>> capabilities are also relatively static instead of highly dynamic<br>
>>>> as they are today. This could also contribute to token-bloat.<br>
>><br>
>> Another con is the time lapse, since the token is created at time a with<br>
>> the access rights applicable at that time, but is used some time later<br>
>> at time b, when the rights might have changed, but the token has not. So<br>
>> unless the token is a one time immediate use token, you have the problem<br>
>> of revocation due to it containing rights that should now be withdrawn.<br>
>><br>
>> regards<br>
>><br>
>> David<br>
>><br>
>>><br>
>>> I think we really want to avoid additional token bloat.<br>
>>><br>
>>> Thanks, -NGK<br>
>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> I’m sure there are more ways to approach this problem, so please<br>
>>>> don’t hesitate to add to the conversation and expand on the<br>
>>>> options. The above options are by no mean exhaustive nor fully<br>
>>>> explored. This change may not even be something to be expected<br>
>>>> within the current development cycle (Kilo) or even the next, but<br>
>>>> this is a conversation that needs to be started as it will help<br>
>>>> make OpenStack better.<br>
>>>><br>
>>>> Thanks, Morgan<br>
>>>><br>
<br>
</blockquote>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>
</blockquote>
</div>
<br>
</div>
</body>
</html>