Re: [openstack-dev] [heat] Deprecate/Remove deferred_auth_method=password config option

[Steven Hardy]

On Thu, Jun 29, 2017 at 4:13 AM, Kaz Shinohara  wrote:
> Hi,
>
>> No, I think we still need this, because it is disabled by default -
>> this option allows you to enable defeating token expiry via trusts,
> My understanding for the current implementation is..
> `deferred_auth_method=trust` triggers getting trust_id and storing it in the 
> db.
> `reauthentication_method=trust` triggers getting trust scoped token by
> taking the trust id(Allow reauthentication)
> Those looks somehow duplicated because trust_id is required only when
> you want to get the trust scoped token, it's ok for heat to get
> trust_id when he need to get trust scoped token, isn't it ?

No they are two different uses for the trust_id;

1. reauthentication_method unset (default) - we can get a trust scoped
token for deferred operations such as autoscaling, but we cannot
defeat the token expiry set by keystone by reauthenticating.

2. reauthentication_method=trusts - we can get a trust scoped token
for any operation (including those initiated by a user with a real not
trust scoped token), such that the token expiry set by keystone can be
defeated.

(2) is not a safe default, but it's useful for certain use-cases such
as TripleO where stack operations can take many hours.

> In case of removing the password authentication, why don't we remove
> `deferred_auth_method` from heat.conf and unify
> 'reauthentication_method' to triggers getting trust_id and getting
> trust scoped token.

Yes as I said before, we could remove deferred_auth_method but we
cannot remove reauthentication_method.

HTH,

Steve

__
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] [heat] Deprecate/Remove deferred_auth_method=password config option

[Kaz Shinohara]

Hi,

> No, I think we still need this, because it is disabled by default -
> this option allows you to enable defeating token expiry via trusts,
My understanding for the current implementation is..
`deferred_auth_method=trust` triggers getting trust_id and storing it in the db.
`reauthentication_method=trust` triggers getting trust scoped token by
taking the trust id(Allow reauthentication)
Those looks somehow duplicated because trust_id is required only when
you want to get the trust scoped token, it's ok for heat to get
trust_id when he need to get trust scoped token, isn't it ?

In case of removing the password authentication, why don't we remove
`deferred_auth_method` from heat.conf and unify
'reauthentication_method' to triggers getting trust_id and getting
trust scoped token.

Cheers,
Kaz

2017-06-21 16:51 GMT+09:00 Steven Hardy :
> On Fri, Jun 16, 2017 at 10:09 AM, Kaz Shinohara  wrote:
>> Hi Rabi,
>>
>>
>> I still takes `deferred _auth_method=password` behalf of trusts because we
>> don't enable trusts in the Keystone side due to some internal reason.
>> The issues what you pointed are correct(e.g. user_domain_id), we don't use
>> the domain well and also added some patches to skip those issues.
>> But I guess that the majority of heat users already moved to trusts and it
>> is obviously better solution in terms of security and granular role control.
>> As the edge case(perhaps), if a user want to take password auth, it would be
>> too tricky for them to introduce it, therefore I agree your 2nd option.
>>
>> If we will remove the `deferred_auth_method=password` from heat.conf,
>> should we keep `deferred_auth_method` self or will replace it to a new
>> config option just to specify the trusts enable/disable ?  Do you have any
>> idea on this?
>
> I don't think it makes sense to have an enable/disable trusts config
> option unless there is an alternative (e.g we've discussed oauth in
> the past and in future there may be alternatives to trusts).
>
> I guess if there was sufficient interest we could have some option
> that blacklists all resources that require deferred authentication,
> but I'm not sure folks are actually asking for that right now?
>
> My preference is to deprecate deferred_auth_method, since right now
> there's not really any alternative that works for us.
>
>> Also I'm thinking that `reauthentication_method` also might be
>> changed/merged ?
>
> No, I think we still need this, because it is disabled by default -
> this option allows you to enable defeating token expiry via trusts,
> which is something an operator must opt-in to IMO (we should not
> enable this by default, as it's really only intended for certain edge
> cases such as TripleO where there are often very long running stack
> operations that may exceed the keystone token expiry).
>
> Steve
>
> __
> 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] [heat] Deprecate/Remove deferred_auth_method=password config option

