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.hum...@gmail.com<mailto:wanghua.hum...@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.o...@rackspace.com<mailto:adrian.o...@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.hum...@gmail.com<mailto:wanghua.hum...@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...@huawei.com<mailto:hongbin...@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.hum...@gmail.com<mailto:wanghua.hum...@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-requ...@lists.openstack.org?subject:unsubscribe<http://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<mailto: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://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<mailto: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
