Re: [openstack-dev] [cross-project] Admin
On 10/24/2015 12:46 AM, Clint Byrum wrote: Can I ask one thing though, can we use a domain name + project_name_ and not the ID? I think we can do that. The submitted patch for the overall spec is here: https://review.openstack.org/#/c/205629/ and the change for Keystone is here: https://review.openstack.org/#/c/240719/ Both of these are WIP. Please post your changed request on the review. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cross-project] Admin
Excerpts from Adam Young's message of 2015-10-19 22:53:14 +0900:
> While I tend to play up bug 968696 for dramatic effect, the reality is
> we have a logical contradiction on what we mean by 'admin' when talking
> about RBAC.
>
> In early iterations of OpenStack, roles were global. This is reflected
> in many of the Policy checks that only look for the global role.
> However, prior to the Keystone-Light rewrite, role assignments became
> scoped to tenants. This shows up in the Keystone git history. As this
> pattern got established, some people wrote policy checks that assert:
>
> role==admin and tenant_id=resource.tenant_id
>
> This contradicts the global-ness of the admin roles. If I assign
> ('joeuser', 'admin','mytenant') I've just granted them the ability to
> perform all of the admin operations.
>
> Thus, today we have a situation where, unless the user rewrites the
> default policy, they have to only assign the role admins to users that
> are trusted to be admins on the whole deployment.
>
> We have a few choices.
>
> 1. Remove Admin from the scoping for projects. Admin is a special role
> reserved only for system admins. Replace project scoped admins with
> 'manager' or some other comparable role. This is actually the easiest
> solution.
>
> 2. Create a special project for administrative actions. Cloud admin
> users are assigned to this project. Communicate that project Id to the
> remote systems. This is what the policy.v3cloudsample.json file
> (http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json)
>
> recommends.
>
> However, 2 is really not practical without some significant
> engineering. For a new deployment, it would require the following steps.
> 1) Every single policy file would have to be "templatized"
> 2) Then deployment mechanism would have to create the admin project, get
> the id for it, and string replace it in the policy file.
I'm glad we're hashing the details of this out, because I've always
found policy file maintenance daunting because of the weird juxtaposition
between careful role assignment, and the user-0 super user access that
'admin' grants.
Can I ask one thing though, can we use a domain name + project _name_
and not the ID?
Using ids in config files means that you cannot configure a service
until after Keystone has been initialized and loaded with data. Of
course this is totally doable, but it puts a huge burden on the config
layer.
However, using logical names means that the physical, random ID that gets
assigned is irrelevant to the configuration step, and thus one can have
a much easier to understand configuration process with static options.
My understanding is that domain+project is a unique ID in Keystone, so
is there any reason not to use that?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cross-project] Admin
Adam Young wrote on 10/22/2015 10:31:12 AM:
> On 10/22/2015 05:16 AM, William M Edmonds wrote:
> Adam Young wrote on 10/19/2015 09:53:14 AM:
> > While I tend to play up bug 968696 for dramatic effect, the reality is
> > we have a logical contradiction on what we mean by 'admin' when talking
> > about RBAC.
> >
> > In early iterations of OpenStack, roles were global. This is reflected
> > in many of the Policy checks that only look for the global role.
> > However, prior to the Keystone-Light rewrite, role assignments became
> > scoped to tenants. This shows up in the Keystone git history. As this
> > pattern got established, some people wrote policy checks that assert:
> >
> > role==admin and tenant_id=resource.tenant_id
> >
> > This contradicts the global-ness of the admin roles. If I assign
> > ('joeuser', 'admin','mytenant') I've just granted them the ability to
> > perform all of the admin operations.
> >
> > Thus, today we have a situation where, unless the user rewrites the
> > default policy, they have to only assign the role admins to users that
> > are trusted to be admins on the whole deployment.
> >
>
> This all appears to be based on a misassumptions that a) checking
> the project id should be done in policy.json files and b) if it's
> not being checked in the policy file then it's not being checked.
> Neither of those is the case. Many APIs check project id in the
> code, which is where it should be checked. Tokens are scoped to
> projects, thus any use of those tokens should necessarily be scoped
> to the project... otherwise you're not obeying the token scoping.
> The few places that are not already enforcing that in their code
> need to be fixed to start enforcing that. It doesn't make sense to
> do that in policy files, since this is a hard and fast rule, not
> something someone needs to be able to change in policy, or should be
> able to change. Nor would it be practical to put this in policy
> files when you realize that this logic applies to all roles, not just
admin.
>
> I agree that project_id check is better performed in code. That is
> not the issue here.
>
> Checking Project ID needs to be done, policy file or code does not
> matter. The problem is more fundamental.
>
> 0. All access is done with Keystone tokens.
> 1. Admin is a role assigned on a project. Always.
> 2. Some APIs have no project with which to check the Scope.
if the URI of the API doesn't include the project, then the code should
limit the request to the scope of the token. No need to check that the
scope of the token matches the scope of the API because scope wasn't
indicated on the API, i.e. scope is implicit based on the token.
> 3. We do not, today, have a means to communicate the scope for an
> admin project.
I don't know what you mean here. "Scope for an admin project"? The scope of
a project is the things that are in that project. And admin is a role that
can exist on any project per #1, i.e., there is no "admin project". We may
need to create the concept of an admin project for keystone in order to
address 968696, but that would be a keystone concept and irrelevant to
nova, cinder, etc.
-matthew
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cross-project] Admin
On 10/22/2015 05:16 AM, William M Edmonds wrote:
Adam Young wrote on 10/19/2015 09:53:14 AM:
> While I tend to play up bug 968696 for dramatic effect, the reality is
> we have a logical contradiction on what we mean by 'admin' when talking
> about RBAC.
>
> In early iterations of OpenStack, roles were global. This is reflected
> in many of the Policy checks that only look for the global role.
> However, prior to the Keystone-Light rewrite, role assignments became
> scoped to tenants. This shows up in the Keystone git history. As this
> pattern got established, some people wrote policy checks that assert:
>
> role==admin and tenant_id=resource.tenant_id
>
> This contradicts the global-ness of the admin roles. If I assign
> ('joeuser', 'admin','mytenant') I've just granted them the ability to
> perform all of the admin operations.
>
> Thus, today we have a situation where, unless the user rewrites the
> default policy, they have to only assign the role admins to users that
> are trusted to be admins on the whole deployment.
>
This all appears to be based on a misassumptions that a) checking the
project id should be done in policy.json files and b) if it's not
being checked in the policy file then it's not being checked. Neither
of those is the case. Many APIs check project id in the code, which is
where it should be checked. Tokens are scoped to projects, thus any
use of those tokens should necessarily be scoped to the project...
otherwise you're not obeying the token scoping. The few places that
are not already enforcing that in their code need to be fixed to start
enforcing that. It doesn't make sense to do that in policy files,
since this is a hard and fast rule, not something someone needs to be
able to change in policy, or should be able to change. Nor would it be
practical to put this in policy files when you realize that this logic
applies to all roles, not just admin.
I agree that project_id check is better performed in code. That is not
the issue here.
Checking Project ID needs to be done, policy file or code does not
matter. The problem is more fundamental.
0. All access is done with Keystone tokens.
1. Admin is a role assigned on a project. Always.
2. Some APIs have no project with which to check the Scope.
3. We do not, today, have a means to communicate the scope for an admin
project.
-Matthew
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cross-project] Admin
Adam Young wrote on 10/19/2015 09:53:14 AM:
> While I tend to play up bug 968696 for dramatic effect, the reality is
> we have a logical contradiction on what we mean by 'admin' when talking
> about RBAC.
>
> In early iterations of OpenStack, roles were global. This is reflected
> in many of the Policy checks that only look for the global role.
> However, prior to the Keystone-Light rewrite, role assignments became
> scoped to tenants. This shows up in the Keystone git history. As this
> pattern got established, some people wrote policy checks that assert:
>
> role==admin and tenant_id=resource.tenant_id
>
> This contradicts the global-ness of the admin roles. If I assign
> ('joeuser', 'admin','mytenant') I've just granted them the ability to
> perform all of the admin operations.
>
> Thus, today we have a situation where, unless the user rewrites the
> default policy, they have to only assign the role admins to users that
> are trusted to be admins on the whole deployment.
>
This all appears to be based on a misassumptions that a) checking the
project id should be done in policy.json files and b) if it's not being
checked in the policy file then it's not being checked. Neither of those is
the case. Many APIs check project id in the code, which is where it should
be checked. Tokens are scoped to projects, thus any use of those tokens
should necessarily be scoped to the project... otherwise you're not obeying
the token scoping. The few places that are not already enforcing that in
their code need to be fixed to start enforcing that. It doesn't make sense
to do that in policy files, since this is a hard and fast rule, not
something someone needs to be able to change in policy, or should be able
to change. Nor would it be practical to put this in policy files when you
realize that this logic applies to all roles, not just admin.
-Matthew
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cross-project] Admin
On 10/19/2015 12:50 PM, Fox, Kevin M wrote: Maybe I misunderstood then. I was thinking you were proposing endpoint scoped tokens. But heat calls out to other endpoints itself, so if a token is scoped to heat, it can't relay it further. Right...not proposing that. This is specifically for operations on the Services themselves, or for operations that are not cleanly scoped to an existing project. I *think* it just makes explicit what people have been doing implicitly. Trying not to break things too badly. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cross-project] Admin
Maybe I misunderstood then. I was thinking you were proposing endpoint scoped
tokens. But heat calls out to other endpoints itself, so if a token is scoped
to heat, it can't relay it further.
Thanks,
Kevin
From: Adam Young [ayo...@redhat.com]
Sent: Monday, October 19, 2015 9:00 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [cross-project] Admin
On 10/19/2015 11:53 AM, Fox, Kevin M wrote:
+1.
I think there may be a slight issue with this and Heat, or any other service
depending on Heat though. It would have to be very carefully through through,
since Heat acts on behalf of the user as the User him/herself would, so scoping
may need to interact differently there, then say Nova. Maybe a flag in the
service catalog saying if the service can be scoped or not?
I think there is a subtlety there you are not making clear. Why would Heat, or
any other service not be scoped? The only rule I am seeing in Heat's policy
would be
"service:index": "rule:context_is_admin",
http://git.openstack.org/cgit/openstack/heat/tree/etc/heat/policy.json
But that certainly suffers from the admin-ess problem. There is certainly
something strange with the deny rules; it is trivial to bypass this role with
a trust. Somethin needs a second look there anyway.
Thanks,
Kevin
From: Adam Young [ayo...@redhat.com<mailto:ayo...@redhat.com>]
Sent: Monday, October 19, 2015 6:53 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [cross-project] Admin
While I tend to play up bug 968696 for dramatic effect, the reality is
we have a logical contradiction on what we mean by 'admin' when talking
about RBAC.
In early iterations of OpenStack, roles were global. This is reflected
in many of the Policy checks that only look for the global role.
However, prior to the Keystone-Light rewrite, role assignments became
scoped to tenants. This shows up in the Keystone git history. As this
pattern got established, some people wrote policy checks that assert:
role==admin and tenant_id=resource.tenant_id
This contradicts the global-ness of the admin roles. If I assign
('joeuser', 'admin','mytenant') I've just granted them the ability to
perform all of the admin operations.
Thus, today we have a situation where, unless the user rewrites the
default policy, they have to only assign the role admins to users that
are trusted to be admins on the whole deployment.
We have a few choices.
1. Remove Admin from the scoping for projects. Admin is a special role
reserved only for system admins. Replace project scoped admins with
'manager' or some other comparable role. This is actually the easiest
solution.
2. Create a special project for administrative actions. Cloud admin
users are assigned to this project. Communicate that project Id to the
remote systems. This is what the policy.v3cloudsample.json file
(http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json)
recommends.
However, 2 is really not practical without some significant
engineering. For a new deployment, it would require the following steps.
1) Every single policy file would have to be "templatized"
2) Then deployment mechanism would have to create the admin project, get
the id for it, and string replace it in the policy file.
We could make this happen in Devstack. The same is true of Puppet,
OSAD, and Fuel. There would be a lag and the downstream mechanisms
would eventually pick it up, multiple releases down the road.
I went through this logic back when I started proposing the Dynamic
Policy approach. If OpenStack managed policy deployment via an
inte4rnal mechanism, then adding things like the admin_project_id
becomes trivial.
While I think Dynamic Policy provides a lot of value, I concede that it
is overkill for just substituting in a single value. The real reason I
am backing off Dynamic Policy for the moment is that we need to better
understand what part of policy should be dynamic and what part should be
static; we are just getting that clean now.
There is an additional dimension to the admin_project_id issue that
several developers want solved. In larger deployments, different users
should have administrative capabilities on different endpoints.
Sometimes this is segregated by service (storage admins vs network
admins) and sometimes by region.
Having a special project clearly communicates the intention of RBAC.
But even clearer would be to have the role assignment explicitly on the
catalog item itself. Which of the following statements would you think
is clearer?
1) Assign Joe the admin role on the project designated to administer
endpoint 0816.
2) 1) Assign Joe the admin role on endpoint 0816.
I think you will agree that it is the latter. Making this happen would
not be too difficult on the Ke
Re: [openstack-dev] [cross-project] Admin
On 10/19/2015 12:39 PM, Neil Jerram wrote:
On 19/10/15 14:57, Adam Young wrote:
While I tend to play up bug 968696 for dramatic effect, the reality is
we have a logical contradiction on what we mean by 'admin' when talking
about RBAC.
In early iterations of OpenStack, roles were global. This is reflected
in many of the Policy checks that only look for the global role.
However, prior to the Keystone-Light rewrite, role assignments became
scoped to tenants. This shows up in the Keystone git history. As this
pattern got established, some people wrote policy checks that assert:
role==admin and tenant_id=resource.tenant_id
This contradicts the global-ness of the admin roles. If I assign
('joeuser', 'admin','mytenant') I've just granted them the ability to
perform all of the admin operations.
I'm afraid I'm not sure I follow. Do you mean all of the admin
operations on resources that are protected only by 'role==admin' ?
Yes, exactly. For example, Nova has such a call with "Hypervisors"
http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json#n159
An there is no clear project that this call can be scoped to.
Contrast this with update-quota which should be scoped to a project.
http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json#n175
Neil
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cross-project] Admin
On 19/10/15 14:57, Adam Young wrote:
> While I tend to play up bug 968696 for dramatic effect, the reality is
> we have a logical contradiction on what we mean by 'admin' when talking
> about RBAC.
>
> In early iterations of OpenStack, roles were global. This is reflected
> in many of the Policy checks that only look for the global role.
> However, prior to the Keystone-Light rewrite, role assignments became
> scoped to tenants. This shows up in the Keystone git history. As this
> pattern got established, some people wrote policy checks that assert:
>
> role==admin and tenant_id=resource.tenant_id
>
> This contradicts the global-ness of the admin roles. If I assign
> ('joeuser', 'admin','mytenant') I've just granted them the ability to
> perform all of the admin operations.
I'm afraid I'm not sure I follow. Do you mean all of the admin
operations on resources that are protected only by 'role==admin' ?
Neil
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cross-project] Admin
On 10/19/2015 11:53 AM, Fox, Kevin M wrote:
+1.
I think there may be a slight issue with this and Heat, or any other service
depending on Heat though. It would have to be very carefully through through,
since Heat acts on behalf of the user as the User him/herself would, so scoping
may need to interact differently there, then say Nova. Maybe a flag in the
service catalog saying if the service can be scoped or not?
I think there is a subtlety there you are not making clear. Why would
Heat, or any other service not be scoped? The only rule I am seeing in
Heat's policy would be
|"service:index": "rule:context_is_admin",
||http://git.openstack.org/cgit/openstack/heat/tree/etc/heat/policy.json |
But that certainly suffers from the admin-ess problem. There is
certainly something strange with the deny rules; it is trivial to
bypass this role with a trust. Somethin needs a second look there anyway.
Thanks,
Kevin
From: Adam Young [ayo...@redhat.com]
Sent: Monday, October 19, 2015 6:53 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [cross-project] Admin
While I tend to play up bug 968696 for dramatic effect, the reality is
we have a logical contradiction on what we mean by 'admin' when talking
about RBAC.
In early iterations of OpenStack, roles were global. This is reflected
in many of the Policy checks that only look for the global role.
However, prior to the Keystone-Light rewrite, role assignments became
scoped to tenants. This shows up in the Keystone git history. As this
pattern got established, some people wrote policy checks that assert:
role==admin and tenant_id=resource.tenant_id
This contradicts the global-ness of the admin roles. If I assign
('joeuser', 'admin','mytenant') I've just granted them the ability to
perform all of the admin operations.
Thus, today we have a situation where, unless the user rewrites the
default policy, they have to only assign the role admins to users that
are trusted to be admins on the whole deployment.
We have a few choices.
1. Remove Admin from the scoping for projects. Admin is a special role
reserved only for system admins. Replace project scoped admins with
'manager' or some other comparable role. This is actually the easiest
solution.
2. Create a special project for administrative actions. Cloud admin
users are assigned to this project. Communicate that project Id to the
remote systems. This is what the policy.v3cloudsample.json file
(http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json)
recommends.
However, 2 is really not practical without some significant
engineering. For a new deployment, it would require the following steps.
1) Every single policy file would have to be "templatized"
2) Then deployment mechanism would have to create the admin project, get
the id for it, and string replace it in the policy file.
We could make this happen in Devstack. The same is true of Puppet,
OSAD, and Fuel. There would be a lag and the downstream mechanisms
would eventually pick it up, multiple releases down the road.
I went through this logic back when I started proposing the Dynamic
Policy approach. If OpenStack managed policy deployment via an
inte4rnal mechanism, then adding things like the admin_project_id
becomes trivial.
While I think Dynamic Policy provides a lot of value, I concede that it
is overkill for just substituting in a single value. The real reason I
am backing off Dynamic Policy for the moment is that we need to better
understand what part of policy should be dynamic and what part should be
static; we are just getting that clean now.
There is an additional dimension to the admin_project_id issue that
several developers want solved. In larger deployments, different users
should have administrative capabilities on different endpoints.
Sometimes this is segregated by service (storage admins vs network
admins) and sometimes by region.
Having a special project clearly communicates the intention of RBAC.
But even clearer would be to have the role assignment explicitly on the
catalog item itself. Which of the following statements would you think
is clearer?
1) Assign Joe the admin role on the project designated to administer
endpoint 0816.
2) 1) Assign Joe the admin role on endpoint 0816.
I think you will agree that it is the latter. Making this happen would
not be too difficult on the Keystone side, and would require fairly
simple changes on the policy enforcement of the remote projects. We've
already discussed "endpoint binding of tokens" where an endpoint needs
to know its own ID. Having a new "scope" in a token that is endpoint_id
would be fairly easy to execute.
One project, though, it that all of the client tooling would need to
change. Horizon, openstackclient, and keystoneauth wo
Re: [openstack-dev] [cross-project] Admin
+1.
I think there may be a slight issue with this and Heat, or any other service
depending on Heat though. It would have to be very carefully through through,
since Heat acts on behalf of the user as the User him/herself would, so scoping
may need to interact differently there, then say Nova. Maybe a flag in the
service catalog saying if the service can be scoped or not?
Thanks,
Kevin
From: Adam Young [ayo...@redhat.com]
Sent: Monday, October 19, 2015 6:53 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [cross-project] Admin
While I tend to play up bug 968696 for dramatic effect, the reality is
we have a logical contradiction on what we mean by 'admin' when talking
about RBAC.
In early iterations of OpenStack, roles were global. This is reflected
in many of the Policy checks that only look for the global role.
However, prior to the Keystone-Light rewrite, role assignments became
scoped to tenants. This shows up in the Keystone git history. As this
pattern got established, some people wrote policy checks that assert:
role==admin and tenant_id=resource.tenant_id
This contradicts the global-ness of the admin roles. If I assign
('joeuser', 'admin','mytenant') I've just granted them the ability to
perform all of the admin operations.
Thus, today we have a situation where, unless the user rewrites the
default policy, they have to only assign the role admins to users that
are trusted to be admins on the whole deployment.
We have a few choices.
1. Remove Admin from the scoping for projects. Admin is a special role
reserved only for system admins. Replace project scoped admins with
'manager' or some other comparable role. This is actually the easiest
solution.
2. Create a special project for administrative actions. Cloud admin
users are assigned to this project. Communicate that project Id to the
remote systems. This is what the policy.v3cloudsample.json file
(http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json)
recommends.
However, 2 is really not practical without some significant
engineering. For a new deployment, it would require the following steps.
1) Every single policy file would have to be "templatized"
2) Then deployment mechanism would have to create the admin project, get
the id for it, and string replace it in the policy file.
We could make this happen in Devstack. The same is true of Puppet,
OSAD, and Fuel. There would be a lag and the downstream mechanisms
would eventually pick it up, multiple releases down the road.
I went through this logic back when I started proposing the Dynamic
Policy approach. If OpenStack managed policy deployment via an
inte4rnal mechanism, then adding things like the admin_project_id
becomes trivial.
While I think Dynamic Policy provides a lot of value, I concede that it
is overkill for just substituting in a single value. The real reason I
am backing off Dynamic Policy for the moment is that we need to better
understand what part of policy should be dynamic and what part should be
static; we are just getting that clean now.
There is an additional dimension to the admin_project_id issue that
several developers want solved. In larger deployments, different users
should have administrative capabilities on different endpoints.
Sometimes this is segregated by service (storage admins vs network
admins) and sometimes by region.
Having a special project clearly communicates the intention of RBAC.
But even clearer would be to have the role assignment explicitly on the
catalog item itself. Which of the following statements would you think
is clearer?
1) Assign Joe the admin role on the project designated to administer
endpoint 0816.
2) 1) Assign Joe the admin role on endpoint 0816.
I think you will agree that it is the latter. Making this happen would
not be too difficult on the Keystone side, and would require fairly
simple changes on the policy enforcement of the remote projects. We've
already discussed "endpoint binding of tokens" where an endpoint needs
to know its own ID. Having a new "scope" in a token that is endpoint_id
would be fairly easy to execute.
One project, though, it that all of the client tooling would need to
change. Horizon, openstackclient, and keystoneauth would need to handle
"endpoint" as the scope. This includes third party integrations, which
we do not control.
All of these constraints drive toward a solution where we link the admin
project to the existing endpoint ids.
Make the catalog a separate domain.
Make regions, services, and endpoints projects
Use the rules of Hierarchical Multitenancy to manage the role
assignments for a project.
On the enforcing side, endpoints *must* know their own ID. They would
have checks that assert token.project_id = self.endpoint_id.
This is the "least magic" app
[openstack-dev] [cross-project] Admin
While I tend to play up bug 968696 for dramatic effect, the reality is
we have a logical contradiction on what we mean by 'admin' when talking
about RBAC.
In early iterations of OpenStack, roles were global. This is reflected
in many of the Policy checks that only look for the global role.
However, prior to the Keystone-Light rewrite, role assignments became
scoped to tenants. This shows up in the Keystone git history. As this
pattern got established, some people wrote policy checks that assert:
role==admin and tenant_id=resource.tenant_id
This contradicts the global-ness of the admin roles. If I assign
('joeuser', 'admin','mytenant') I've just granted them the ability to
perform all of the admin operations.
Thus, today we have a situation where, unless the user rewrites the
default policy, they have to only assign the role admins to users that
are trusted to be admins on the whole deployment.
We have a few choices.
1. Remove Admin from the scoping for projects. Admin is a special role
reserved only for system admins. Replace project scoped admins with
'manager' or some other comparable role. This is actually the easiest
solution.
2. Create a special project for administrative actions. Cloud admin
users are assigned to this project. Communicate that project Id to the
remote systems. This is what the policy.v3cloudsample.json file
(http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json)
recommends.
However, 2 is really not practical without some significant
engineering. For a new deployment, it would require the following steps.
1) Every single policy file would have to be "templatized"
2) Then deployment mechanism would have to create the admin project, get
the id for it, and string replace it in the policy file.
We could make this happen in Devstack. The same is true of Puppet,
OSAD, and Fuel. There would be a lag and the downstream mechanisms
would eventually pick it up, multiple releases down the road.
I went through this logic back when I started proposing the Dynamic
Policy approach. If OpenStack managed policy deployment via an
inte4rnal mechanism, then adding things like the admin_project_id
becomes trivial.
While I think Dynamic Policy provides a lot of value, I concede that it
is overkill for just substituting in a single value. The real reason I
am backing off Dynamic Policy for the moment is that we need to better
understand what part of policy should be dynamic and what part should be
static; we are just getting that clean now.
There is an additional dimension to the admin_project_id issue that
several developers want solved. In larger deployments, different users
should have administrative capabilities on different endpoints.
Sometimes this is segregated by service (storage admins vs network
admins) and sometimes by region.
Having a special project clearly communicates the intention of RBAC.
But even clearer would be to have the role assignment explicitly on the
catalog item itself. Which of the following statements would you think
is clearer?
1) Assign Joe the admin role on the project designated to administer
endpoint 0816.
2) 1) Assign Joe the admin role on endpoint 0816.
I think you will agree that it is the latter. Making this happen would
not be too difficult on the Keystone side, and would require fairly
simple changes on the policy enforcement of the remote projects. We've
already discussed "endpoint binding of tokens" where an endpoint needs
to know its own ID. Having a new "scope" in a token that is endpoint_id
would be fairly easy to execute.
One project, though, it that all of the client tooling would need to
change. Horizon, openstackclient, and keystoneauth would need to handle
"endpoint" as the scope. This includes third party integrations, which
we do not control.
All of these constraints drive toward a solution where we link the admin
project to the existing endpoint ids.
Make the catalog a separate domain.
Make regions, services, and endpoints projects
Use the rules of Hierarchical Multitenancy to manage the role
assignments for a project.
On the enforcing side, endpoints *must* know their own ID. They would
have checks that assert token.project_id = self.endpoint_id.
This is the "least magic" approach. It reuses existing abstractions
without radically altering them. The chance of a collision between an
existing project_id and and endpoint_id is vanishingly small\, and could
be addressed by modifying one or the other accordingly. The biggest
effort would be in updating the policy files, but this seems to be
within the capability of cross project efforts.
We will be discussing this at the Cross Project session at the summit
on Global Admin
https://mitakadesignsummit.sched.org/event/51c8f2ea29aa0b63f85e424b0acf9741
Please read this, process it, and be ready to help come to a proper
conclusion of this bug.
Ref
Re: [openstack-dev] [cross-project] "Admin" ness not properly scoped
On 07/24/2015 05:10 AM, Thierry Carrez wrote: Adam Young wrote: [...] There should be no "Global Admin Tokens." They are a security risk, and violate the principal of Least Privilege. https://en.wikipedia.org/wiki/Principle_of_least_privilege. Thanks for taking on this long-standing issue. Should we have some cross-project spec to scope the work needed in the various projects and track overall acceptance of the plan ? Yes, the is appropriate: https://review.openstack.org/#/c/205629/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cross-project] "Admin" ness not properly scoped
Adam Young wrote: > [...] > There should be no "Global Admin Tokens." They are a security risk, > and violate the principal of Least Privilege. > https://en.wikipedia.org/wiki/Principle_of_least_privilege. Thanks for taking on this long-standing issue. Should we have some cross-project spec to scope the work needed in the various projects and track overall acceptance of the plan ? -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cross-project] "Admin" ness not properly scoped
On 07/23/2015 01:11 PM, melanie witt wrote: On Jul 23, 2015, at 7:35, Adam Young wrote: What this means is the if a user is assigned "admin" on any project, they are assigned admin for everything. Fixing this is going to require a change to how we write policy. Each policy rule needs to have two parts: 1. Match the scoped of the token (project for everything that is not Keystone, project or domain for Keystone). 2. Match the role. Thanks for bringing this up. If I understand correctly, you're saying we can fix this by modifying policy.json alone, right? There aren't any code changes required? Unless you need to fetch an object out of the database in order to get its project id, and you are not currently doing that, policy enforcement as currently implemented should be OK. On the quota API, we might acutally need to rethink this; the role that user gets that allows them to set quota should not be on the project itself, but on the containing project. That information might not yet be made available. What makes quota's different than other things like this is that a quota is not something managed *by* the project but instead something external managed *on* the project. So far, for me it has worked fine for "admin" role to grant "admin" everywhere for the system administrators (no one else has "admin" role). But with the prospect of nested quota in nova, I think we would have a new rule for quota update that is, for example: "quota_admin_rule": "role:quota_admin and project_id:%(project_id)s" "admin_or_quota_admin": "role:admin or rule:quota_admin_rule" ordinarily the rule should be something like "quota_admin_rule": "(role:quota_admin or role.admin) and project_id:%(project_id)s" But that means that the user would have the quota_admin on the project itself. That is improperly scoped; if I am an admin on that project, I should not be able to set quota on that project. The rule should be: "quota_admin_rule": " parent.project_id:%(project_id)s and (role:admin or role:quota_admin)", I would prefer: quota_admin_role: "(role:admin or role:quota_admin)" quota_scope: " parent.project_id:%(project_id)s" "compute_extension:quotas:update": "rule:quota_scope and rule:quota_admin_role", Knowing that a deployer should be able to update the role portion, but not the scope "compute_extension:quotas:update": "rule:admin_or_quota_admin", "compute_extension:quotas:delete": "rule:admin_or_quota_admin", "os_compute_api:os-quota-sets:update": "rule:admin_or_quota_admin", "os_compute_api:os-quota-sets:delete": "rule:admin_or_quota_admin", "os_compute_api:os-quota-sets:detail": "rule:admin_or_quota_admin", if I want system administrators and designated quota administrators of a project to be able to update quota. In keystone the quota admins will have the role "quota_admin" only in their projects. Is that an example of the right way to scope "admin" in your view? -melanie (irc: melwitt) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cross-project] "Admin" ness not properly scoped
On Jul 23, 2015, at 7:35, Adam Young wrote: > What this means is the if a user is assigned "admin" on any project, they are > assigned admin for everything. > > Fixing this is going to require a change to how we write policy. > > Each policy rule needs to have two parts: > > 1. Match the scoped of the token (project for everything that is not > Keystone, project or domain for Keystone). > > 2. Match the role. Thanks for bringing this up. If I understand correctly, you're saying we can fix this by modifying policy.json alone, right? There aren't any code changes required? So far, for me it has worked fine for "admin" role to grant "admin" everywhere for the system administrators (no one else has "admin" role). But with the prospect of nested quota in nova, I think we would have a new rule for quota update that is, for example: "quota_admin_rule": "role:quota_admin and project_id:%(project_id)s" "admin_or_quota_admin": "role:admin or rule:quota_admin_rule" "compute_extension:quotas:update": "rule:admin_or_quota_admin", "compute_extension:quotas:delete": "rule:admin_or_quota_admin", "os_compute_api:os-quota-sets:update": "rule:admin_or_quota_admin", "os_compute_api:os-quota-sets:delete": "rule:admin_or_quota_admin", "os_compute_api:os-quota-sets:detail": "rule:admin_or_quota_admin", if I want system administrators and designated quota administrators of a project to be able to update quota. In keystone the quota admins will have the role "quota_admin" only in their projects. Is that an example of the right way to scope "admin" in your view? -melanie (irc: melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [cross-project] "Admin" ness not properly scoped
I a user has an admin role anywhere, they have it everywhere. This is bug https://bugs.launchpad.net/keystone/+bug/968696 and, in order to fix it we are going to have to adjust our thinking on policy checks. Here is the theory: A user is assigned a role on a project. Policy uses the roles assigned in the token to see if the user has access to the object. This breaks down in practice. The policy checks either look for a role OR a project. The role is almost always "Admin" If that fails, then look to see if the user has a project assigned in the token. What this means is the if a user is assigned "admin" on any project, they are assigned admin for everything. Fixing this is going to require a change to how we write policy. Each policy rule needs to have two parts: 1. Match the scoped of the token (project for everything that is not Keystone, project or domain for Keystone). 2. Match the role. Only the second part should ever be changed on a deployment. It is ok to take a rule that is normally executable by A Member and say that it is Admin only. or, if you are so included, define new roles, like Manager, which can perform some operations different than Member or Admin. The first part should not be modified. It is an engineering decision to say "here is where we find the scope in this API. How to find the Scope varies from call to call, and changing that part of the rule is likely to break the policy check. There should be no "Global Admin Tokens." They are a security risk, and violate the principal of Least Privilege. https://en.wikipedia.org/wiki/Principle_of_least_privilege. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
