On Mon, Oct 13, 2014 at 1:17 PM, Morgan Fainberg <morgan.fainb...@gmail.com>
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.
>
>
> 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.
>
> 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.
>
> 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).
>
> 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).
>
> 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.
>
>
> 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.
>
>
>
> 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.
>
I don't have another way to address this problem, but I do have a related
use case.
A smart 'nova help' that would only list commands that I can do. This
means knowing what extensions are available and what the policy file allows.
>
> 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
