[Openstack] Keystone Design Session - Fine Grained Access Control
I'd like to propose a design session on Fine Grained Access Control for the summit. Session info: http://summit.openstack.org/cfp/edit/99 Blueprint: https://blueprints.launchpad.net/keystone/+spec/fine-grain Details: a large implementation, there can be many users each having some level of access to a shared pool of resources. Not all users need that much access though and there are cases where access must be restricted further. V3 introduces policies and that works for restricting access to certain capabilities (only a user with the role admin or group foo can create server in nova, etc). Policies bloat up though if they need to get down the resource level (only joe can delete server ABC). This blue print (which will be expanded upon) introduces the concept of a resource group in an attempt to provide highly-available, easily modifiable fine grained access control to OpenStack services. 1. The v3 core spec doesn't allow for fine-grained access control. You can force it into policy blobs, but that isn't scalable or transparent enough 2. Identity shouldn't act as a CMDB, keeping track and storing references to all resources 3. Having a configurable group that represents resources across services is easier to maintain in identity 4. Token scope has layers (all optional), and a. Service endpoints the token has access to b. Which roles the token is scoped to c. Which policies the token is scoped to 5. Likewise, policies should have scope: a. Which resource groups the policies apply to 6. Services should make a call available to introspect which servers, files, etc make up that resource group Looking forward to your comments the discussion! Thanks, Joe Savak ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone Design Session - Fine Grained Access Control
Hi Jay, See my comments below thanks for the feedback. :) What is the difference between a resource group and a group? A group in keystone is a collection of users. This aids in role assignments and makes a logical collection of users possible. A resource group in the context of keystone is an identifier of a distributed restriction that can be assigned to policies and users. For example: Policy x defines that user joe can perform the capability deleteServers. That policy is tied to a resource group called prod-servers. Hitting up nova in a GET /resource-group/prod-servers will yield all the resources (with respect to that service) that comprise that resource group. Those are the servers that joe may delete. Do your scalability concerns revolve around having a single policy BLOB for the service and the corresponding single record, multi-writer data access pattern that would mean? If you had a policy BLOB per group, would that assuage those concerns? Meaning... a compromise between having a REST API that would essentially operate on single resources and the existing API that changes all policies in one call? The proposed solution above helps distribute the real load of a fine-grained access control solution out to the services that would know more about the resources. Thanks, joe -Original Message- From: openstack-bounces+joe.savak=rackspace@lists.launchpad.net [mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On Behalf Of Jay Pipes Sent: Tuesday, April 02, 2013 9:58 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Keystone Design Session - Fine Grained Access Control On 04/02/2013 09:51 AM, Joe Savak wrote: I'd like to propose a design session on Fine Grained Access Control for the summit. Session info: http://summit.openstack.org/cfp/edit/99 Blueprint: https://blueprints.launchpad.net/keystone/+spec/fine-grain Details: a large implementation, there can be many users each having some level of access to a shared pool of resources. Not all users need that much access though and there are cases where access must be restricted further. V3 introduces policies and that works for restricting access to certain capabilities (only a user with the role admin or group foo can create server in nova, etc). Policies bloat up though if they need to get down the resource level (only joe can delete server ABC). Once you go down this super-fine-grained route and start managing privileges in this manner, it definitely complicates things. :) This blue print (which will be expanded upon) introduces the concept of a resource group in an attempt to provide highly-available, easily modifiable fine grained access control to OpenStack services. What is the difference between a resource group and a group? 1. The v3 core spec doesn't allow for fine-grained access control. You can force it into policy blobs, but that isn't scalable or transparent enough Do your scalability concerns revolve around having a single policy BLOB for the service and the corresponding single record, multi-writer data access pattern that would mean? If you had a policy BLOB per group, would that assuage those concerns? Meaning... a compromise between having a REST API that would essentially operate on single resources and the existing API that changes all policies in one call? Best, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
Hi Joe, If I'm working across multiple tenants, I'd prefer one token that I can securely handle that proves access rights to the tenants I'm working with. Handling multiple tokens increases the complexity of clients needing to provide multi-tenancy access to an authenticated identity. It also adds more calls to keystone. Again, I think that having the keystone reference implementation restrict tokens to 1 tenant is fine. We shouldn't have such arbitrary restrictions in the API contract though. It needs to be extensible and flexible to allow for the all sorts of use cases that are likely to occur. Thanks, joe -Original Message- From: heckj [mailto:he...@mac.com] Sent: Tuesday, November 13, 2012 3:59 PM To: Joe Savak Cc: OpenStack Development Mailing List; openstack@lists.launchpad.net (openstack@lists.launchpad.net) Subject: Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API Hey Joe: Currently a user scoped token doesn't include a service catalog - mostly because I think the service catalog generally requires tenant_id's to interpolate into the values to provide it. That doesn't mean we can't put in/include service catalog endpoints where that value doesn't need to be determined. I'm also questioning the value of providing a token scoped to all tenants associated with a user - that seems to have the same value as just using a user token. In fact, even if we allow some arbitrary set of tenants to be scoped into a token along with a user, what on earth should be in the service catalog? Endpoints relevant to every possible tenant? This just seems to be a potential explosion of data that is poorly scoped from a security perspective. -joe On Nov 13, 2012, at 1:42 PM, Joe Savak joe.sa...@rackspace.com wrote: Will user-scoped token include the full service catalog? Also, I thought the consensus was to allow the API contract to be flexible on how many tenants we can scope the token to. The ref impl can enforce 1 tenant-scoped token. Are we diverging from this? Thanks, joe -Original Message- From: openstack-bounces+joe.savak=rackspace@lists.launchpad.net [mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On Behalf Of heckj Sent: Tuesday, November 13, 2012 1:34 PM To: OpenStack Development Mailing List Cc: openstack@lists.launchpad.net (openstack@lists.launchpad.net) Subject: Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API On Nov 13, 2012, at 11:01 AM, Jorge Williams jorge.willi...@rackspace.com wrote: On Nov 13, 2012, at 11:35 AM, heckj wrote: So maintaining a token scoped to just the user, and a mechanism to scope it to a tenant sound like all goodness. We can absolutely keep the API such that it can provide either. Right now, our auth_token middleware implicitly requires a tenant in that scoping to work. If someone wanted to support a token scoped to just a user for the services, they'd need a different middleware there. Keystone as a service *doesn't* use the auth_token middleware, so with the V3 API we can make it provide services appropriately based on a token scoped only to the user. All that in place, allow a token to be indeterminate scoped to multiple tenants is fraught with security flaws, and if we continue to provide unscoped tokens, that should obviate the need for token scoped to multiple tenants. I'm not sure I'm following you there. I don't see how unscoped tokens obviate the need to scope to multiple tenants, these may be driven by different concerns. Again, I think we need to have some flexibility in how we scope tokens. The API should be flexible enough to support different models -- I think that scoping a token to multiple tenants is useful in cases such as delegation -- where a single identity may be issued revokable access to a set of resources in multiple projects. The consensus from the folks weighing in on this from a security perspective seems to be that it's kosher to restrict tokens further (the least privilege thing). Broadening the scope to multiple tenants or sets of tenants doesn't appear to follow those best practices. If you wanted to accept a less-scoped token than the scoped to single tenant, you can accept and use a user-scoped token, at least by my read. -joe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
Will user-scoped token include the full service catalog? Also, I thought the consensus was to allow the API contract to be flexible on how many tenants we can scope the token to. The ref impl can enforce 1 tenant-scoped token. Are we diverging from this? Thanks, joe -Original Message- From: openstack-bounces+joe.savak=rackspace@lists.launchpad.net [mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On Behalf Of heckj Sent: Tuesday, November 13, 2012 1:34 PM To: OpenStack Development Mailing List Cc: openstack@lists.launchpad.net (openstack@lists.launchpad.net) Subject: Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API On Nov 13, 2012, at 11:01 AM, Jorge Williams jorge.willi...@rackspace.com wrote: On Nov 13, 2012, at 11:35 AM, heckj wrote: So maintaining a token scoped to just the user, and a mechanism to scope it to a tenant sound like all goodness. We can absolutely keep the API such that it can provide either. Right now, our auth_token middleware implicitly requires a tenant in that scoping to work. If someone wanted to support a token scoped to just a user for the services, they'd need a different middleware there. Keystone as a service *doesn't* use the auth_token middleware, so with the V3 API we can make it provide services appropriately based on a token scoped only to the user. All that in place, allow a token to be indeterminate scoped to multiple tenants is fraught with security flaws, and if we continue to provide unscoped tokens, that should obviate the need for token scoped to multiple tenants. I'm not sure I'm following you there. I don't see how unscoped tokens obviate the need to scope to multiple tenants, these may be driven by different concerns. Again, I think we need to have some flexibility in how we scope tokens. The API should be flexible enough to support different models -- I think that scoping a token to multiple tenants is useful in cases such as delegation -- where a single identity may be issued revokable access to a set of resources in multiple projects. The consensus from the folks weighing in on this from a security perspective seems to be that it's kosher to restrict tokens further (the least privilege thing). Broadening the scope to multiple tenants or sets of tenants doesn't appear to follow those best practices. If you wanted to accept a less-scoped token than the scoped to single tenant, you can accept and use a user-scoped token, at least by my read. -joe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Fwd: [openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
Your suggestion to it optional (it being a token scoped to multiple projects). :) From: Adam Young [mailto:ayo...@redhat.com] Sent: Monday, October 22, 2012 9:57 PM To: Jorge Williams Cc: Joe Savak; OpenStack Development Mailing List; openstack@lists.launchpad.net Subject: Re: [Openstack] Fwd: [openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API Are you guys +1 ing the original Idea, my suggestion to make it optional, the fact that I think we should call these sloppy tokens? On 10/22/2012 03:40 PM, Jorge Williams wrote: +1 here too. At the end of the day, we'd like the identity API to be flexible enough to allow the token to be scoped in a manner that the deployer sees fit. What the keystone implementation does by default is a different matter -- and disabling multiple tenant scope by default would be fine by me. -jOrGe W. On Oct 21, 2012, at 11:10 AM, Joe Savak wrote: +1. ;) So the issue is that the v2 API contract allows a token to be scoped to multiple tenants. For v3, I'd like to have the same flexibility. I don't see security issues, as if a token were to be sniffed you can change the password of the account using it and use those creds to scope tokens to any tenant you wish. Scope should always be kept as limited as possible. Personally, I don't feel like limiting the tenant list makes much difference. THe more I think about it, the real benefit comes from limiting the endpoints. On Oct 20, 2012, at 21:07, Adam Young ayo...@redhat.commailto:ayo...@redhat.com wrote: On 10/20/2012 01:50 PM, heckj wrote: I sent this to the openstack-dev list, and thought I'd double post this onto the openstack list at Launchpad for additional feedback. -joe Begin forwarded message: From: heckj he...@mac.commailto:he...@mac.com Subject: [openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API Date: October 19, 2012 1:51:16 PM PDT To: OpenStack Development Mailing List openstack-...@lists.openstack.orgmailto:openstack-...@lists.openstack.org Reply-To: OpenStack Development Mailing List openstack-...@lists.openstack.orgmailto:openstack-...@lists.openstack.org The topic of what a token can or can't represent for the upcoming V3 Keystone API came up - and I wanted to share the conversation a bit more broadly to get feedback. A bit of history: In the V2 API, when you authenticated with just a username and password, the token that was provided wasn't entirely clearly defined. The reference implementation that Keystone used was to create what's been called an 'unscoped' token - which was generally limited to only being able to get a list of possible tenants/projects and the capability of getting a token specific to a user tenant/project (what's been called a scoped token) Likewise, the reference implementation of the rest of the OpenStack projects all require a tenant information to be included within the token as that token was the identity refernce inforoamtion - and most OpenStack services were wanting to know the tenant associated with the token for authorization/ownership purposes. Apparently Rackspace's internal implementation provided a token that was immediately valid for all possible tenants to which the user was associated, and presumably their internal implementations of openstack do whatever work is appropriate to discern and provide that information to the various openstack services. The quandary: In the V3 API, we started off with, and currently define the token as being specifically mandated to a single tenant, with a new requirement that if you authorize with just a username and password, a default tenant is used. If for some reason you have no tenant associated with the userid, the authorization is to be refused. If the user is associated with more than one tenant/project, it's possible to use the token to get a list of other tenants/projects and request a new token specific to one of those other tenant/projects, but the implementation is expected to respect and provide a default. I would like to make default tenant a configuration option, and have it disabled by default. Unscoped tokens are a very useful construct. In the case where the user has many roles across a multitude of projects, it is possible to create huge tokens. I would prefer unscoped tokens to remain, and to be associated with no tenant. The only operation Keystone should provide with them is the ability to enumerate tenants, so something like Horizon can then request an appropriately scoped token. I am also in favor of limiting the scope of a token to an endpoint. Even more-so than tenants, scoping a token to an end point increases security. Once a token has been scoped to an endpoint, it can only be used on that endpoint. If an endpoint gets compromised, the damage is limited to resources that endpoint already has access to. This, in conjunction with pre
Re: [Openstack] Fwd: [openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
+1. ;) So the issue is that the v2 API contract allows a token to be scoped to multiple tenants. For v3, I'd like to have the same flexibility. I don't see security issues, as if a token were to be sniffed you can change the password of the account using it and use those creds to scope tokens to any tenant you wish. On Oct 20, 2012, at 21:07, Adam Young ayo...@redhat.commailto:ayo...@redhat.com wrote: On 10/20/2012 01:50 PM, heckj wrote: I sent this to the openstack-dev list, and thought I'd double post this onto the openstack list at Launchpad for additional feedback. -joe Begin forwarded message: From: heckj he...@mac.commailto:he...@mac.com Subject: [openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API Date: October 19, 2012 1:51:16 PM PDT To: OpenStack Development Mailing List openstack-...@lists.openstack.orgmailto:openstack-...@lists.openstack.org Reply-To: OpenStack Development Mailing List openstack-...@lists.openstack.orgmailto:openstack-...@lists.openstack.org The topic of what a token can or can't represent for the upcoming V3 Keystone API came up - and I wanted to share the conversation a bit more broadly to get feedback. A bit of history: In the V2 API, when you authenticated with just a username and password, the token that was provided wasn't entirely clearly defined. The reference implementation that Keystone used was to create what's been called an 'unscoped' token - which was generally limited to only being able to get a list of possible tenants/projects and the capability of getting a token specific to a user tenant/project (what's been called a scoped token) Likewise, the reference implementation of the rest of the OpenStack projects all require a tenant information to be included within the token as that token was the identity refernce inforoamtion - and most OpenStack services were wanting to know the tenant associated with the token for authorization/ownership purposes. Apparently Rackspace's internal implementation provided a token that was immediately valid for all possible tenants to which the user was associated, and presumably their internal implementations of openstack do whatever work is appropriate to discern and provide that information to the various openstack services. The quandary: In the V3 API, we started off with, and currently define the token as being specifically mandated to a single tenant, with a new requirement that if you authorize with just a username and password, a default tenant is used. If for some reason you have no tenant associated with the userid, the authorization is to be refused. If the user is associated with more than one tenant/project, it's possible to use the token to get a list of other tenants/projects and request a new token specific to one of those other tenant/projects, but the implementation is expected to respect and provide a default. I would like to make default tenant a configuration option, and have it disabled by default. Unscoped tokens are a very useful construct. In the case where the user has many roles across a multitude of projects, it is possible to create huge tokens. I would prefer unscoped tokens to remain, and to be associated with no tenant. The only operation Keystone should provide with them is the ability to enumerate tenants, so something like Horizon can then request an appropriately scoped token. I am also in favor of limiting the scope of a token to an endpoint. Even more-so than tenants, scoping a token to an end point increases security. Once a token has been scoped to an endpoint, it can only be used on that endpoint. If an endpoint gets compromised, the damage is limited to resources that endpoint already has access to. This, in conjunction with pre-auths, could allow a user to perform an action with a minimum of risk in a public cloud environment. A few folks from Rackspace touched on this at the very tail end of the V3 API review session on Thursday, bringing up that they had an issue with the token being scoped to a single tenant. Since this has significant implications to both security and a potential user experience flow, I wanted to bring the issue up across the broader community for discussion. The request outstanding: Rackspace folks are requesting that the token not be limited to a single tenant/project, but instead provides a list of potential tenants against which the token should be considered valid. I would like the world to know that we are affectionately calling such tokens sloppy tokens and Joe Savak has adopted the nickname of Sloppy Joe for championing them. Allowing it as an option is fine, but I would not recommend that this become the norm, or that we enable this feature by default. Brief (maybe shoddy) analysis: This would potentially imply changes to what gets passed as a part of the authentication reference in the context passed using auth_token
[Openstack] (no subject)
___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] REPOSE - at 3:40/Wednesday in Maggie (OpenStack summit)
Come learn about Repose - Restful HTTP proxy service helping with rate limiting and client authentication http://openrepose.org/ Introducing Repose: http://www.rackspace.com/blog/introducing-repose-the-restful-proxy-service-engine/ A more technical look at Repose: http://devops.rackspace.com/459/rate-limiting-with-repose-the-restful-proxy-service-engine 3:40pm on Wednesday at the OpenStack Summit in the Maggie Room ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Keystone] What exactly are we modeling with endpoints?
Is it reasonable to have a service without any endpoints? There are no use cases today that I know of that would need a service represented in the service catalog without endpoints. Since the future is vague though and each implementation could be different, I don't think we should require a service to have an endpoint. Same with 3 duplicate endpoints - a use case could come up and the core contract should be flexible enough with these things. From: Joseph Heck [mailto:he...@me.com] Sent: Wednesday, April 25, 2012 11:47 AM To: Nguyen, Liem Manh Cc: Joe Savak; openstack@lists.launchpad.net (openstack@lists.launchpad.net); Adam Gandelman Subject: Re: [Openstack] [Keystone] What exactly are we modeling with endpoints? This isn't about parsing the data structure - it's about what a service represents so that we can model it appropriately. So what does the service here represent? the collection of all possible services of that type? That's what your example would seem to indicate. In your example, the service is a pretty simple structure - just having a type (driven by convention and API spec) and human readable name, and each service is expected to have 1 to N endpoints. Is it reasonable to have a service without any endpoints? Regardless of reasonable, is it allowable? What does an endpoint represent? The API's URI point, clearly. Is there a uniqueness constraint of any kind on endpoints? Is it allowable (if strange) to list 3 duplicate endpoints with exactly the same metadata on it? -joe On Apr 25, 2012, at 9:37 AM, Nguyen, Liem Manh wrote: I would like to keep the service type and name under the service and not the endpoint, too. Make it easier to parse for a given service. One thing is that I am not sure if we need the metadata tag... In the Keystone XSD, we have the construct anyAttribute namespace=##other processContents=lax/, which allows any additional, implementation-specific attribute to be added. Those that do not support the specific attribute can simply ignore it. A couple of benefits I can see with not using the metadata tag, and just use the custom element directly like this: http://paste.openstack.org/show/13832/, which the anyAttribute supports, are: * Simplier parsing, one level less. * If that attribute becomes a core attribute later, no need to change the parser. Liem From: openstack-bounces+liem_m_nguyen=hp@lists.launchpad.netmailto:openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net [mailto:openstack-bounces+liem_m_nguyen=hp@lists.launchpad.netmailto:hp@lists.launchpad.net] On Behalf Of Joe Savak Sent: Tuesday, April 24, 2012 1:04 PM To: Joseph Heck; openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net (openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net) Cc: Adam Gandelman Subject: Re: [Openstack] [Keystone] What exactly are we modeling with endpoints? Having endpoints under the service construct is supposed to make it easier to programmatically find the endpoint(s) you are interested in. For example - as nova client I can parse the service catalog and identity nova by service-type compute in order to get the public, internal, and admin endpoints for nova. By having service type name as attributes under the endpoint, I'll have a harder time doing that (having to dive into each endpoint construct to identify the ones with service-type compute). Maybe it would be better to have each endpoint have its own construct inside of a service. So instead of http://paste.openstack.org/show/13678/ Maybe http://paste.openstack.org/show/13682/ From: openstack-bounces+joe.savak=rackspace@lists.launchpad.netmailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net [mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.netmailto:rackspace@lists.launchpad.net] On Behalf Of Joseph Heck Sent: Friday, April 20, 2012 4:16 PM To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net (openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net) Cc: Adam Gandelman Subject: [Openstack] [Keystone] What exactly are we modeling with endpoints? While I've been roaming about the summit and conference, I've been trying to figure out exactly what we're modeling with the current service and endpoints that are in the API today. After talking with a number of folks, it's getting clearer that how it's being used is very installation specific. I'd like to simplify this aspect of the API if at all possible, especially with a lot of the good ideas around describing the relationships between endpoints and and their installation. The use cases I'm hearing actively in use are: * (Horizon/UI/client) To indicate to a user where they can go to access their data * (Glance, Nova, Keystone client) to find the endpoint relevant to uploading images (current client implementations appear to assume there is only one image endpoint) The use case to indicate
Re: [Openstack] [Keystone] What exactly are we modeling with endpoints?
Having endpoints under the service construct is supposed to make it easier to programmatically find the endpoint(s) you are interested in. For example - as nova client I can parse the service catalog and identity nova by service-type compute in order to get the public, internal, and admin endpoints for nova. By having service type name as attributes under the endpoint, I'll have a harder time doing that (having to dive into each endpoint construct to identify the ones with service-type compute). Maybe it would be better to have each endpoint have its own construct inside of a service. So instead of http://paste.openstack.org/show/13678/ Maybe http://paste.openstack.org/show/13682/ From: openstack-bounces+joe.savak=rackspace@lists.launchpad.net [mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On Behalf Of Joseph Heck Sent: Friday, April 20, 2012 4:16 PM To: openstack@lists.launchpad.net (openstack@lists.launchpad.net) Cc: Adam Gandelman Subject: [Openstack] [Keystone] What exactly are we modeling with endpoints? While I've been roaming about the summit and conference, I've been trying to figure out exactly what we're modeling with the current service and endpoints that are in the API today. After talking with a number of folks, it's getting clearer that how it's being used is very installation specific. I'd like to simplify this aspect of the API if at all possible, especially with a lot of the good ideas around describing the relationships between endpoints and and their installation. The use cases I'm hearing actively in use are: * (Horizon/UI/client) To indicate to a user where they can go to access their data * (Glance, Nova, Keystone client) to find the endpoint relevant to uploading images (current client implementations appear to assume there is only one image endpoint) The use case to indicate a geographic location for a datacenter or cloud is not consistent - some implementations I've learned of have that feature (and use Region for that sort of information), and others are load balancing a single endpoint to deploy to multiple datacenters and geographic regions from a single endpoint. At the summit and conference, I heard a desire to expose geographic information with the endpoints, but that is clearly an operator specific implementation/deployment detail. Likewise I heard a lot of We could really... if additional metadata was easily available on endpoints, again in fairly implementation/deployment specific detail. So looking forward towards a v.next API, what do you all think about having just endpoints, with everything else being attributes on those endpoints (including what service and type it is), with some expected conventions (that there are a few well defined types - such as PublicURL and InternalURL, and relevant names for the rest API endpoints (ec2, compute, volume, image, identity...) Additional metadata can then float on the endpoints in deployment/implementation specific ways that don't lock in other systems to be deployed and implemented in the same fashion. -joe On Apr 20, 2012, at 1:47 PM, Lorin Hochstein wrote: On Apr 13, 2012, at 12:34 PM, Adam Gandelman wrote: On 04/13/2012 10:50 AM, Dolph Mathews wrote: While $(tenant_id)s is certainly the documented syntax, it appears that the SQL catalog backend (and *only* the SQL catalog backend, as far as I can tell) explicitly supports both $(tenant_id)s and %(tenant_id)s: https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/sql.py#L163 Perhaps Adam Gandelman has some insight? -Dolph Dolph- No, the same is supported in the case of templated catalog as well, which is what the SQL catalog was largely based off: https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/templated.py#L115 Just tested that sed -i 's/\$/%/g' /etc/keystone/default_catalog.templates still produces a functional service catalog when configured to use the templated backend. Seeing as both are supported, perhaps it would be better for docs to be updated to refer to the use of % instead of $ to avoid people running into problems with the $() sub-shell? The OpenStack Install and Deploy manual has some language about this (see last paragraph): http://docs.openstack.org/trunk/openstack-compute/install/content/elements-of-keystone-service-catalog-entry.html This hasn't made its way into the admin docs yet, though. Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.comhttps://www.nimbisservices.com/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to :
Re: [Openstack] Repose project?
Hi Liem! Jorge team have been busy on it and have developed the resources below. Docs: http://openrepose.org/documentation.html Wiki: http://wiki.openrepose.org/display/REPOSE/Home Code: https://github.com/rackspace/repose Thanks, Joe From: openstack-bounces+joe.savak=rackspace@lists.launchpad.net [mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On Behalf Of Nguyen, Liem Manh Sent: Monday, March 12, 2012 12:00 PM To: openstack@lists.launchpad.net Subject: [Openstack] Repose project? Hello fellow stackers, Last year, Jorge gave a presentation on the Repose (Restful Proxy Service Engine)... I am just wondering what is the status of this project? Where can I find more information on this? It seems like a very good idea to help make APIs more consistent and promote re-use. Thanks, Liem ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Request for review - Keystone RBAC calls
Hi Stackers, Keystone has an RBAC prototype on its roadmap for e-1 and we'd like to get your feedback on the blueprint for it (https://blueprints.launchpad.net/keystone/+spec/rbac-keystone). OS-RBAC, a keystone extension, will allow Nova, Swift, Glance, and Dashboard to manage capabilities and assign capabilities to roles. The prototype will not be the full implementation of it, but will include WADL, XSD, and some of the major calls. Take a look and let us know your feedback. Thanks, Joe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] RBAC handled by keystone or each services ?
Hi Kuo,
RBAC is a hot topic at Essex right now with a few sessions to explicitly
discuss them:
http://essexdesignsummit.sched.org/event/2610368e1c5bd0e52982777f75baafb5
http://essexdesignsummit.sched.org/event/2d4b84fe8559d6a144897a1d53adbb9e
http://essexdesignsummit.sched.org/event/6648ad6a353fd56d39d45193a69f6908
I'm sure notes will be shared about the Essex design summit soon.
In the meantime, Keystone tag 2011.03 provides the following functionality for
roles:
1. Core calls as defined in
https://github.com/openstack/keystone/blob/master/keystone/content/admin/identityadminguide.pdf
(should be fully developed)
a. GET /users/{user_id}/roles - returns global roles for a specific user
(excludes tenant roles)
b. GET /tenants/{tenantId}/users/{user_id}/roles - returns roles for a
specific user on a specific tenant (excludes global roles)
2. Extension calls as defined in
https://github.com/openstack/keystone/blob/master/keystone/content/admin/OS-KSADM-admin-devguide.pdf
(contract complete but not code complete)
a. GET /OS-KSADM/roles - list roles
b. POST /OS-KSADM/roles - add role
c. GET /OS-KSADM/roles/{roleId} - get a role
d. DELETE /OS-KSADM/roles/{roleId} - delete a role
Since the extension isn't complete yet, you can use keystone-manage to add
users, roles, etc for testing.
Thanks,
Joe
From: openstack-bounces+joe.savak=rackspace@lists.launchpad.net
[mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On
Behalf Of Kuo Hugo
Sent: Wednesday, October 05, 2011 6:39 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] RBAC handled by keystone or each services ?
Hello folks ,
While playing with Keystone , there's four roles named
[Admin,Member,KeystoneAdmin,KeystoneServiceAdmin].
I'm confusing about that who handles these roles's permission / privileges
I mean RBAC include admin, itsec, projectmanager, netadmin, developer roles in
NOVA but not Admin/Member .
is that handled by keystone or service itself ???
Is there any API to add Roles(also set permission / privileges)?
In my guess , the RBAC still on each service(nova / swift ) , but how NOVA
knows the permission of Role Admin ?
--
+Hugo Kuo+
tonyt...@gmail.commailto:tonyt...@gmail.com
hugo@cloudena.commailto:hugo@cloudena.com
+886-935-004-793
www.cloudena.comhttp://www.cloudena.com
This email may include confidential information. If you received it in error,
please delete it.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal: URIs for X-Auth-Header Keystone tokens
Mark Bryan,
I haven't forgotten about this and included it on the keystone wiki so
we won't lose track of it during Essex planning.
http://wiki.openstack.org/keystone
Thanks,
Joe
-Original Message-
From: openstack-bounces+joe.savak=rackspace@lists.launchpad.net
[mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On
Behalf Of Mark Nottingham
Sent: Wednesday, September 07, 2011 2:11 AM
To: Bryan Taylor
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Proposal: URIs for X-Auth-Header Keystone tokens
There's been a lot of interest in a finer-grained Vary function (i.e.,
something that lets you specify the cache key on something more flexible than
just whole headers). We're working a a spec in the background, but of course
caches will need to support it...
Cheers,
On 05/09/2011, at 3:43 PM, Bryan Taylor wrote:
It _would_ be useful to have Vary pick out a link by its rel, even on a
request. Maybe the rel= part should've been considered part of the
header:
Link;rel=Keystone-token : blah
Or maybe Vary should support matching on header values:
Vary: Link:*;rel=keystone-token
On 9/4/11 9:51 PM, Mark Nottingham m...@mnot.net wrote:
Good point; Link makes more sense on a response.
Cheers,
On 05/09/2011, at 12:49 PM, Bryan Taylor wrote:
Hmmm, I'm thinking more about this. Would using the Link: header break
the
ability to use the Vary header? I can't Vary on a Link header based on
it's rel attribute.
So maybe Keystone-Token is the way to go. I could see intermediaries
doing
the token resolution and adding headers like Keystone-User and
Keystone-Tenant which could also be used in Vary Headers.
On 9/4/11 8:06 PM, Bryan Taylor btay...@rackspace.com wrote:
Love it.
Link:
https://keystone.server/tokens/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c;
rel=keystone-token
Fixed: s/tenants/tokens/ (my bad).
On 9/4/11 7:40 PM, Mark Nottingham m...@mnot.net wrote:
Still getting up to speed on the finer points of keystone, but makes
sense to me.
Is X-Auth-Token keystone-specific? If so, calling it something like
Keystone-Token would be better (X- is falling out of favour; see
http://tools.ietf.org/html/draft-saintandre-xdash-03). That'd also
avoid problems with people expecting the other format.
Finally, if you're going to make it a URI, best to enclose it in
quotes -
URIs can contain commas, which can be a delimiter in HTTP headers
(especially if multiple tokens might be allowed).
E.g.,
Keystone-Token:
https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c;
Cheers,
P.S. If these are going to show up in other contexts, it *might* make
sense to define keystone-token as a link relation
http://tools.ietf.org/html/rfc5988, giving you:
Link:
https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c;
rel=keystone-token
On 04/09/2011, at 2:39 AM, Bryan Taylor wrote:
I propose identifying tokens by their full keystone URI within
X-Auth-Token header. EG: instead of
X-Auth-Token: fa8426a0-8eaf-4d22-8e13-7c1b16a9370c
we would do
X-Auth-Token:
https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c
This has the advantage of allowing federated tokens, and allowing
APIs
and even resources to use the auth server in access decisions. A
given
service would maintain a whitelists of keystone servers. The service
would take the request, get the token, and verify that the host of
the
token URI matches one from the appropriate whitelist, and then do a
GET
on the token per the keystone API.
For example, consider rackspace. We might have 3 keystone servers:
region1.customer.keystone
region2.customer.keystone
employee.keystone
The management API might set it's whitelist to {employee.keystone},
while the public APIs could whitelist all three, or maybe just the
first
two.
This creates three ways to do remote federation.
1) Each service could simply add remote keystone APIs to its
whitelists.
2) A whitelisted keystone server return REDIRECT, which services
implicitly trust
3) A whitelisted keystone server could forward the request directly
Items 2 and 3 might be facilitated by adding an @host string to the
end of the token to allow the keystone implementation to map the
token
to its source. Eg: if the service receives a token that is not from a
whitelisted client, such as
https://keystone.utexas.edu/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a937
0c
then it mutate the token to hit a trusted keystone implementation:
https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c@k
ey
s
tone.utexas.edu
The keystone.server implementation could verify the trust
relationship
with keystone.utexas.edu and redirect or forward back to the
original.
This would allow remote federations to be controlled by the trusted
keystone servers in a way that a client can leverage with no special
knowledge
Re: [Openstack] API documentation move
I like it and +1 for identity-api since it will have both authZ and authN capabilities. From: openstack-bounces+joe.savak=rackspace@lists.launchpad.net [mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On Behalf Of Anne Gentle Sent: Wednesday, September 07, 2011 6:57 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] API documentation move Hello again - In yesterday's team meeting, Brian Lamar brought up a good point - why name the API projects after the project name, why not the product name? This makes a lot of sense to me. So the names for the API repos will be: compute-api identity-api (should this be auth-api?) image-api storage-api (should this be object-api?) Let me know your feedback on this naming standard. Thanks Jay for catching the keystone-api typo. :) Anne Anne Gentle a...@openstack.orgmailto:a...@openstack.org my bloghttp://justwriteclick.com/ | my bookhttp://xmlpress.net/publications/conversation-community/ | LinkedInhttp://www.linkedin.com/in/annegentle | Delicioushttp://del.icio.us/annegentle | Twitterhttp://twitter.com/annegentle On Tue, Sep 6, 2011 at 1:02 PM, Anne Gentle a...@openstack.orgmailto:a...@openstack.org wrote: Hi all - I wanted to discuss some changes to the API documentation for each project prior to implementation to make sure I'm not missing any crucial detail and to ensure you all feel you have ownership of the solution and input into it. My goal is to move all the OpenStack documentation into github repos. In doing so, I will also move all the API documentation into separate repos with a goal of completing the move by October 1st. Here is my current proposal, please feel free to suggest corrections as you see fit. 1. Create new github repos named project-api that contain: API documentation including existing API Dev Guides and in the case of Nova, an API Spec. Four new projects for now: openstack/glance-api, openstack/keystone, openstack/nova-api, openstack/swift-api. 2. Create connection to Gerrit for review by core devs for each project, plus the creation of a new group, openstack-core-doc, for reviews of all four projects. 3. Create a new github repo named openstack/openstack-manuals to contain sys admin documentation such as the Admin manuals (installation, configuration, administration docs). 4. Automated build/publish on Jenkins to the correct location on docs.openstack.orghttp://docs.openstack.org/ (or project.openstack.orghttp://project.openstack.org/ as appropriate), either /diablo or /api or /incubation depending on project's state. Also includes Jenkins jobs to validate the docs pre-merge, for XML validation and testing for missing figures. Please give me your feedback by the end of this week so we can make the next moves. Ha! Move! I've also added this item for discussion at today's team meeting. Thanks, Anne This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Keystone - call for blueprints (for Essex)
Hi all, We are hard at work getting Keystone documentation and core functionality in place for the Diablo release. That doesn't mean we aren't thinking ahead to Essex. You'll notice under the keystone wiki (http://wiki.openstack.org/keystone) a call for blueprints. Please peruse the blueprints that are out there, provide feedback, or feel free to add new ones. As a side note, all keystone issues have been moved over to launchpad (thank you Monty Dolph) and the rackspace/keystone github repo will be shut down (you should be referencing the openstack/keystone github repo). Thanks let me know if you have any questions, Joe This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone and SCIM - Simple Cloud Identity Management
I haven't heard of this before, but it sounds interesting. Possibly capable of providing the core (non-extension) CRUD operations for user management in Essex. On that note, I updated the keystone wiki (http://wiki.openstack.org/keystone ) with links to potential blueprints for Essex. I'll include SCIM as well as something to look into. Thanks, Joe -Original Message- From: openstack-bounces+joe.savak=rackspace@lists.launchpad.net [mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On Behalf Of Nathan Sowatskey Sent: Tuesday, September 06, 2011 6:09 AM To: openstack@lists.launchpad.net Subject: [Openstack] Keystone and SCIM - Simple Cloud Identity Management http://forums.openstack.org/viewtopic.php?f=23t=266 Hi Is anyone working on Keystone aware of the Simple Cloud Identity Management (SCIM) project? See: http://www.simplecloud.info/ SCIM addresses user provisioning for cloud services. That might overlap with Keystone, or there may be another part of Openstack that addresses user provisioning to services. I don't really know, so I am asking here. Thanks Nathan -- Nathan Sowatskey (nsowa...@cisco.com) - Technical Leader, STG - +34-638-083-675 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
