settingsLogin | Registersettings

[openstack-dev] [cross-project] RBAC Policy Basics

0 votes

Policy is supposed to allow access control to work across multiple
services and endpoints. However, each service has specified policy
differently.

Here are some of the basic working assumptions for policy enforcement we
can use to work towards consistent enforcement.

1) A policy rule should specify:
Where do I find the scope in this request?
What role does the token need to contain in order to access this
the API?

Roles are not global. Roles are always scoped to something. Just
because someone has "admin" on one project or domain does not mean they
should have it everywhere. However, we have found a need to have a
global override. This is a way a cloud admin that can go into any API
anywhere and fix things.Even if we keep the mechanism, I assume it will
take a few iterations to phase out having this specified on each rule.

2) Policy rules should be namespaced by API type.

for example, All of the Keystone policy rule targets start with:
"identity:"

such as

|"identity:ec2getcredential": "rule:adminrequired or (rule:owner and
user
id:%(target.credential.user_id)s)"|

This means that Glance, Neutron, Nova, and Keystone should be able to
share a policy file.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Jun 17, 2015 in openstack-dev by Adam_Young (19,940 points)   2 7 9

7 Responses

0 votes

Adam,

Thank you for the information RBAC Policy Basics.

Thursday, June 18, 2015 1:47 AM, Adam Young wrote:
However, we have found a need to have a global override. This is a way a cloud admin that can go into any API anywhere and fix things.
This means that Glance, Neutron, Nova, and Keystone should be able to share a policy file.

What situations does a shared policy file require?

For example, there are policy files for Nova and Cinder and they have same targets such as
"contextisadmin", "adminorowner" and "default".

(1) load both policy.json files on a server process then the targets will be overridden by 2nd loaded policy.json.
A cloud admin changes the 2nd policy.json only.
(2) A cloud admin changes the targets in different policy.json files at one time.

Did you mention about case(2)?

Nova: https://github.com/openstack/nova/blob/master/etc/nova/policy.json
Cinder: https://github.com/openstack/cinder/blob/master/etc/cinder/policy.json

"contextisadmin": "role:admin",
"adminorowner": "isadmin:True or projectid:%(projectid)s",
"default": "rule:admin
or_owner",

BTW, I sent the following email in this list. I think I found right person who
can answer my question? :-)

http://lists.openstack.org/pipermail/openstack-dev/2015-May/063915.html
- HTTPXSERVICE_ROLES handling in _checks.py

Thanks in advance,
Hisashi Osanai


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 19, 2015 by Osanai,_Hisashi (1,880 points)   3 6
0 votes

On 06/19/2015 01:08 AM, Osanai, Hisashi wrote:
Adam,

Thank you for the information RBAC Policy Basics.

Thursday, June 18, 2015 1:47 AM, Adam Young wrote:

However, we have found a need to have a global override. This is a way a cloud admin that can go into any API anywhere and fix things.
This means that Glance, Neutron, Nova, and Keystone should be able to share a policy file.
What situations does a shared policy file require?

For example, there are policy files for Nova and Cinder and they have same targets such as
"contextisadmin", "adminorowner" and "default".

A lot of these internal rules most likely should be removed. They do
conflict, with differenet interpretations between the proejcts. They are
also confusing two different things: scope and role./ I think we
should make it a point to keep them separate.

(1) load both policy.json files on a server process then the targets will be overridden by 2nd loaded policy.json.
A cloud admin changes the 2nd policy.json only.

Actually, we should specify when uploading whether it is an override or
not. If it is not an over rider, we would only pick up these "new"
rules that are not covered by existing ones.

I suspect that managing the stack of policy files this wayi s going to
be much like a git repo.

(2) A cloud admin changes the targets in different policy.json files at one time.

Did you mention about case(2)?

Nova: https://github.com/openstack/nova/blob/master/etc/nova/policy.json
Cinder: https://github.com/openstack/cinder/blob/master/etc/cinder/policy.json

"contextisadmin": "role:admin",
"adminorowner": "isadmin:True or projectid:%(projectid)s",
"default": "rule:admin
orowner",
I think we will need service specific defaults, although I could see the
case for the default everywhere being "if not specified, match the
project, and require the admin role." But matching the project is going
too be tricky. Nova has it in teh URL for the resources, but I don;t
think mnost of the other projects do...even if they do, it only takes
one sensitive operation without project
id in the URL to break the pattern.

BTW, I sent the following email in this list. I think I found right person who
can answer my question? :-)

http://lists.openstack.org/pipermail/openstack-dev/2015-May/063915.html
- HTTPXSERVICE_ROLES handling in _checks.py

