On Fri, Jun 16, 2017 at 10:09 AM, Kaz Shinohara <ksnhr.t...@gmail.com> 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