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.o...@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.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> > 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> 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> >> 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] >>> *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://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 >> >> >> __________________________________________________________________________ >> 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 > > > __________________________________________________________________________ > 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
