Re: [openstack-dev] [magnum][heat] Global stack-list for Magnum service user

[Fox, Kevin M]

+1.  Id like to see a similar thing for keystone validate user tokens.

Thanks,
Kevin


From: Johannes Grassler
Sent: Monday, July 04, 2016 2:43:47 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [magnum][heat] Global stack-list for Magnum service 
user

Hello,

Magnum has a periodic task that checks the state of the Heat stacks it creates
for its bays. It does this across all users/tenants that have Magnum bays.
Currently it uses a global stack-list operation to query these Heat stacks:

https://github.com/openstack/magnum/blob/master/magnum/service/periodic.py#L83

Now the Magnum service user does not normally have permission to perform this 
operation,
hence the Magnum documentation currently suggests the following change to
Heat's policy.json:

| stacks:global_index: "role:admin",

This is less than optimal since it allows any tenant's admin user to perform a
global stack-list. Would it be an option to have something like this in Heat's
default policy.json?

| stacks:global_index: "role:service",

That way the global stack-list would be restricted to service users and seting
Magnum (or other services that use Heat internally) wouldn't need a change to
Heat's policy.json.

If that kind of approach is feasible I'd be happy to submit a change.

Cheers,

Johannes

--
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smithard, Graham Norton
Maxfeldstr. 5, 90409 Nürnberg, Germany

__
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] [magnum][heat] Global stack-list for Magnum service user

[Johannes Grassler]

Hello,

Thanks for the exhaustive comment on the issue. Won't help much in the short
term, but it's good to see there will eventually be a way to sort this out
properly!

On 07/04/2016 12:50 PM, Steven Hardy wrote:

On Mon, Jul 04, 2016 at 11:43:47AM +0200, Johannes Grassler wrote:

[Magnum's global stack-list versus Heat's policy.json]


Yes, this sort of problem is the reason we disabled global_index by
default[1] - because of the somewhat notorious keystone bug #968696[2], we
could not create a default rule which correctly communicated that this
should be a cloud-admin only action.

So, instead of creating an insecure-by-default rule, we disabled it for
everybody, so that deployers could make an explicit choice about how to
enable access to this potentially sensitive API.


Ok, that's fair enough.


| stacks:global_index: "role:service",

[...]

I don't think this is feasible, because it implies a level of admin-ness
for service users that I think isn't desirable (even it if may be the
status-quo, I don't personally think trusting all services to have global
access to heat by default is a good model from a security isolation
perspective).


Yes...also, it just shifts the problem as Pavlo pointed out: an admin user can
just assign themselves the 'service' role in their own tenant. So that's no
advantage over using role:admin :-)
 
[...]



So, in summary, I think we should fix our integration with the new keystone
is_admin_project stuff, then potentially switch the global_index to use the
is_admin rule as defined by our policy.json.


Indeed, that sounds a lot better.


Then, you'd just need to add the magnum service user to whatever project is
defined in keystone as being the admin project, but it would not require
exposing this API to every other service by default.

Hope that helps!


Definitely does, thanks!

Cheers,

Johannes

--
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smithard, Graham Norton
Maxfeldstr. 5, 90409 Nürnberg, Germany

__
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] [magnum][heat] Global stack-list for Magnum service user

[Steven Hardy]

On Mon, Jul 04, 2016 at 11:43:47AM +0200, Johannes Grassler wrote:
> Hello,
> 
> Magnum has a periodic task that checks the state of the Heat stacks it creates
> for its bays. It does this across all users/tenants that have Magnum bays.
> Currently it uses a global stack-list operation to query these Heat stacks:
> 
> https://github.com/openstack/magnum/blob/master/magnum/service/periodic.py#L83
> 
> Now the Magnum service user does not normally have permission to perform this 
> operation,
> hence the Magnum documentation currently suggests the following change to
> Heat's policy.json:
> 
> | stacks:global_index: "role:admin",
> 
> This is less than optimal since it allows any tenant's admin user to perform a
> global stack-list. Would it be an option to have something like this in Heat's
> default policy.json?

Yes, this sort of problem is the reason we disabled global_index by
default[1] - because of the somewhat notorious keystone bug #968696[2], we
could not create a default rule which correctly communicated that this
should be a cloud-admin only action.

So, instead of creating an insecure-by-default rule, we disabled it for
everybody, so that deployers could make an explicit choice about how to
enable access to this potentially sensitive API.

> | stacks:global_index: "role:service",
> 
> That way the global stack-list would be restricted to service users and seting
> Magnum (or other services that use Heat internally) wouldn't need a change to
> Heat's policy.json.
> 
> If that kind of approach is feasible I'd be happy to submit a change.

