[heat] Deprecate/Remove deferred_auth_method=password config option

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[heat] Deprecate/Remove deferred_auth_method=password config option

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?

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [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 <[hidden email]>:
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?

__________________________________________________________________________
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: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [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 <[hidden email]
> <mailto:[hidden email]>>:

[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: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Pavlo Shchelokovskyy
HI all,

On Fri, Jun 16, 2017 at 4:33 PM, Zane Bitter <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>>:

[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.



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-request@...enstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Cheers,
--
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [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 <[hidden email]>:

> HI all,
>
> On Fri, Jun 16, 2017 at 4:33 PM, Zane Bitter <[hidden email]> 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 <[hidden email]
>>> <mailto:[hidden email]>>:
>>
>>
>> [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: [hidden email]?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: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Rabi Mishra
In reply to this post by Zane Bitter
On Fri, Jun 16, 2017 at 7:03 PM, Zane Bitter <[hidden email]> 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-request@...enstack.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: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Steven Hardy
In reply to this post by Kaz Shinohara
On Fri, Jun 16, 2017 at 10:09 AM, Kaz Shinohara <[hidden email]> 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: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Loading...