Open Stack

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 <pshchelokovskyy at mirantis.com>:
> HI all,
>
> On Fri, Jun 16, 2017 at 4:33 PM, Zane Bitter <zbitter at redhat.com> 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 <ramishra at redhat.com
>>> <mailto:ramishra at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>