Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150814/d935b5ac/attachment.html>