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.
Thanks,
Morgan
—
Morgan Fainberg
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
