Re: [openstack-dev] [Solum][Keystone] Best practices for storing keystone trusts information
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 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 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 >> >> >> 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 >> To: OpenStack Development Mailing List , >> >> 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
Re: [openstack-dev] [Solum][Keystone] Best practices for storing keystone trusts information
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 mailto: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 mailto: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 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 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 mailto:gokrokvertsk...@mirantis.com>> To: OpenStack Development Mailing List mailto: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<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto: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
Re: [openstack-dev] [Solum][Keystone] Best practices for storing keystone trusts information
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 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 > > > [image: Inactive hide details for Georgy Okrokvertskhov ---01/17/2014 > 12:11:46 PM---Hi, In Solum project we want to use Keystone trusts]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 > To: OpenStack Development Mailing List , > > 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
Re: [openstack-dev] [Solum][Keystone] Best practices for storing keystone trusts information
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
From: Georgy Okrokvertskhov
To: OpenStack Development Mailing List
,
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] [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
