Re: [openstack-dev] [Keystone][Marconi][Heat] Creating accounts in Keystone
On 08/25/2014 10:49 AM, Zane Bitter wrote: On 24/08/14 23:17, Adam Young wrote: On 08/23/2014 02:01 AM, Clint Byrum wrote: I don't know how Zaqar does its magic, but I'd love to see simple signed URLs rather than users/passwords. This would work for Heat as well. That way we only have to pass in a single predictably formatted string. Excerpts from Zane Bitter's message of 2014-08-22 14:35:38 -0700: Here's an interesting fact about Zaqar (the project formerly known as Marconi) that I hadn't thought about before this week: it's probably the first OpenStack project where a major part of the API primarily faces Nah, this is the direction we are headed. Service users (out of LDAP!) are going to be the norm with a recent feature add to Keytone: http://adam.younglogic.com/2014/08/getting-service-users-out-of-ldap/ Ah, excellent, thanks Adam. (BTW markup fail: "The naming of this file is essential: keystone..conf [sic] is the expected form.") If that is the worst typo in that article I consider that success. So this will solve the Authentication half of the problem. What is the recommended solution for Authorisation? In particular, even if a service like Zaqar or Heat implements their own authorisation (e.g. the user creating a Zaqar queue supplies lists of the accounts that are allowed to read or write to it, respectively), how does the user ensure that the service accounts they create will not have access to other OpenStack APIs? IIRC the default policy.json files supplied by the various projects allow non-admin operations from any account with a role in the project. There are things I want to implement to solve this. Locking a token (and a trust) to a service and/or Endpoint is the primary thing. More finely grained roles. Delegating operations instead of roles. Additional constraints on tokens. Basically, I want the moon on a stick. Keep asking. I can't justify the effort to build this stuff until people show they need it. Heat has been the primary driver for so much of Keystone already. thanks, Zane. ___ 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] [Keystone][Marconi][Heat] Creating accounts in Keystone
Excerpts from Adam Young's message of 2014-08-24 20:17:34 -0700: > On 08/23/2014 02:01 AM, Clint Byrum wrote: > > I don't know how Zaqar does its magic, but I'd love to see simple signed > > URLs rather than users/passwords. This would work for Heat as well. That > > way we only have to pass in a single predictably formatted string. > > > > Excerpts from Zane Bitter's message of 2014-08-22 14:35:38 -0700: > >> Here's an interesting fact about Zaqar (the project formerly known as > >> Marconi) that I hadn't thought about before this week: it's probably the > >> first OpenStack project where a major part of the API primarily faces > > > > Nah, this is the direction we are headed. Service users (out of LDAP!) are > going to be the norm with a recent feature add to Keytone: > > > http://adam.younglogic.com/2014/08/getting-service-users-out-of-ldap/ > This complicates the case by requiring me to get tokens and present them, to cache them, etc. I just want to fetch and/or send messages. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Marconi][Heat] Creating accounts in Keystone
On 27/08/14 12:15, Kurt Griffiths wrote: On 8/25/14, 9:50 AM, "Ryan Brown" wrote: I'm actually quite partial to roles because, in my experience, service accounts rarely have their credentials rotated more than once per eon. Having the ability to let instances grab tokens would certainly help Heat, especially if we start using Zaqar (the artist formerly known as marconi). According to AWS docs, IAM Roles allow you to "Define which API actions and resources the application can use after assuming the role.” What would it take to implement this in OpenStack? Currently, Keystone roles seem to be more oriented toward cloud operators, not end users. This quote from the Keystone docs[1] is telling: If you wish to restrict users from performing operations in, say, the Compute service, you need to create a role in the Identity Service and then modify /etc/nova/policy.json so that this role is required for Compute operations. The terminology is somewhat confusing, because roles are entirely different things in OpenStack. In AWS a Role is a type of account that is locked to a single EC2 server that is automatically supplied with rotating tokens. In Keystone, a role is a group membership within a project. What you're hitting on is that Keystone has been primarily an Identity service concerned only with Authentication and not Authorisation. The limited Authorisation that does exist is concerned with checking roles assigned by the operator against the policy.json file also provided by the operator. In practice, it's mostly at the granularity of locking down individual URL endpoints to be admin-only (where admin means the cloud operator). What will be increasingly needed is what you describe below; a way for users to assign roles or something similar to accounts, along with fine-grained permissions for operations on individual resources. Right now afaik the best you can do is to roll your own within each OpenStack project, which is unfortunate - but much worse is that there's no way to communicate to other project APIs that particular accounts should be locked down. cheers, Zane. On 8/25/14, 9:49 AM, "Zane Bitter" wrote: In particular, even if a service like Zaqar or Heat implements their own authorisation (e.g. the user creating a Zaqar queue supplies lists of the accounts that are allowed to read or write to it, respectively), how does the user ensure that the service accounts they create will not have access to other OpenStack APIs? IIRC the default policy.json files supplied by the various projects allow non-admin operations from any account with a role in the project. It seems like end users need to be able to define custom roles and policies. Some example use cases for the sake of discussion: 1. App developer sends a request to Zaqar to create a queue named “customer-orders" 2. Zaqar creates a queue named "customer-orders" 3. App developer sends a request to Keystone to create a role, "role-x", for App Component X 4. Keystone creates role-x 5. App developer sends requests to Keystone to create a service user, “user-x” and associate it with role-x 6. Keystone creates user-x and gives it role-x 7. App developer sends a request to Zaqar to create a policy, “customer-orders-observer”, and associate that policy with role-x. The policy only allows GETing (listing) messages from the customer-orders queue 8. Zaqar creates customer-orders-observer and notes that it is associated with role-x Later on... 1. App Component X sends a request to Zaqar, including an auth token 2. Zaqar sends a request to Keystone asking for roles associated with the given token 3. Keystone returns one or more roles, including role-x 4. Zaqar checks for any user-defined policies associated with the roles, including role-x, and finds customer-orders-observer 5. Zaqar verifies that the requested operation is allowed according to customer-orders-observer We should also compare and contrast this with signed URLs ala Swift’s tempurl. For example, service accounts do not have to be created or managed in the case of tempurl. --Kurt [1]: http://goo.gl/5UBMwR [http://docs.openstack.org] ___ 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] [Keystone][Marconi][Heat] Creating accounts in Keystone
On 08/27/2014 12:15 PM, Kurt Griffiths wrote: > On 8/25/14, 9:50 AM, "Ryan Brown" wrote: > >> I'm actually quite partial to roles because, in my experience, service >> accounts rarely have their credentials rotated more than once per eon. >> Having the ability to let instances grab tokens would certainly help >> Heat, especially if we start using Zaqar (the artist formerly known as >> marconi). >> > > According to AWS docs, IAM Roles allow you to "Define which API actions > and resources the application can use after assuming the role.” What would Optimally, you'd be able to (as a user) generate tokens with subsets of your permissions (e.g. if you're admin, you can create non-admin tokens/tempurls). It seems like implementing this seems (from where I'm sitting) like it would take lots of help from the Keystone team. > it take to implement this in OpenStack? Currently, Keystone roles seem to > be more oriented toward cloud operators, not end users. This quote from > the Keystone docs[1] is telling: > > If you wish to restrict users from performing operations in, say, > the Compute service, you need to create a role in the Identity > Service and then modify /etc/nova/policy.json so that this role is > required for Compute operations. I wasn't aware that this was how role permissions worked. Thank you for including that info. > > On 8/25/14, 9:49 AM, "Zane Bitter" wrote: > >> In particular, even if a service like Zaqar or Heat implements their own >> authorisation (e.g. the user creating a Zaqar queue supplies lists of >> the accounts that are allowed to read or write to it, respectively), how >> does the user ensure that the service accounts they create will not have >> access to other OpenStack APIs? IIRC the default policy.json files >> supplied by the various projects allow non-admin operations from any >> account with a role in the project. >> > > It seems like end users need to be able to define custom roles and > policies. > > Some example use cases for the sake of discussion: > > 1. App developer sends a request to Zaqar to create a queue named >“customer-orders" > 2. Zaqar creates a queue named "customer-orders" > 3. App developer sends a request to Keystone to create a role, "role-x", >for App Component X > 4. Keystone creates role-x > 5. App developer sends requests to Keystone to create a service user, >“user-x” and associate it with role-x > 6. Keystone creates user-x and gives it role-x > 7. App developer sends a request to Zaqar to create a policy, >“customer-orders-observer”, and associate that policy with role-x. The >policy only allows GETing (listing) messages from the customer-orders >queue > 8. Zaqar creates customer-orders-observer and notes that it is associated >with role-x > > Later on... > > 1. App Component X sends a request to Zaqar, including an auth token > 2. Zaqar sends a request to Keystone asking for roles associated with the >given token > 3. Keystone returns one or more roles, including role-x > 4. Zaqar checks for any user-defined policies associated with the roles, >including role-x, and finds customer-orders-observer > 5. Zaqar verifies that the requested operation is allowed according to >customer-orders-observer > > We should also compare and contrast this with signed URLs ala Swift’s > tempurl. For example, service accounts do not have to be created or > managed in the case of tempurl. Perhaps there would be a way to have a more generic (Keystone-wide) version of similar functionality. Even if there wasn't any scoping support it would still be exceptionally useful. This is starting to sound like it's worth drafting a blueprint for, or at least looking through existing BP's to see if there's something that fits. > > --Kurt > > [1]: http://goo.gl/5UBMwR [http://docs.openstack.org] > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Marconi][Heat] Creating accounts in Keystone
On 8/25/14, 9:50 AM, "Ryan Brown" wrote: >I'm actually quite partial to roles because, in my experience, service >accounts rarely have their credentials rotated more than once per eon. >Having the ability to let instances grab tokens would certainly help >Heat, especially if we start using Zaqar (the artist formerly known as >marconi). > According to AWS docs, IAM Roles allow you to "Define which API actions and resources the application can use after assuming the role.” What would it take to implement this in OpenStack? Currently, Keystone roles seem to be more oriented toward cloud operators, not end users. This quote from the Keystone docs[1] is telling: If you wish to restrict users from performing operations in, say, the Compute service, you need to create a role in the Identity Service and then modify /etc/nova/policy.json so that this role is required for Compute operations. On 8/25/14, 9:49 AM, "Zane Bitter" wrote: >In particular, even if a service like Zaqar or Heat implements their own >authorisation (e.g. the user creating a Zaqar queue supplies lists of >the accounts that are allowed to read or write to it, respectively), how >does the user ensure that the service accounts they create will not have >access to other OpenStack APIs? IIRC the default policy.json files >supplied by the various projects allow non-admin operations from any >account with a role in the project. > It seems like end users need to be able to define custom roles and policies. Some example use cases for the sake of discussion: 1. App developer sends a request to Zaqar to create a queue named “customer-orders" 2. Zaqar creates a queue named "customer-orders" 3. App developer sends a request to Keystone to create a role, "role-x", for App Component X 4. Keystone creates role-x 5. App developer sends requests to Keystone to create a service user, “user-x” and associate it with role-x 6. Keystone creates user-x and gives it role-x 7. App developer sends a request to Zaqar to create a policy, “customer-orders-observer”, and associate that policy with role-x. The policy only allows GETing (listing) messages from the customer-orders queue 8. Zaqar creates customer-orders-observer and notes that it is associated with role-x Later on... 1. App Component X sends a request to Zaqar, including an auth token 2. Zaqar sends a request to Keystone asking for roles associated with the given token 3. Keystone returns one or more roles, including role-x 4. Zaqar checks for any user-defined policies associated with the roles, including role-x, and finds customer-orders-observer 5. Zaqar verifies that the requested operation is allowed according to customer-orders-observer We should also compare and contrast this with signed URLs ala Swift’s tempurl. For example, service accounts do not have to be created or managed in the case of tempurl. --Kurt [1]: http://goo.gl/5UBMwR [http://docs.openstack.org] ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Marconi][Heat] Creating accounts in Keystone
On 08/22/2014 05:35 PM, Zane Bitter wrote: > > On AWS the very first thing a user does is create a bunch of IAM > accounts so that they virtually never have to use the credentials > associated with their natural person ever again. There are both user > accounts and service accounts - the latter IIUC have > automatically-rotating keys. Is there anything like this planned in > Keystone? Zaqar is likely only the first (I guess second, if you count > Heat) of many services that will need it. > The only auto-rotation in AWS is through roles[1], which are separate from users. User: * Is a real person or a service account * Can generate temporary tokens with a subset of their perms * Has a static credentials (access keys, username/password, MFA) Role: * Has no static credentials * Is granted to an instance on launch * Temporary tokens are provided to instance by instance metadata service I'm actually quite partial to roles because, in my experience, service accounts rarely have their credentials rotated more than once per eon. Having the ability to let instances grab tokens would certainly help Heat, especially if we start using Zaqar (the artist formerly known as marconi). [1]: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Marconi][Heat] Creating accounts in Keystone
On 24/08/14 23:17, Adam Young wrote: On 08/23/2014 02:01 AM, Clint Byrum wrote: I don't know how Zaqar does its magic, but I'd love to see simple signed URLs rather than users/passwords. This would work for Heat as well. That way we only have to pass in a single predictably formatted string. Excerpts from Zane Bitter's message of 2014-08-22 14:35:38 -0700: Here's an interesting fact about Zaqar (the project formerly known as Marconi) that I hadn't thought about before this week: it's probably the first OpenStack project where a major part of the API primarily faces Nah, this is the direction we are headed. Service users (out of LDAP!) are going to be the norm with a recent feature add to Keytone: http://adam.younglogic.com/2014/08/getting-service-users-out-of-ldap/ Ah, excellent, thanks Adam. (BTW markup fail: "The naming of this file is essential: keystone..conf [sic] is the expected form.") So this will solve the Authentication half of the problem. What is the recommended solution for Authorisation? In particular, even if a service like Zaqar or Heat implements their own authorisation (e.g. the user creating a Zaqar queue supplies lists of the accounts that are allowed to read or write to it, respectively), how does the user ensure that the service accounts they create will not have access to other OpenStack APIs? IIRC the default policy.json files supplied by the various projects allow non-admin operations from any account with a role in the project. thanks, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Marconi][Heat] Creating accounts in Keystone
On 08/23/2014 02:01 AM, Clint Byrum wrote: I don't know how Zaqar does its magic, but I'd love to see simple signed URLs rather than users/passwords. This would work for Heat as well. That way we only have to pass in a single predictably formatted string. Excerpts from Zane Bitter's message of 2014-08-22 14:35:38 -0700: Here's an interesting fact about Zaqar (the project formerly known as Marconi) that I hadn't thought about before this week: it's probably the first OpenStack project where a major part of the API primarily faces Nah, this is the direction we are headed. Service users (out of LDAP!) are going to be the norm with a recent feature add to Keytone: http://adam.younglogic.com/2014/08/getting-service-users-out-of-ldap/ software running in the cloud rather than facing the user. That is to say, nobody is going to be sending themselves messages on their laptop, from their laptop, via a cloud. At least one end of any given queue is likely to be on a VM in the cloud. That makes me wonder: how does Zaqar authenticate users who are sending and receiving messages (as opposed to setting up the queues in the first place)? Presumably using Keystone, in which case it will run into a problem we've been struggling with in Heat since the very early days. Keystone is generally a front end for an identity store with a 1:1 correspondence between users and actual natural persons. Only the operator can add or remove accounts. This breaks down as soon as you need to authenticate automated services running in the cloud - in particular, you never ever want to store the credentials belonging to an actual natural person in a server in the cloud. Heat has managed to work around this to some extent (for those running the Keystone v3 API) by creating users in a separate domain and more or less doing our own authorisation for them. However, this requires action on the part of the operator, and isn't an option for the end user. I guess Zaqar could do something similar and pass out sets of credentials good only for reading and writing to queues (respectively), but it seems like it would be better if the user could create the keystone accounts and set their own access control rules on the queues. On AWS the very first thing a user does is create a bunch of IAM accounts so that they virtually never have to use the credentials associated with their natural person ever again. There are both user accounts and service accounts - the latter IIUC have automatically-rotating keys. Is there anything like this planned in Keystone? Zaqar is likely only the first (I guess second, if you count Heat) of many services that will need it. I have this irrational fear that somebody is going to tell me that this issue is the reason for the hierarchical-multitenancy idea - fear because that both sounds like it requires intrusive changes in every OpenStack project and fails to solve the problem. I hope somebody will disabuse me of that notion in 3... 2... 1... cheers, Zane. ___ 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] [Keystone][Marconi][Heat] Creating accounts in Keystone
I don't know how Zaqar does its magic, but I'd love to see simple signed URLs rather than users/passwords. This would work for Heat as well. That way we only have to pass in a single predictably formatted string. Excerpts from Zane Bitter's message of 2014-08-22 14:35:38 -0700: > Here's an interesting fact about Zaqar (the project formerly known as > Marconi) that I hadn't thought about before this week: it's probably the > first OpenStack project where a major part of the API primarily faces > software running in the cloud rather than facing the user. > > That is to say, nobody is going to be sending themselves messages on > their laptop, from their laptop, via a cloud. At least one end of any > given queue is likely to be on a VM in the cloud. > > That makes me wonder: how does Zaqar authenticate users who are sending > and receiving messages (as opposed to setting up the queues in the first > place)? Presumably using Keystone, in which case it will run into a > problem we've been struggling with in Heat since the very early days. > > Keystone is generally a front end for an identity store with a 1:1 > correspondence between users and actual natural persons. Only the > operator can add or remove accounts. This breaks down as soon as you > need to authenticate automated services running in the cloud - in > particular, you never ever want to store the credentials belonging to an > actual natural person in a server in the cloud. > > Heat has managed to work around this to some extent (for those running > the Keystone v3 API) by creating users in a separate domain and more or > less doing our own authorisation for them. However, this requires action > on the part of the operator, and isn't an option for the end user. I > guess Zaqar could do something similar and pass out sets of credentials > good only for reading and writing to queues (respectively), but it seems > like it would be better if the user could create the keystone accounts > and set their own access control rules on the queues. > > On AWS the very first thing a user does is create a bunch of IAM > accounts so that they virtually never have to use the credentials > associated with their natural person ever again. There are both user > accounts and service accounts - the latter IIUC have > automatically-rotating keys. Is there anything like this planned in > Keystone? Zaqar is likely only the first (I guess second, if you count > Heat) of many services that will need it. > > I have this irrational fear that somebody is going to tell me that this > issue is the reason for the hierarchical-multitenancy idea - fear > because that both sounds like it requires intrusive changes in every > OpenStack project and fails to solve the problem. I hope somebody will > disabuse me of that notion in 3... 2... 1... > > cheers, > Zane. > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Keystone][Marconi][Heat] Creating accounts in Keystone
Here's an interesting fact about Zaqar (the project formerly known as Marconi) that I hadn't thought about before this week: it's probably the first OpenStack project where a major part of the API primarily faces software running in the cloud rather than facing the user. That is to say, nobody is going to be sending themselves messages on their laptop, from their laptop, via a cloud. At least one end of any given queue is likely to be on a VM in the cloud. That makes me wonder: how does Zaqar authenticate users who are sending and receiving messages (as opposed to setting up the queues in the first place)? Presumably using Keystone, in which case it will run into a problem we've been struggling with in Heat since the very early days. Keystone is generally a front end for an identity store with a 1:1 correspondence between users and actual natural persons. Only the operator can add or remove accounts. This breaks down as soon as you need to authenticate automated services running in the cloud - in particular, you never ever want to store the credentials belonging to an actual natural person in a server in the cloud. Heat has managed to work around this to some extent (for those running the Keystone v3 API) by creating users in a separate domain and more or less doing our own authorisation for them. However, this requires action on the part of the operator, and isn't an option for the end user. I guess Zaqar could do something similar and pass out sets of credentials good only for reading and writing to queues (respectively), but it seems like it would be better if the user could create the keystone accounts and set their own access control rules on the queues. On AWS the very first thing a user does is create a bunch of IAM accounts so that they virtually never have to use the credentials associated with their natural person ever again. There are both user accounts and service accounts - the latter IIUC have automatically-rotating keys. Is there anything like this planned in Keystone? Zaqar is likely only the first (I guess second, if you count Heat) of many services that will need it. I have this irrational fear that somebody is going to tell me that this issue is the reason for the hierarchical-multitenancy idea - fear because that both sounds like it requires intrusive changes in every OpenStack project and fails to solve the problem. I hope somebody will disabuse me of that notion in 3... 2... 1... cheers, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