[Steven Hardy]

On Fri, Jun 16, 2017 at 10:09 AM, Kaz Shinohara  wrote:
> Hi Rabi,
>
>
> I still takes `deferred _auth_method=password` behalf of trusts because we
> don't enable trusts in the Keystone side due to some internal reason.
> The issues what you pointed are correct(e.g. user_domain_id), we don't use
> the domain well and also added some patches to skip those issues.
> But I guess that the majority of heat users already moved to trusts and it
> is obviously better solution in terms of security and granular role control.
> As the edge case(perhaps), if a user want to take password auth, it would be
> too tricky for them to introduce it, therefore I agree your 2nd option.
>
> If we will remove the `deferred_auth_method=password` from heat.conf,
> should we keep `deferred_auth_method` self or will replace it to a new
> config option just to specify the trusts enable/disable ?  Do you have any
> idea on this?

I don't think it makes sense to have an enable/disable trusts config
option unless there is an alternative (e.g we've discussed oauth in
the past and in future there may be alternatives to trusts).

I guess if there was sufficient interest we could have some option
that blacklists all resources that require deferred authentication,
but I'm not sure folks are actually asking for that right now?

My preference is to deprecate deferred_auth_method, since right now
there's not really any alternative that works for us.

> Also I'm thinking that `reauthentication_method` also might be
> changed/merged ?

No, I think we still need this, because it is disabled by default -
this option allows you to enable defeating token expiry via trusts,
which is something an operator must opt-in to IMO (we should not
enable this by default, as it's really only intended for certain edge
cases such as TripleO where there are often very long running stack
operations that may exceed the keystone token expiry).

Steve

__
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] [heat] Deprecate/Remove deferred_auth_method=password config option

[Rabi Mishra]

On Fri, Jun 16, 2017 at 7:03 PM, Zane Bitter  wrote:
[snip]

>
> I'm not sure whether this works with keystone v2 and anyone is using
>> it or not. Keeping in mind that heat-cli is deprecated and keystone
>> v3 is now the default, we've 2 options
>>
>> 1. Continue to support 'deferred_auth_method=passsword' option and
>> fix all the above issues.
>>
>> 2. Remove/deprecate the option in pike itlsef.
>>
>> I would prefer option 2, but probably I miss some history and use
>> cases for it.
>>
>
> Am I right in thinking that any user (i.e. not just the [heat] service
> user) can create a trust? I still see occasional requests about 'standalone
> mode' for clouds that don't have Heat available to users (which I suspect
> is broken, otherwise people wouldn't be asking), and I'm guessing that
> standalone mode has heretofore required deferred_auth_method=password.
>

I think standalone heat is broken in more than one way based on my testing.
It seems changes have not kept up with heat standalone as 'authpassword'
middleware is broken[1] and we don't seem to pass correct domain details in
the rpc context.  I've tried to fix them in[2].

I'm also not sure why heat standalone historically restricts
deferred_auth_method to 'password'[3]. It seems to work well with 'trusts'
though.


[1]  https://bugs.launchpad.net/heat/+bug/1699418
[2]  https://review.openstack.org/#/c/476014/
[3]  https://github.com/openstack/heat/blob/master/devstack/lib/heat#L74


> So if we're going to remove the option then we should probably either
> officially disown standalone mode or rewrite the instructions such that it
> can be used with the trusts method.
>
> I think disowning the standalone mode would be an easier option. Probably
we should rewrite the instructions for it to be used with 'trusts' method
as it seems to work, unless I miss something. However, without any testing
at the gate we would surely break it from time to time.


> cheers,
> Zane.
>
>
> __
> 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
>



-- 
Regards,
Rabi Mishra
__
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] [heat] Deprecate/Remove deferred_auth_method=password config option