I don't think this is feasible, because it implies a level of admin-ness
for service users that I think isn't desirable (even it if may be the
status-quo, I don't personally think trusting all services to have global
access to heat by default is a good model from a security isolation
perspective).

This topic was discussed[3] recently in the context of another RFE bug[4] that
wanted additional global-admin capabilities, and the outcome of that
discussion was a reccomendation that we use the new "is_admin_project"
capability added to keystone[5] in order to fix bug #968696.

The net result of this is a redefinition of "is_admin" in our context to
look like:

"role:admin and auth_token_info.token.is_admin_project:True",

However ref https://review.openstack.org/#/c/08/ there are problems
with backwards compatibility when accessing this directly from the
token_info, so we need https://review.openstack.org/#/c/331916/ which will
enable access of this attribute in a backwards compatible way.

I assume the net result will be that anyone not configuring an admin
project in keystone will get the old buggy #968696 behaviour, but at least
then we won't have codified any assumptions around admin scope inside heat,
and that access can be controlled centrally for all services via keystone
in a consistent way.

So, in summary, I think we should fix our integration with the new keystone
is_admin_project stuff, then potentially switch the global_index to use the
is_admin rule as defined by our policy.json.

Then, you'd just need to add the magnum service user to whatever project is
defined in keystone as being the admin project, but it would not require
exposing this API to every other service by default.

Hope that helps!

Steve

[1] https://github.com/openstack/heat/blob/master/etc/heat/policy.json#L47
[2] https://bugs.launchpad.net/keystone/+bug/968696
[3] http://lists.openstack.org/pipermail/openstack-dev/2015-November/079006.html
[4] https://bugs.launchpad.net/heat/+bug/1466694
[5] https://review.openstack.org/#/c/240719/

__
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] [magnum][heat] Global stack-list for Magnum service user

[Pavlo Shchelokovskyy]

Hi Johannes,

this is still not too optimal, as AFAIK admin role is still global, so
admin in tenant also means admin of whole OpenStack, thus it still can
assign himself/whomever the 'service' role and get access to global stack
list.

Best solution would probably be to create a separate domain in Keystone,
and a service user in it, and check in policy json the actual
domain+tenant+some role or username in this tenant. This domain and tenant
are completely controlled by Magnum service then (creds are in the magnum
config) - all similar to how Heat is working.

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Mon, Jul 4, 2016 at 12:43 PM, Johannes Grassler 
wrote:

> Hello,
>
> Magnum has a periodic task that checks the state of the Heat stacks it
> creates
> for its bays. It does this across all users/tenants that have Magnum bays.
> Currently it uses a global stack-list operation to query these Heat stacks:
>
>
> https://github.com/openstack/magnum/blob/master/magnum/service/periodic.py#L83
>
> Now the Magnum service user does not normally have permission to perform
> this operation,
> hence the Magnum documentation currently suggests the following change to
> Heat's policy.json:
>
> | stacks:global_index: "role:admin",
>
> This is less than optimal since it allows any tenant's admin user to
> perform a
> global stack-list. Would it be an option to have something like this in
> Heat's
> default policy.json?
>
> | stacks:global_index: "role:service",
>
> That way the global stack-list would be restricted to service users and
> seting
> Magnum (or other services that use Heat internally) wouldn't need a change
> to
> Heat's policy.json.
>
> If that kind of approach is feasible I'd be happy to submit a change.
>
> Cheers,
>
> Johannes
>
> --
> Johannes Grassler, Cloud Developer
> SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> Maxfeldstr. 5, 90409 Nürnberg, Germany
>
> __
> 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

[openstack-dev] [magnum][heat] Global stack-list for Magnum service user

[Johannes Grassler]

Hello,

Magnum has a periodic task that checks the state of the Heat stacks it creates
for its bays. It does this across all users/tenants that have Magnum bays.
Currently it uses a global stack-list operation to query these Heat stacks:

https://github.com/openstack/magnum/blob/master/magnum/service/periodic.py#L83

Now the Magnum service user does not normally have permission to perform this 
operation,
hence the Magnum documentation currently suggests the following change to
Heat's policy.json:

| stacks:global_index: "role:admin",

This is less than optimal since it allows any tenant's admin user to perform a
global stack-list. Would it be an option to have something like this in Heat's
default policy.json?

| stacks:global_index: "role:service",

That way the global stack-list would be restricted to service users and seting
Magnum (or other services that use Heat internally) wouldn't need a change to
Heat's policy.json.

If that kind of approach is feasible I'd be happy to submit a change.

Cheers,

Johannes

--
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smithard, Graham Norton
Maxfeldstr. 5, 90409 Nürnberg, Germany

__
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