[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
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 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 inline: graycol.gif___ 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 gokrokvertsk...@mirantis.commailto: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.commailto: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 graycol.gifGeorgy 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.commailto:gokrokvertsk...@mirantis.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto: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.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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 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.comwrote: 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.comwrote: 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.gifGeorgy 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