[Kaz Shinohara]

Hi team,


>> Free advice: whatever reason you have for not enabling trusts, storing
>> user passwords in the Heat database is 100x worse.
Thank you, your point sounds reasonable.
Of course we don't like to store our customer's credentials in Heat
DB, event though those are encrypted.
This is one of the reason why I agree Rabi's option2.
We are seriously thinking to change it  to the trusts now.


>> Why aren't those upstream?
One of them already in review as Rabi attached.  My colleague raised :)
https://review.openstack.org/435213
If the discussion here will have a conclusion to keep the password auth,
it's pleasure for us to have any further contribution on this point.

Regards,
Kaz

2017-06-17 0:19 GMT+09:00 Pavlo Shchelokovskyy :
> HI all,
>
> On Fri, Jun 16, 2017 at 4:33 PM, Zane Bitter  wrote:
>>
>> On 16/06/17 05:09, Kaz Shinohara wrote:
>>>
>>> I still takes `deferred _auth_method=password` behalf of trusts because
>>> we don't enable trusts in the Keystone side due to some internal reason.
>>
>>
>> Free advice: whatever reason you have for not enabling trusts, storing
>> user passwords in the Heat database is 100x worse.
>>
>>> The issues what you pointed are correct(e.g. user_domain_id), we don't
>>> use the domain well and also added some patches to skip those issues.
>>
>>
>> Why aren't those upstream?
>>
>>> But I guess that the majority of heat users already moved to trusts and
>>> it is obviously better solution in terms of security and granular role
>>> control.
>>> As the edge case(perhaps), if a user want to take password auth, it would
>>> be too tricky for them to introduce it, therefore I agree your 2nd option.
>>>
>>> If we will remove the `deferred_auth_method=password` from heat.conf,
>>> should we keep `deferred_auth_method` self or will replace it to a new
>>> config option just to specify the trusts enable/disable ?  Do you have any
>>> idea on this?
>>> Also I'm thinking that `reauthentication_method` also might be
>>> changed/merged ?
>>>
>>> Regards,
>>> Kaz Shinohara
>>>
>>>
>>> 2017-06-16 14:11 GMT+09:00 Rabi Mishra >> >:
>>
>>
>> [snip]
>>
>>> I'm not sure whether this works with keystone v2 and anyone is using
>>> it or not. Keeping in mind that heat-cli is deprecated and keystone
>>> v3 is now the default, we've 2 options
>>>
>>> 1. Continue to support 'deferred_auth_method=passsword' option and
>>> fix all the above issues.
>>>
>>> 2. Remove/deprecate the option in pike itlsef.
>>>
>>> I would prefer option 2, but probably I miss some history and use
>>> cases for it.
>>
>>
>> Am I right in thinking that any user (i.e. not just the [heat] service
>> user) can create a trust? I still see occasional requests about 'standalone
>> mode' for clouds that don't have Heat available to users (which I suspect is
>> broken, otherwise people wouldn't be asking), and I'm guessing that
>> standalone mode has heretofore required deferred_auth_method=password.
>
>
> When trusts are enabled, generally any user can create a trust to any other
> user, but only with itself as trustor  - there's a strict rule for that in
> default keystone policy.json [0]. The only other reason that might block
> this is when the user is already a trustee, and trust chaining is disabled
> or already exhausted for this trustee. A tiny problem might be that it seems
> you need to know both the user_id/project_id of trustor (can be resolved by
> trustor itself) and the user_id of trustee - which is generally impossible
> for non-admin users, so a trustee must give the trustor its id.
>
> [0]
> http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json#n138
>
>>
>> So if we're going to remove the option then we should probably either
>> officially disown standalone mode or rewrite the instructions such that it
>> can be used with the trusts method.
>>
>> cheers,
>> Zane.
>>
>>
>> __
>> 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
>
>
>
> Cheers,
> --
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.mirantis.com
>
> __
> 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] [heat] Deprecate/Remove deferred_auth_method=password config option

