Open Stack

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<mailto: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<mailto: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

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/

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<mailto:gokrokvertskhov at mirantis.com>>
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto: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<mailto: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<mailto: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<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140117/94892e6a/attachment.html>