Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170616/58cf425e/attachment.html>