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
