Open Stack

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.otto at 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 <
> gokrokvertskhov at 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 <ldbragst at 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 <gokrokvertskhov at mirantis.com>
>> To: OpenStack Development Mailing List <openstack-dev at 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>  _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140117/9c7609b2/attachment.html>