HI all, On Fri, Jun 16, 2017 at 4:33 PM, Zane Bitter <zbit...@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 <ramis...@redhat.com <mailto: >> 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
