Open Stack

The expire time is determined by keystone. Keystone do not allow users to
change it. So it is impossible to get a token which has no expiry.

On Fri, Aug 14, 2015 at 10:42 AM, Adrian Otto <adrian.otto at rackspace.com>
wrote:

> You can specify the timeout when you create it, so it is possible to make
> one that effectively has no expiry.
>
> --
> Adrian
>
> On Aug 13, 2015, at 7:36 PM, 王华 <wanghua.humble at gmail.com> wrote:
>
> Will the scoped swift trust token time out?
>
> Regards,
> Wanghua
>
> On Fri, Aug 14, 2015 at 10:11 AM, Adrian Otto <adrian.otto at rackspace.com>
> wrote:
>
>> Keystone v3 trusts can be scoped to specific actions. In this case the
>> node needs a valid auth token to use swift. The token can be a trust token.
>> We should generate a trust token scoped to swift for a given user (project)
>> and tenant. It can use a system domain account that has a role that allows
>> it to CRUD objects in a particular swift storage container. Then the
>> registry v2 software can use the swift trust token to access swift, but not
>> other OpenStack services. Depending on the trust enforcement available in
>> swift, it may even be possible to prevent creation of new swift storage
>> containers. We could check to be sure.
>>
>> The scoped swift trust token can be injected into the bay master at
>> creation time using cloud-init.
>>
>> --
>> Adrian
>>
>> On Aug 13, 2015, at 6:46 PM, 王华 <wanghua.humble at gmail.com> wrote:
>>
>> Hi hongbin,
>> I have comments in line.
>>
>> Thank you.
>>
>> Regards,
>> Wanghua
>>
>> On Fri, Aug 14, 2015 at 6:20 AM, Hongbin Lu <hongbin.lu at huawei.com>
>> wrote:
>>
>>> Hi Wanghua,
>>>
>>>
>>>
>>> For the question about how to pass user password to bay nodes, there are
>>> several options here:
>>>
>>> 1.       Directly inject the password to bay nodes via cloud-init. This
>>> might be the simplest solution. I am not sure if it is OK in security
>>> aspect.
>>>
>>> 2.       Inject a scoped Keystone trust to bay nodes and use it to
>>> fetch user password from Barbican (suggested by Adrian).
>>>
>> If we use trust, who we should let user trust?  If we let user trust
>> magnum, then the credential of magnum will occur in vm. I think it is
>> insecure.
>>
>>> 3.       Leverage the solution proposed by Kevin Fox [1]. This might be
>>> a long-term solution.
>>>
>>>
>>>
>>> For the security concerns about storing credential in a config file, I
>>> need clarification. What is the config file? Is it a dokcer registry v2
>>> config file? I guess the credential stored there will be used to talk to
>>> swift. Is that correct? In general, it is
>>>
>> The credential stored in docker registry v2 config file is used to talk
>> to swift.
>>
>>
>>> insecure to store user credential inside a VM, because anyone can take a
>>> snapshot of the VM and boot another VM from the snapshot. Maybe storing a
>>> scoped credential in the config file could mitigate the security risk. Not
>>> sure if there is a better solution.
>>>
>>>
>>>
>>> [1] https://review.openstack.org/#/c/186617/
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Hongbin
>>>
>>>
>>>
>>> *From:* 王华 [mailto:wanghua.humble at gmail.com]
>>> *Sent:* August-13-15 4:06 AM
>>> *To:* OpenStack Development Mailing List (not for usage questions)
>>> *Subject:* [openstack-dev] [magnum]password for registry v2
>>>
>>>
>>>
>>> Hi all,
>>>
>>>
>>>
>>> In order to add registry v2 to bay nodes[1], authentication information
>>> is needed for the registry to upload and download files from swift. The
>>> swift storage-driver in registry now needs the parameters as described in
>>> [2]. User password is needed. How can we get the password?
>>>
>>>
>>>
>>> 1. Let user pass password in baymodel-create.
>>>
>>> 2. Use user token to get password from keystone
>>>
>>>
>>>
>>> Is it suitable to store user password in db?
>>>
>>>
>>>
>>> It may be insecure to store password in db and expose it to user in a
>>> config file even if the password is encrypted. Heat store user password in
>>> db before, and now change to keystone trust[3]. But if we use keystone
>>> trust, the swift storage-driver does not support it. If we use trust, we
>>> expose magnum user's credential in a config file, which is also insecure.
>>>
>>>
>>>
>>> Is there a secure way to implement this bp?
>>>
>>>
>>>
>>> [1] https://blueprints.launchpad.net/magnum/+spec/registryv2-in-master
>>>
>>> [2]
>>> https://github.com/docker/distribution/blob/master/docs/storage-drivers/swift.md
>>>
>>> [3] https://wiki.openstack.org/wiki/Keystone/Trusts
>>>
>>>
>>>
>>> Regards,
>>>
>>> Wanghua
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>
>>
>> __________________________________________________________________________
>> 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
>
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150814/cc8a6ffd/attachment.html>