Re: [openstack-dev] [all][policy][keystone] Better Policy Model and Representing Capabilites
- Original Message -
From: Nathan Kinder nkin...@redhat.com
To: openstack-dev@lists.openstack.org
Sent: Tuesday, October 14, 2014 2:25:35 AM
Subject: Re: [openstack-dev] [all][policy][keystone] Better Policy Model and
Representing Capabilites
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.
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.
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).
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.
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
Re: [openstack-dev] [all][policy][keystone] Better Policy Model and Representing Capabilites
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
Re: [openstack-dev] [all][policy][keystone] Better Policy Model and Representing Capabilites
First, some truth in advertising: I work on Congress (policy as a service), so I’ve mostly given thought to this problem in that context. 1) I agree with the discussion below about creating a token that encodes all the permitted actions for the user. The cons seem substantial. (i) The token will get stale, requiring us to either revoke it when policy/roles change or to live with incorrect access control enforcement until the token expires. (ii) The token could become large, complex, or both. Suppose the policy is granular enough to put restrictions on the arguments a user is permitted to provide to an action. The token might end up encoding a significant portion of the policy itself. Checking if the token permits a given action could be similar computationally to checking the original policy.json file. 2) I like the idea of an out-of-band service that caches a copy of all the policy.jsons and allows users to interrogate/edit them. I’ve definitely talked to operators who would like this kind of thing. This would be a low-risk, low-friction solution to the problem because nothing about OpenStack today would need to change. We’d just add an extra service and tell people to use it—sort of a new UI for the policy.json files. And we could add interesting functionality, e.g. hypothetical queries such as “if I were to add role X, what changes would that make in my rights? Perhaps some more context about why users want to know all of the actions they are permitted to execute might help. Tim On Oct 14, 2014, at 1:56 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: 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://urldefense.proofpoint.com/v1/url?u=https://blog-nkinder.rhcloud.com/?p%3D101k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0Am=XcBszEjYqiYgkoy9iUk3baKeyYoE%2Bb20k6zm3jIXGAs%3D%0As=ff78352cef9982b47c9e6cca97aa001f38b13837387332a38b56ce30e1394b87 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
Re: [openstack-dev] [all][policy][keystone] Better Policy Model and Representing Capabilites
On 10/14/2014 07:42 AM, Tim Hinrichs wrote: First, some truth in advertising: I work on Congress (policy as a service), so I’ve mostly given thought to this problem in that context. 1) I agree with the discussion below about creating a token that encodes all the permitted actions for the user. The cons seem substantial. +1 (i) The token will get stale, requiring us to either revoke it when policy/roles change or to live with incorrect access control enforcement until the token expires. This is a very good point. (ii) The token could become large, complex, or both. Suppose the policy is granular enough to put restrictions on the arguments a user is permitted to provide to an action. The token might end up encoding a significant portion of the policy itself. Checking if the token permits a given action could be similar computationally to checking the original policy.json file. 2) I like the idea of an out-of-band service that caches a copy of all the policy.jsons and allows users to interrogate/edit them. I’ve definitely talked to operators who would like this kind of thing. This would be a low-risk, low-friction solution to the problem because nothing about OpenStack today would need to change. We’d just add an extra service and tell people to use it—sort of a new UI for the policy.json files. And we could add interesting functionality, e.g. hypothetical queries such as “if I were to add role X, what changes would that make in my rights? Perhaps some more context about why users want to know all of the actions they are permitted to execute might help. I think that there are two questions that a user may have here: 1) What actions can I perform using a particular token? 2) What role(s) do I need to perform a particular action? For me, the second question is more interesting. A user likely already has an idea of a task that they want to perform. With question number 1, what do I do as a user if the response says that I'm not allowed to perform the task I'm trying to accomplish? The answer really doesn't give me a way to move forward and perform my task. With question 2, I'm able to find out what exact roles are needed to perform a specific action. With this information, I could request a Keystone token with a subset of my roles that is authorized to perform the task while leaving out roles that might have a higher level of authorization. For instance, why should I need to send a token with the 'admin' role to Nova just to launch an instance if '_member_' is all that's required? Another real use case is determining what roles are needed when creating a trust in Keystone. If I want to use a trust to allow a service like Heat or Neutron's LBaaS to perform an action on my behalf, I want to minimize the authorization that I'm delegating to those services. Keystone trusts already have the ability to explicitly define the roles that will be present in the issues trust tokens, but I have no way of knowing what roles are required to perform a particular action without consulting the policy. -NGK Tim On Oct 14, 2014, at 1:56 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: 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
Re: [openstack-dev] [all][policy][keystone] Better Policy Model and Representing Capabilites
On Tuesday, October 14, 2014, Nathan Kinder nkin...@redhat.com wrote: On 10/14/2014 07:42 AM, Tim Hinrichs wrote: First, some truth in advertising: I work on Congress (policy as a service), so I’ve mostly given thought to this problem in that context. 1) I agree with the discussion below about creating a token that encodes all the permitted actions for the user. The cons seem substantial. +1 (i) The token will get stale, requiring us to either revoke it when policy/roles change or to live with incorrect access control enforcement until the token expires. This is a very good point. Totally valid point. Worth avoiding making this problem worse than today. We have this to a minor extent because roles are static within an issued token (policy file could be changed to mitigate). (ii) The token could become large, complex, or both. Suppose the policy is granular enough to put restrictions on the arguments a user is permitted to provide to an action. The token might end up encoding a significant portion of the policy itself. Checking if the token permits a given action could be similar computationally to checking the original policy.json file. 2) I like the idea of an out-of-band service that caches a copy of all the policy.jsons and allows users to interrogate/edit them. I’ve definitely talked to operators who would like this kind of thing. This would be a low-risk, low-friction solution to the problem because nothing about OpenStack today would need to change. We’d just add an extra service and tell people to use it—sort of a new UI for the policy.json files. And we could add interesting functionality, e.g. hypothetical queries such as “if I were to add role X, what changes would that make in my rights? Perhaps some more context about why users want to know all of the actions they are permitted to execute might help. I think that there are two questions that a user may have here: 1) What actions can I perform using a particular token? This is an important question to answer for tools like Horizon, we don't want to show capabilities or lock out capabilities so we don't need to try to know if it will succeed. This is purely UX. 2) What role(s) do I need to perform a particular action? For me, the second question is more interesting. A user likely already has an idea of a task that they want to perform. With question number 1, what do I do as a user if the response says that I'm not allowed to perform the task I'm trying to accomplish? The answer really doesn't give me a way to move forward and perform my task. With question 2, I'm able to find out what exact roles are needed to perform a specific action. With this information, I could request a Keystone token with a subset of my roles that is authorized to perform the task while leaving out roles that might have a higher level of authorization. For instance, why should I need to send a token with the 'admin' role to Nova just to launch an instance if '_member_' is all that's required? Another real use case is determining what roles are needed when creating a trust in Keystone. If I want to use a trust to allow a service like Heat or Neutron's LBaaS to perform an action on my behalf, I want to minimize the authorization that I'm delegating to those services. Keystone trusts already have the ability to explicitly define the roles that will be present in the issues trust tokens, but I have no way of knowing what roles are required to perform a particular action without consulting the policy This sums up the large(er) part of or starting this conversation. -NGK Tim On Oct 14, 2014, at 1:56 AM, David Chadwick d.w.chadw...@kent.ac.uk javascript:; wrote: 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
Re: [openstack-dev] [all][policy][keystone] Better Policy Model and Representing Capabilites
That was really helpful background. Thanks! 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. Let me know if that would help or if you’d prefer a different approach. Tim On Oct 14, 2014, at 10:31 AM, Morgan Fainberg morgan.fainb...@gmail.commailto:morgan.fainb...@gmail.com wrote: 2) What role(s) do I need to perform a particular action? For me, the second question is more interesting. A user likely already has an idea of a task that they want to perform. With question number 1, what do I do as a user if the response says that I'm not allowed to perform the task I'm trying to accomplish? The answer really doesn't give me a way to move forward and perform my task. With question 2, I'm able to find out what exact roles are needed to perform a specific action. With this information, I could request a Keystone token with a subset of my roles that is authorized to perform the task while leaving out roles that might have a higher level of authorization. For instance, why should I need to send a token with the 'admin' role to Nova just to launch an instance if '_member_' is all that's required? Another real use case is determining what roles are needed when creating a trust in Keystone. If I want to use a trust to allow a service like Heat or Neutron's LBaaS to perform an action on my behalf, I want to minimize the authorization that I'm delegating to those services. Keystone trusts already have the ability to explicitly define the roles that will be present in the issues trust tokens, but I have no way of knowing what roles are required to perform a particular action without consulting the policy This sums up the large(er) part of or starting this conversation. -NGK Tim On Oct 14, 2014, at 1:56 AM, David Chadwick d.w.chadw...@kent.ac.ukjavascript:; wrote: 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://urldefense.proofpoint.com/v1/url?u=https://blog-nkinder.rhcloud.com/?p%3D101k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0Am=XcBszEjYqiYgkoy9iUk3baKeyYoE%2Bb20k6zm3jIXGAs%3D%0As=ff78352cef9982b47c9e6cca97aa001f38b13837387332a38b56ce30e1394b87 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
Re: [openstack-dev] [all][policy][keystone] Better Policy Model and Representing Capabilites
There are two distinct permissions to be managed: 1. What can the user do. 2. What actions can this token be used to do. 2. is a subset of 1. Just because I, Adam Young, have the ability to destroy the golden image I have up on glance does not mean that I want to delegate that ability every time I use a token. But that is exactly the mechanism we have today. As a user, I should not be locked in to only delegating roles. A role may say you can read or modify an image but I want to only delegate the Read part when creating a new VM: I want Nova to be able to read the image I specify. Hence, I started a spec around capabilities which are I think, a different check than for RBAC. https://review.openstack.org/#/c/123726/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][policy][keystone] Better Policy Model and Representing Capabilites
This is a hot topic for some brainstorms here, since I started to hack a
bit with OpenStack =)
Regarding the given options, the second one looks better IMO, and we could
avoid some of the token bloating issues by having a parameter where the
service specifies what is set of actions that are important (the parameter
could be service name). Although we have some services with a huge set of
possible operations, like Nova.
But there is also some points that seem important to keep in mind, giving
that we have some cases for each action, not just the action itsel. For
example: update_project. A project_admin can update its own project but not
another project. And I don't see other options to check this than having
two different rules: update_own_project, update_any_project, and the rules
would be checked against the project_id in the token scope.
On Mon, Oct 13, 2014 at 5: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.
Thanks,
Morgan
—
Morgan Fainberg
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Rodrigo Duarte Sousa
Software Engineer
Re: [openstack-dev] [all][policy][keystone] Better Policy Model and Representing Capabilites
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.
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.
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).
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.
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.
I think we really want to avoid additional token bloat.
Thanks,
-NGK
I’m sure