[Pavlo Shchelokovskyy]

HI all,

On Fri, Jun 16, 2017 at 4:33 PM, Zane Bitter  wrote:

> On 16/06/17 05:09, Kaz Shinohara wrote:
>
>> I still takes `deferred _auth_method=password` behalf of trusts because
>> we don't enable trusts in the Keystone side due to some internal reason.
>>
>
> Free advice: whatever reason you have for not enabling trusts, storing
> user passwords in the Heat database is 100x worse.
>
> The issues what you pointed are correct(e.g. user_domain_id), we don't use
>> the domain well and also added some patches to skip those issues.
>>
>
> Why aren't those upstream?
>
> But I guess that the majority of heat users already moved to trusts and it
>> is obviously better solution in terms of security and granular role control.
>> As the edge case(perhaps), if a user want to take password auth, it would
>> be too tricky for them to introduce it, therefore I agree your 2nd option.
>>
>> If we will remove the `deferred_auth_method=password` from heat.conf,
>> should we keep `deferred_auth_method` self or will replace it to a new
>> config option just to specify the trusts enable/disable ?  Do you have any
>> idea on this?
>> Also I'm thinking that `reauthentication_method` also might be
>> changed/merged ?
>>
>> Regards,
>> Kaz Shinohara
>>
>>
>> 2017-06-16 14:11 GMT+09:00 Rabi Mishra > ramis...@redhat.com>>:
>>
>
> [snip]
>
> I'm not sure whether this works with keystone v2 and anyone is using
>> it or not. Keeping in mind that heat-cli is deprecated and keystone
>> v3 is now the default, we've 2 options
>>
>> 1. Continue to support 'deferred_auth_method=passsword' option and
>> fix all the above issues.
>>
>> 2. Remove/deprecate the option in pike itlsef.
>>
>> I would prefer option 2, but probably I miss some history and use
>> cases for it.
>>
>
> Am I right in thinking that any user (i.e. not just the [heat] service
> user) can create a trust? I still see occasional requests about 'standalone
> mode' for clouds that don't have Heat available to users (which I suspect
> is broken, otherwise people wouldn't be asking), and I'm guessing that
> standalone mode has heretofore required deferred_auth_method=password.
>

When trusts are enabled, generally any user can create a trust to any other
user, but only with itself as trustor  - there's a strict rule for that in
default keystone policy.json [0]. The only other reason that might block
this is when the user is already a trustee, and trust chaining is disabled
or already exhausted for this trustee. A tiny problem might be that it
seems you need to know both the user_id/project_id of trustor (can be
resolved by trustor itself) and the user_id of trustee - which is generally
impossible for non-admin users, so a trustee must give the trustor its id.

[0]
http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json#n138


> So if we're going to remove the option then we should probably either
> officially disown standalone mode or rewrite the instructions such that it
> can be used with the trusts method.
>
> cheers,
> Zane.
>
>
> __
> 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
>


Cheers,
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
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] [heat] Deprecate/Remove deferred_auth_method=password config option

[Zane Bitter]

On 16/06/17 05:09, Kaz Shinohara wrote:
I still takes `deferred _auth_method=password` behalf of trusts because 
we don't enable trusts in the Keystone side due to some internal reason.


Free advice: whatever reason you have for not enabling trusts, storing 
user passwords in the Heat database is 100x worse.


The issues what you pointed are correct(e.g. user_domain_id), we don't 
use the domain well and also added some patches to skip those issues.


Why aren't those upstream?

But I guess that the majority of heat users already moved to trusts and 
it is obviously better solution in terms of security and granular role 
control.
As the edge case(perhaps), if a user want to take password auth, it 
would be too tricky for them to introduce it, therefore I agree your 2nd 
option.


If we will remove the `deferred_auth_method=password` from heat.conf,  
should we keep `deferred_auth_method` self or will replace it to a new 
config option just to specify the trusts enable/disable ?  Do you have 
any idea on this?
Also I'm thinking that `reauthentication_method` also might be 
changed/merged ?