I've missed there there was another push for "Service specif roles" out
there. We've been trying to make the concpet slighly more general by
saying that we were going to namespace roles, and that a Service would
be one potential namwspacing. Henry Nash had proposed Domain Specific
roles, in case you were wondering what else would need to be namespaced.

https://review.openstack.org/#/c/133855/

Thanks in advance,
Hisashi Osanai


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 20, 2015 by Adam_Young (19,940 points)   2 7 9
0 votes

On Saturday, June 20, 2015 11:16 AM, Adam Young wrote:

What situations does a shared policy file require?
For example, there are policy files for Nova and Cinder and they have
same targets such as
"contextisadmin", "adminorowner" and "default".

A lot of these internal rules most likely should be removed. They do
conflict, with differenet interpretations between the proejcts. They are
also confusing two different things: scope and role./ I think we
should make it a point to keep them separate.

I don't understand why you think it as conflicts. They use same target name
such as "contextisadmin", "adminorowner" and "default" but they use them
on different processes. I might have mis-understanding here but for me there
is no conflict.

I've missed there there was another push for "Service specif roles" out
there. We've been trying to make the concpet slighly more general by
saying that we were going to namespace roles, and that a Service would
be one potential namwspacing. Henry Nash had proposed Domain Specific
roles, in case you were wondering what else would need to be namespaced.

https://review.openstack.org/#/c/133855/

I like your thought " the concpet slighly more general" and it becomes a
solution for my issue.

My concern now is:
* Service Tokens was implemented in Juno [1] but now we are not able to
Implement it with Oslo policy without extensions so far.
* I think to implement spec[2] needs more time.

[1] https://github.com/openstack/keystone-specs/blob/master/specs/keystonemiddleware/implemented/service-tokens.rst
[2] https://review.openstack.org/#/c/133855/

Is there any way to support spec[1] in Oslo policy? Or
Should I wait for spec[2]?

Thanks in advance,
Hisashi Osanai


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 22, 2015 by Osanai,_Hisashi (1,880 points)   3 6
0 votes

On 06/22/2015 12:41 AM, Osanai, Hisashi wrote:
On Saturday, June 20, 2015 11:16 AM, Adam Young wrote:

What situations does a shared policy file require?
For example, there are policy files for Nova and Cinder and they have
same targets such as
"contextisadmin", "adminorowner" and "default".
A lot of these internal rules most likely should be removed. They do
conflict, with differenet interpretations between the proejcts. They are
also confusing two different things: scope and role./ I think we
should make it a point to keep them separate.
I don't understand why you think it as conflicts. They use same target name
such as "contextisadmin", "adminorowner" and "default" but they use them
on different processes. I might have mis-understanding here but for me there
is no conflict.

It is not an issue if you keep each of the policy files completely
separate, but it means that each service has its own meaning for the
same name, and that confuses operators; owner in Nova means "a user
that has a role on this project" where as "owner" in Keystone means
"Objects associated with a specific user".

http://lists.openstack.org/pipermail/openstack-dev/2015-May/063915.html
- HTTPXSERVICE_ROLES handling in _checks.py
I've missed there there was another push for "Service specif roles" out
there. We've been trying to make the concpet slighly more general by
saying that we were going to namespace roles, and that a Service would
be one potential namwspacing. Henry Nash had proposed Domain Specific
roles, in case you were wondering what else would need to be namespaced.

https://review.openstack.org/#/c/133855/
I like your thought " the concpet slighly more general" and it becomes a
solution for my issue.
Wow, I typoed this. Glad is was still comprehensible.

My concern now is:
* Service Tokens was implemented in Juno [1] but now we are not able to
Implement it with Oslo policy without extensions so far.
* I think to implement spec[2] needs more time.

[1] https://github.com/openstack/keystone-specs/blob/master/specs/keystonemiddleware/implemented/service-tokens.rst
[2] https://review.openstack.org/#/c/133855/

Is there any way to support spec[1] in Oslo policy? Or
Should I wait for spec[2]?

I'm sorry, I am not sure what you are asking.

Thanks in advance,
Hisashi Osanai


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 22, 2015 by Adam_Young (19,940 points)   2 7 9
0 votes

On Tuesday, June 23, 2015 12:14 AM, Adam Young wrote:

It is not an issue if you keep each of the policy files completely
separate, but it means that each service has its own meaning for the
same name, and that confuses operators; owner in Nova means "a user
that has a role on this project" where as "owner" in Keystone means
"Objects associated with a specific user".

I understand your thought came from usability.

But it might increase development complexity, I think each component
doesn't want to define own component name in the policy.json because
it's well-known there.
Unnn... Please forget it (it might be too development thought) :-)

I want to focus on the following topic:

