On 14/10/2014 01:25, Nathan Kinder wrote: > > > On 10/13/2014 01:17 PM, Morgan Fainberg wrote: >> Description of the problem: Without attempting an action on an >> endpoint with a current scoped token, it is impossible to know what >> actions are available to a user. >>
This is not unusual in the physical world. If you think about all the authz tokens you carry around in your pocket (as plastic cards), very few of them (if any) list what you are entitled to do with them. This gives the issuers and SPs flexibility to dynamically change your accesses rights without changing your authorisation. What you can do, in general terms, may be written in policy documents that you can consult if you wish. So you may wish to introduce a service that is equivalent to this (i.e. user may optionally consult some policy advice service). If you introduce a service to allow a user to dynamically determine his access rights (absolutely), you have to decide what to do about the dynamics of this service compared to the lifetime of the keystone token, as the rights may change more quickly than the token's lifetime. >> >> Horizon makes some attempts to solve this issue by sourcing all of >> the policy files from all of the services to determine what a user >> can accomplish with a given role. This is highly inefficient as it >> requires processing the various policy.json files for each request >> in multiple places and presents a mechanism that is not really >> scalable to understand what a user can do with the current >> authorization. Horizon may not be the only service that (in the >> long term) would want to know what actions a token can take. > > This is also extremely useful for being able to actually support > more restricted tokens as well. If I as an end user want to request > a token that only has the roles required to perform a particular > action, I'm going to need to have a way of knowing what those roles > are. I think that is one of the main things missing to allow the > "role-filtered tokens" option that I wrote up after the last Summit > to be a viable approach: > > https://blog-nkinder.rhcloud.com/?p=101 > >> >> I would like to start a discussion on how we should improve our >> policy implementation (OpenStack wide) to help make it easier to >> know what is possible with a current authorization context >> (Keystone token). The key feature should be that whatever the >> implementation is, it doesn’t require another round-trip to a third >> party service to “enforce” the policy which avoids another scaling >> point like UUID Keystone token validation. Presumably this does not rule out the user, at his option, calling another service to ask for advice "what can I do with this token", bearing in mind that the response will be advice and not a definite answer (since the PDP will always be the one to provide the definitive answer). >> >> Here are a couple of ideas that we’ve discussed over the last few >> development cycles (and none of this changes the requirements to >> manage scope of authorization, e.g. project, domain, trust, ...): >> >> 1. Keystone is the holder of all policy files. Each service gets >> it’s policy file from Keystone and it is possible to validate the >> policy (by any other service) against a token provided they get the >> relevant policy file from the authoritative source (Keystone). Can I suggest that this is made more abstract, to say, there is a central policy administration service that stores all policies and allows them to be updated, deleted, created, inherited etc. Whether this service is combined with keystone or not in the implementation is a separate issue. Conceptually it is a new type of policy administration service for OpenStack. >> >> Pros: This is nearly completely compatible with the current policy >> system. The biggest change is that policy files are published to >> Keystone instead of to a local file on disk. This also could open >> the door to having keystone build “stacked” policies >> (user/project/domain/endpoint/service specific) where the deployer >> could layer policy definitions (layering would allow for stricter >> enforcement at more specific levels, e.g. users from project X >> can’t terminate any VMs). > > I think that there are a some additional advantages to centralizing > policy storage (not enforcement). > > - The ability to centralize management of policy would be very nice. > If I want to update the policy for all of my compute nodes, I can do > it in one location without the need for external configuration > management solutions. > > - We could piggy-back on Keystone's signing capabilities to allow > policy to be signed, providing protection against policy tampering on > an individual endpoint. > >> >> Cons: This doesn’t ease up the processing requirement or the need >> to hold (potentially) a significant number of policy files for each >> service that wants to evaluate what actions a token can do. if you separate out an optional advice service from the decision/enforcement service, this might provide the flexibility and performance that you need. E.g. the advice service could cache results and computations, whilst the decision service would not. The advice service could be part of the policy administration service, and separate from the decision/enforcement service. > > Are you thinking of there being a call to keystone that answers > "what can I do with token A against endpoint B"? This seems similar > in concept to the LDAP "get effective rights" control. There would > definitely be some processing overhead to this though you could set > up multiple keystone instances and replicate the policy to spread out > the load. It also might be possible to index the enforcement points > by role in an attempt to minimize the processing for this sort of > call. > >> >> >> 2. Each enforcement point in a service is turned into an >> attribute/role, and the token contains all of the information on >> what a user can do (effectively shipping the entire policy >> information with the token). >> >> Pros: It is trivial to know what a token provides access to: the >> token would contain something like `{“nova”: [“terminate”, “boot”], >> “keystone”: [“create_user”, “update_user”], ...}`. It would be >> easily possible to allow glance “get image” nova “boot” capability >> instead of needing to know the roles for policy.json for both >> glance and nova work for booting a new VM. >> >> Cons: This would likely require a central registry of all the >> actions that could be taken (something akin to an IANA port list). >> Without a grouping to apply these authorizations to a user (e.g. >> keystone_admin would convey “create_project, delete_project, >> update_project, create_user, delete_user, update_user, ...”) this >> becomes unwieldy. The “roles” or “attribute” that convey >> capabilities are also relatively static instead of highly dynamic >> as they are today. This could also contribute to token-bloat. Another con is the time lapse, since the token is created at time a with the access rights applicable at that time, but is used some time later at time b, when the rights might have changed, but the token has not. So unless the token is a one time immediate use token, you have the problem of revocation due to it containing rights that should now be withdrawn. regards David > > I think we really want to avoid additional token bloat. > > Thanks, -NGK > >> >> >> >> I’m sure there are more ways to approach this problem, so please >> don’t hesitate to add to the conversation and expand on the >> options. The above options are by no mean exhaustive nor fully >> explored. This change may not even be something to be expected >> within the current development cycle (Kilo) or even the next, but >> this is a conversation that needs to be started as it will help >> make OpenStack better. >> >> Thanks, Morgan >> >> — Morgan Fainberg >> >> >> >> _______________________________________________ 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 > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