Regards,
Kaz Shinohara


2017-06-16 14:11 GMT+09:00 Rabi Mishra >:


[snip]


I'm not sure whether this works with keystone v2 and anyone is using
it or not. Keeping in mind that heat-cli is deprecated and keystone
v3 is now the default, we've 2 options

1. Continue to support 'deferred_auth_method=passsword' option and
fix all the above issues.

2. Remove/deprecate the option in pike itlsef.

I would prefer option 2, but probably I miss some history and use
cases for it.


Am I right in thinking that any user (i.e. not just the [heat] service 
user) can create a trust? I still see occasional requests about 
'standalone mode' for clouds that don't have Heat available to users 
(which I suspect is broken, otherwise people wouldn't be asking), and 
I'm guessing that standalone mode has heretofore required 
deferred_auth_method=password.


So if we're going to remove the option then we should probably either 
officially disown standalone mode or rewrite the instructions such that 
it can be used with the trusts method.


cheers,
Zane.

__
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] [heat] Deprecate/Remove deferred_auth_method=password config option

[Kaz Shinohara]

Hi Rabi,


I still takes `deferred _auth_method=password` behalf of trusts because we
don't enable trusts in the Keystone side due to some internal reason.
The issues what you pointed are correct(e.g. user_domain_id), we don't use
the domain well and also added some patches to skip those issues.
But I guess that the majority of heat users already moved to trusts and it
is obviously better solution in terms of security and granular role
control.
As the edge case(perhaps), if a user want to take password auth, it would
be too tricky for them to introduce it, therefore I agree your 2nd option.

If we will remove the `deferred_auth_method=password` from heat.conf,
should we keep `deferred_auth_method` self or will replace it to a new
config option just to specify the trusts enable/disable ?  Do you have any
idea on this?
Also I'm thinking that `reauthentication_method` also might be
changed/merged ?

Regards,
Kaz Shinohara


2017-06-16 14:11 GMT+09:00 Rabi Mishra :

> Hi All,
>
> As we know,  'deferred_auth_method=trusts' being the default, we use
> trust_auth_plugin whenever a resource requires deferred_auth (any resource
> derived from SignalResponder and StackResource). We also support
> 'deferred_auth_method=password' where  'X-Auth-User'/username and
> 'X-Auth-Key'/password is passed in the request header and we then store
> them in 'user_creds' (rather than 'trust_id')  to create a 'password'
> auth_plugin when loading the stack with stored context for signalling. I
> assume for this very reason we've the '--include-pass' option in heat cli.
>
> However, when using keystone session(which is the default), we don't have
> the above implemented with SessionClient (i.e to pass the headers). There
> is a bug[1] and patch[2]  to add this to SessionClient in the review queue.
> Aslo, we don't have anything like '--include-pass' for osc.
>
> I've noticed that 'deferred_auth_method=password' is broken and does not
> work with keystone v3 at all. As we don't store the 'user_domain_id/name'
> in 'user_creds', we can not even intialize the 'password' auth_plugin when
> creating the StoredContext, as it would not be able to authenticate the
> user without the user_domain[3].
>
> I'm not sure whether this works with keystone v2 and anyone is using it or
> not. Keeping in mind that heat-cli is deprecated and keystone v3 is now the
> default, we've 2 options
>
> 1. Continue to support 'deferred_auth_method=passsword' option and fix
> all the above issues.
>
> 2. Remove/deprecate the option in pike itlsef.
>
> I would prefer option 2, but probably I miss some history and use cases
> for it.
>
> Thoughts?
>
>
> [1] https://bugs.launchpad.net/python-heatclient/+bug/1665321
>
> [2] https://review.openstack.org/435213
>
> [3] https://github.com/openstack/heat/blob/master/heat/common/
> context.py#L292
>
> --
> Regards,
> Rabi Mishra
>
>
> __
> 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