Open Stack

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 <omolchanov at 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 <kdanilov at mirantis.com
> > wrote:
>
>> Would send ceph estimation tomorrow.
>> Yet estimation != ETTA
>>
>> On Wed, Jul 29, 2015 at 12:27 AM, Sergii Golovatiuk
>> <sgolovatiuk at 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 <
>> awoodward at 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
>> >> <sgolovatiuk at 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 <xarses at gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> Keystone authtoken is also used by radosgw to validate users
>> >>>>
>> >>>> On Tue, Jul 28, 2015 at 10:31 AM Andrew Woodward
>> >>>> <awoodward at 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
>> >>>>> <sgolovatiuk at 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
>> >>>>>> <omolchanov at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Adam Heczko
Security Engineer @ Mirantis Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150803/fcba6276/attachment.html>