Agree that SERVICE_TOKEN usage eradication will be probably long standing process, but IMO radosgw should follow usual way of managing Openstack service interactions. Usually when service wants to integrate with OpenStack, an appropriate user with role "admin" is created. I believe that for radosgw probably user "radosgw" should be created or something similar. Of course requirement of its "adminess" and role assignment is a different topic.
Regards, Adam On Thu, Jul 30, 2015 at 4:33 PM, Oleksiy Molchanov <omolcha...@mirantis.com> wrote: > Update from Radoslaw Zarzynski > ------- > > Hi, > > I'm afraid that eradication of OS_SERVICE_TOKEN won't be quick > nor painless process due to dependencies. We would need to identify > and fix all applications that requires this auth method. > > For example, Ceph RADOS Gateway (radosgw) currently requires [1] > it in order to provide Keystone integration in its S3 API implementation. > We have customers using that in production. > > Best regards, > Radoslaw Zarzynski > > [1] https://github.com/ceph/ceph/blob/master/src/rgw/rgw_rest_s3.cc#L2222 > > On Wed, Jul 29, 2015 at 6:38 PM, Konstantin Danilov <kdani...@mirantis.com > > wrote: > >> Would send ceph estimation tomorrow. >> Yet estimation != ETTA >> >> On Wed, Jul 29, 2015 at 12:27 AM, Sergii Golovatiuk >> <sgolovat...@mirantis.com> wrote: >> > Hi, >> > >> > Let's ask our Ceph developers how much time/resources they need to >> implement >> > such functionality. >> > >> > -- >> > Best regards, >> > Sergii Golovatiuk, >> > Skype #golserge >> > IRC #holser >> > >> > On Tue, Jul 28, 2015 at 11:21 PM, Andrew Woodward < >> awoodw...@mirantis.com> >> > wrote: >> >> >> >> It's literally how radosgw goes about verifying users, it has no >> scheme of >> >> using a user or working with auth-tokens. It would have to fixed in the >> >> ceph-radosgw codebase. PKI tokens (which we don't use) rely on this >> less, >> >> but its still used. >> >> >> >> On Tue, Jul 28, 2015 at 2:16 PM Sergii Golovatiuk >> >> <sgolovat...@mirantis.com> wrote: >> >>> >> >>> Why can't radosgw use own own credentials? If it's technical debt we >> need >> >>> to put it on plate to address in next release. >> >>> >> >>> >> >>> -- >> >>> Best regards, >> >>> Sergii Golovatiuk, >> >>> Skype #golserge >> >>> IRC #holser >> >>> >> >>> On Tue, Jul 28, 2015 at 10:21 PM, Andrew Woodward <xar...@gmail.com> >> >>> wrote: >> >>>> >> >>>> Keystone authtoken is also used by radosgw to validate users >> >>>> >> >>>> On Tue, Jul 28, 2015 at 10:31 AM Andrew Woodward >> >>>> <awoodw...@mirantis.com> wrote: >> >>>>> >> >>>>> IIRC the puppet modules, and even the heat domain create script make >> >>>>> use of the token straight from the config file. It not being >> present could >> >>>>> cause problems for some of the manifests. We would need to ensure >> that their >> >>>>> usage is minimized or removed. >> >>>>> >> >>>>> On Tue, Jul 28, 2015 at 9:29 AM Sergii Golovatiuk >> >>>>> <sgolovat...@mirantis.com> wrote: >> >>>>>> >> >>>>>> Hi Oleksiy, >> >>>>>> >> >>>>>> Good catch. Also OSTF should get endpoints from hiera as some >> plugins >> >>>>>> may override the initial deployment settings. There may be cases >> when >> >>>>>> keystone is detached by plugin. >> >>>>>> >> >>>>>> -- >> >>>>>> Best regards, >> >>>>>> Sergii Golovatiuk, >> >>>>>> Skype #golserge >> >>>>>> IRC #holser >> >>>>>> >> >>>>>> On Tue, Jul 28, 2015 at 5:26 PM, Oleksiy Molchanov >> >>>>>> <omolcha...@mirantis.com> wrote: >> >>>>>>> >> >>>>>>> Hello all, >> >>>>>>> >> >>>>>>> We need to discuss removal of OS_SERVICE_TOKEN usage in Fuel after >> >>>>>>> deployment. This came from >> https://bugs.launchpad.net/fuel/+bug/1430619. I >> >>>>>>> guess not all of us have an access to this bug, so to be short: >> >>>>>>> >> >>>>>>> # A "shared secret" that can be used to bootstrap Keystone. >> >>>>>>> # This "token" does not represent a user, and carries no >> >>>>>>> # explicit authorization. To disable in production (highly >> >>>>>>> # recommended), remove AdminTokenAuthMiddleware from your >> >>>>>>> # paste application pipelines (for example, in keystone- >> >>>>>>> # paste.ini). (string value) >> >>>>>>> >> >>>>>>> After removing this and testing we found out that OSTF fails >> because >> >>>>>>> it uses admin token. >> >>>>>>> >> >>>>>>> What do you think if we create ostf user like for workloads, but >> with >> >>>>>>> wider permissions? >> >>>>>>> >> >>>>>>> BR, >> >>>>>>> Oleksiy. >> >>>>>>> >> >>>>>>> >> >>>>>>> >> __________________________________________________________________________ >> >>>>>>> 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 >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> __________________________________________________________________________ >> >>>>>> 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 >> >>>>> >> >>>>> -- >> >>>>> -- >> >>>>> Andrew Woodward >> >>>>> Mirantis >> >>>>> Fuel Community Ambassador >> >>>>> Ceph Community >> >>>>> >> >>>>> >> __________________________________________________________________________ >> >>>>> 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 >> >>>> >> >>>> -- >> >>>> >> >>>> -- >> >>>> >> >>>> Andrew Woodward >> >>>> >> >>>> Mirantis >> >>>> >> >>>> Fuel Community Ambassador >> >>>> >> >>>> Ceph Community >> >>>> >> >>>> >> >>>> >> >>>> >> __________________________________________________________________________ >> >>>> 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 >> >>>> >> >>> >> >>> >> >>> >> __________________________________________________________________________ >> >>> 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 >> >> >> >> -- >> >> -- >> >> Andrew Woodward >> >> Mirantis >> >> Fuel Community Ambassador >> >> Ceph Community >> >> >> >> >> __________________________________________________________________________ >> >> 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 >> >> >> > >> > >> > >> __________________________________________________________________________ >> > 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 >> > >> >> >> >> -- >> Kostiantyn Danilov aka koder.ua >> Principal software engineer, Mirantis >> >> skype:koder.ua >> http://koder-ua.blogspot.com/ >> http://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 >> > > > __________________________________________________________________________ > 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc.
__________________________________________________________________________ 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