My concern now is:
* Service Tokens was implemented in Juno [1] but now we are not able
to implement it with Oslo policy without extensions so far.
* I think to implement spec[2] needs more time.

[1] https://github.com/openstack/keystone-specs/blob/master/specs/keystonemiddleware/implemented/service-tokens.rst
[2] https://review.openstack.org/#/c/133855/

Is there any way to support spec[1] in Oslo policy? Or
Should I wait for spec[2]?

I'm sorry, I am not sure what you are asking.

I'm sorry let me explain this again.

(1) Keystone supports service tokens [1] from Juno release.
(2) Oslo policy graduated from Kilo release.
(3) Oslo policy doesn't have an ability to deal with the service tokens.
I'm not 100% sure but in order to support the service tokens Oslo policy
needs to handle service_roles in addition to roles stored in a credential.
Current logic:
If a rule which starts with 'role:', RoleCheck uses 'roles' in the credential.
code: https://github.com/openstack/oslo.policy/blob/master/oslo_policy/_checks.py#L249

My solution for this now is create ServiceRoleCheck class to handle 'service_roles' in
the credential. This check will be used when a rule starts with 'srole:'.
https://review.openstack.org/#/c/149930/15/swift/common/middleware/keystoneauth.py
L759-L767

I think it's better to handle by Oslo policy because of a common issue. So I would like
to know a plan to handle this issue.

Thanks in advance,
Hisashi Osanai


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 23, 2015 by Osanai,_Hisashi (1,880 points)   3 6
0 votes

On 06/23/2015 06:14 AM, Osanai, Hisashi wrote:
On Tuesday, June 23, 2015 12:14 AM, Adam Young wrote:

It is not an issue if you keep each of the policy files completely
separate, but it means that each service has its own meaning for the
same name, and that confuses operators; owner in Nova means "a user
that has a role on this project" where as "owner" in Keystone means
"Objects associated with a specific user".
I understand your thought came from usability.

But it might increase development complexity, I think each component
doesn't want to define own component name in the policy.json because
it's well-known there.
Unnn... Please forget it (it might be too development thought) :-)

I want to focus on the following topic:

My concern now is:
* Service Tokens was implemented in Juno [1] but now we are not able
to implement it with Oslo policy without extensions so far.
* I think to implement spec[2] needs more time.

[1] https://github.com/openstack/keystone-specs/blob/master/specs/keystonemiddleware/implemented/service-tokens.rst
[2] https://review.openstack.org/#/c/133855/

Is there any way to support spec[1] in Oslo policy? Or
Should I wait for spec[2]?
I'm sorry, I am not sure what you are asking.
I'm sorry let me explain this again.

(1) Keystone supports service tokens [1] from Juno release.
(2) Oslo policy graduated from Kilo release.
(3) Oslo policy doesn't have an ability to deal with the service tokens.
I'm not 100% sure but in order to support the service tokens Oslo policy
needs to handle serviceroles in addition to roles stored in a credential.
Current logic:
If a rule which starts with 'role:', RoleCheck uses 'roles' in the credential.
code: https://github.com/openstack/oslo.policy/blob/master/oslo_policy/_checks.py#L249

My solution for this now is create ServiceRoleCheck class to handle 'service
roles' in
the credential. This check will be used when a rule starts with 'srole:'.
https://review.openstack.org/#/c/149930/15/swift/common/middleware/keystoneauth.py
L759-L767
OK, I think I get it; you want to make a check specific to the roles on
the service token. The term Service roles confused me.

You can do this check with oslo.messaging today. Don't uyse the role
check, just a generic check.
It looks for an elelement in a collection, and reeturns true if it is in
there; see

http://git.openstack.org/cgit/openstack/oslo.policy/commit/?id=a08bc79f5c117696c43feb2e44c4dc5fd0013deb

I think it's better to handle by Oslo policy because of a common issue. So I would like
to know a plan to handle this issue.

Thanks in advance,
Hisashi Osanai


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 23, 2015 by Adam_Young (19,940 points)   2 7 9
0 votes

On Tuesday, June 23, 2015 10:30 PM, Adam Young wrote:

OK, I think I get it; you want to make a check specific to the roles
on the service token. The term Service roles confused me.

You can do this check with oslo.messaging today. Don't uyse the role
check, just a generic check.
It looks for an elelement in a collection, and reeturns true if it is
in there; see

http://git.openstack.org/cgit/openstack/oslo.policy/commit/?id=a08bc
79f5c117696c43feb2e44c4dc5fd0013deb

Cool! This is what I wanted to have. :-)

Thanks!
Hisashi Oasnai


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 24, 2015 by Osanai,_Hisashi (1,880 points)   3 6
...