Hi Adrian, Barbican looks good for this purpose. I will do a prototype with it.
Thanks Georgy On Fri, Jan 17, 2014 at 11:43 AM, Adrian Otto <adrian.o...@rackspace.com>wrote: > Georgy, > > For Solum, let's refrain from storing any secrets, whether they be > passwords or trusts, or tokens. I definitely don't want to be in the > business of managing how to secure them in an SQL database. I don't even > want "admin password" values to appear in the configuration files. I'd > prefer to take a hard dependency on barbican[1], and store them in there, > where they can be centrally fortified with encryption and access controls, > accesses can be logged, they can be revoked, and we have a real auditing > story for enterprises who have strict security requirements. > > Thanks, > > Adrian > > [1] https://github.com/stackforge/barbican > > On Jan 17, 2014, at 11:26 AM, Georgy Okrokvertskhov < > gokrokvertsk...@mirantis.com> > wrote: > > Hi Lance, > > Thank you for the documentation link. It really solves the problem with > trust expiration. I really like an idea to restrict trust to specific > roles. This is great. > > As you mentioned, you use sql to store trusts information. Do you use > any encryption for that? I am thinking from security perspective, if you > have trust information in DB it might be not safe as this trust is a long > term authentication. > > Thanks > Georgy > > > On Fri, Jan 17, 2014 at 10:31 AM, Lance D Bragstad <ldbra...@us.ibm.com>wrote: > >> Hi Georgy, >> >> The following might help with some of the trust questions you have, if >> you haven't looked at it already: >> >> *https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3-os-trust-ext.md*<https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3-os-trust-ext.md> >> >> >> As far as storage implementation, trust uses sql and kvs backends. Trusts >> can be given an expiration but if an expiration is not given the trust is >> valid until it is explicitly revoked (taken from the link above): >> >> Optionally, the trust may only be valid for a specified time period, as >> defined by expires_at. If noexpires_at is specified, then the trust is >> valid until it is explicitly revoked. >> >> Trusts can also be given 'uses' so that you can set a limit to how many >> times a trust will issue a token to the trustee. That functionality hasn't >> landed yet but it is up for review: >> *https://review.openstack.org/#/c/56243/*<https://review.openstack.org/#/c/56243/> >> >> >> Hope this helps! >> >> >> Best Regards, >> >> Lance Bragstad >> >> >> <graycol.gif>Georgy Okrokvertskhov ---01/17/2014 12:11:46 PM---Hi, In >> Solum project we want to use Keystone trusts to work with other >> >> >> From: Georgy Okrokvertskhov <gokrokvertsk...@mirantis.com> >> To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>, >> >> Date: 01/17/2014 12:11 PM >> Subject: [openstack-dev] [Solum][Keystone] Best practices for storing >> keystone trusts information >> >> ------------------------------ >> >> >> >> Hi, >> >> In Solum project we want to use Keystone trusts to work with other >> OpenStack services on behalf of user. Trusts are long term entities and a >> service should keep them for a long time. >> >> I want to understand what are best practices for working with trusts and >> storing them in a service? >> >> What are the options to keep trust? I see obvious approaches like keep >> them in a service DB or keep them in memory. Are there any other approaches? >> >> Is there a proper way to renew trust? For example if I have a long term >> task which is waiting for external event, how to keep trust fresh for a >> long and unpredicted period? >> >> Thanks >> Georgy_______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Georgy Okrokvertskhov Technical Program Manager, Cloud and Infrastructure Services, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
