18:00:51 #startmeeting 18:00:52 Meeting started Tue Jul 31 18:00:51 2012 UTC. The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:53 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:04 Okay - let's get this ball rolling 18:01:41 http://wiki.openstack.org/Meetings/KeystoneMeeting 18:01:56 #topic domains 18:02:02 ayoung was gracious enough to get us an agenda set up 18:02:26 * ayoung has to leave at about 1:45..so in a bit of a hurry 18:02:28 ayoung: what's the domain topic? 18:02:30 np 18:02:50 heckj, OK, so Domains is gyee's bailywick. I figured we should sort out what we are doing with them 18:03:06 My take is: get them in in a minimal format 18:03:09 no groups 18:03:22 and first we need an agreement of what is acceptable/expected 18:03:29 ayound: adding as extension to V2 API, or dependent on V3 API? 18:03:41 not sure if anyone have a chance to look at my draft review 18:03:56 gyee, have you changed it recently? 18:04:00 no 18:04:02 I've glanced over it, but not read in depth 18:04:08 why change it, its perfect :) 18:04:39 #link http://etherpad.openstack.org/keystone-domains 18:05:11 gyee, since we are not doing a formal V3 for Folsom anyway, are you OK with doing it as an extension? 18:05:14 adding domains as an extension to V2 API isn't an issue, but changing the token format and output would be a significant API change - which I believe is needed to make it useful to external services 18:05:19 We can migrate Extension to V3 in Grizzly 18:05:30 sure 18:05:38 as of know, the code is parked in contrib 18:05:40 now 18:05:43 good 18:06:02 so are we OK with the current impl? 18:06:09 OIK, so my understanding is that each user and tenant is owned by exactly one domain 18:06:13 I heard rejection city the last go around 18:06:35 gyee, I heard arguing over details, but I think that we were close to consensus 18:07:04 FYI... Guang's implementation would support the single-home user RBAC model, i.e., a user may have only one home domain. 18:07:15 http://etherpad.openstack.org/KeystoneRoles 18:07:33 right 18:07:39 It's unclear that users need to be fully segmented as well - using the policy engine, we can get the same enforcement 18:08:15 heckj, I see this as more "the eggs Policy usese to make omlettes" 18:08:20 if we have the domain_id in the users, we can easily implement isolation 18:08:27 you have to put a user "somewhere" 18:08:34 and with the V2 API, the "admin" has uber-rights over everything 18:08:34 once we put them there, they stay there 18:08:55 heckj, with my impl, domain admin can control their own domain 18:09:07 domain admin is a role 18:09:29 Yep - not asserting what your code does, asserting what current code and V2 API expectations are 18:09:33 meaning user from one domain can have the domain admin role in multiple domains 18:10:30 we are not doing anything outside the realm of RBAC 18:10:55 heckj, is the question "a mechanism that is domain specific" versus "a mechanism based on the policy impl?" 18:11:15 IE, we can implement the domain spec using the policy code? 18:12:24 (in V3) I think we have everything we need to enforce the domain admin needs even down to users using policy 18:12:44 My primary concern with gyee's current extension/V2 work is that I don't think we can meaningfully make this a V2 API extension 18:12:55 If we start changing responses to the API, we'll get a lot 18:13:05 of pushback that the API needs to be revised/revisioned 18:13:18 (recent conversations related to changing the API and what that means to versioning) 18:13:20 heckj, agreed that we are too late to do modifications of V2 APIs 18:13:29 I think that domain is a core concept and should be part of the core, rather than an extension... It is messier as an extension. 18:13:39 liemmn, yes, but not until V3 18:13:43 yep 18:13:47 liemmn: I'm totally with you - and I think it needs to flow all the way out ot all services (nova, glance, etc) 18:13:50 hence, voting for v3 18:13:58 (as core) 18:14:13 I really appreciate gyee's work, but I think we'd be better getting identity wrapper and moved in a V3 API and get started with impl there 18:14:34 I am OK with V3 18:14:39 but we have to have user isolation 18:14:56 which means domain_id in users 18:15:17 gyee, so long as it is an attribute, and not in the URL that should not break anything 18:15:36 I think that meets the letter of the law WRT dkranz's policy doc 18:15:37 right 18:15:53 domain_id is an attribute of user, just like tenant 18:16:39 gyee, so do you have enough to get a new impl out for review? 18:16:47 keep in mind that having domain_id in user does not prevent user from *assigning* to tenants 18:16:57 gyee: I'm asserting that you can and do have domain isoliation of users with a reasonable use of policy.json. I don't think it's critical to enforce it in the data model as well 18:17:09 With domain model + domain_id on user, I think we can implement the user isolation as described in the KeystoneRoles doc ("single-home user" option) 18:17:23 ^^^ what he said 18:17:23 gyee: Error: "^^" is not a valid command. 18:18:10 heckj, so to add a new domain, we would need to update policy.json ? 18:18:20 I am ready to rock n roll if you guys are cool with it 18:19:16 ayoung: not at all - just add a role & rule in policy.json that to add a user, reset a user, etc you need to be the domain admin for relevant tenants 18:19:40 heckj, I think that domain_id would be default to null for most deployments, but be in the data model to be used in "multi domain deployments" 18:20:07 If the implementation you have completey segregates tenants and users are in tenants, you can use the default_tenant_id to determine the appropriate domain to use to verify for password resets and such 18:20:58 heckj, but tenants can't be nested, and thus we don't have an organizational mechanism for tenants/ 18:21:02 ayoung: if it's null, then it can't be mandatory. If it's optional, then what's the difference between it and using the domain assocaited with the default tenant? 18:21:24 ayoung: in this first cut, they can't be nested - but I think we all agree that we want to enable that in a future round 18:21:25 heckj, have default_tenant_id as domain_id, we are essentially overloading the meaning of default tenant 18:21:28 not very flexible 18:21:51 and confusing 18:21:55 heckj, I provided an argument against using default tenant for linking domain in the KeystoneRoles document. 18:21:56 gyee: I absolutely do not want to overload a value 18:22:07 default tenant is for scoping the token. domainId is for isolating the user 18:22:09 amen 18:22:12 I'm happy using them as a chain to look up relevant data, but the meaning of an attribute has to be crisp and clear 18:22:40 so what's the problem with having domain_id and default_tenant_id as separate attributes? 18:22:43 that's very clear 18:23:09 I think that is overloading the usage of default tenancy. If I understand correctly, default tenancy is used for the purpose of authentication if a tenant is not specified. A default tenant is also optional. A user's "home domain" is not. A user (except for a super-admin) must always have a "home domain." So, I decided to introduce the concept of "home domain" for better separation of concern and enforcement of immutability. To 18:23:09 answer your question: 18:23:09 1) "can a user have a default tenant but a null home domain?" -> No, a user (except the super-admin) always has a home domain. 18:23:10 2) "can a user's default tenant not belong to the user's in the user's home domain?" -> Yes, in the given proposal, user's default tenancy and home domain are 2 separate concerns. For example, I have a guest tenancy in domain B and a home domain A. However, whenever I log on, I always want to log onto the guest tenancy I have in domain B. Therefore, I will set my default tenancy to guest tenancy in domain B. 18:23:17 gyee: that is clear - are you OK with asserting that domain_id is optional and can be null? 18:23:17 (cut-and-paste) 18:23:31 I am OK with it being "null" 18:23:44 gyee: and thereby being also optional? 18:23:47 deployment does not use domain doesn't need to set a domain_id 18:23:54 heckj, I would state that for all domain_id = null we assume the default domain. 18:24:05 As opposed to any chained lookup 18:24:15 sounds good 18:24:19 it is an all or nothing thing... if it is used in a deployment, it is a mandatory field 18:24:21 Maybe we can create a configuration to specify if the deployment is a "domain-aware" deployment (similar to PKI, for example)... If it is so, we will need to enforce non-null domainId when creating a user. 18:24:33 +1 18:24:38 +1 18:24:39 ayoung: inconsistency is going to bite us there 18:24:58 It's a deployment option. 18:25:08 I am OK with that 18:25:15 liemmn: and you're arguing to encode deployment options in the data model, which I'm not OK with 18:25:19 heckj, you mean there is the potential for an inconsistnacy between the domain of the user (null) and the domain of the default tenant? 18:25:24 data model is always there. 18:25:27 ayoung: yes 18:25:45 heckj, I would say that is an acceptable setup in some cases 18:25:51 enforcement of non-null domainId is there... For a domain-aware install, a user without a domain does not make sense. 18:25:54 say a migration scenario 18:26:01 I'm ok with adding a domain_id attribute to the user *if* we assert it can be Null, and therefore is an optional attribute based on backend driver 18:26:02 where a domain was not used in the past 18:26:14 hackj, +1 18:26:22 heckj, my bad 18:26:23 heckj, I can buy that 18:26:28 no 18:26:29 np 18:26:33 now I can't type 18:26:39 :) 18:26:53 gyee spreaded the can't type bug 18:27:07 OK. gyee can you write up what we agreed on here in a couple short sentances and we';; # action them? 18:27:09 its my middle finger 18:27:30 ayoung, you got it 18:28:30 heckj, OK to move on to PKI? 18:28:45 ayoung, for migration from a non-domain deployment to a domain-aware one, we will need to lob all those users into some sort of default domain... 18:28:52 liemmn, exactly 18:29:24 liemmn: +1 18:29:26 so there might be a point where a default tenant is part of a domain, but the user isn't or some other weirdness 18:29:27 ayoung: yep 18:29:30 #topic PKI 18:29:45 first up is location of the cached certs 18:29:58 it came to my attention that sticking them in /tmp is a no-no 18:30:29 there is a potential elevation of privs: say a user on the Keystone system gets to /tmp/keystone-blah ahead of time 18:30:34 and sticks in their own cert 18:30:48 then they can authenticate using a bogus token 18:31:09 So the question is what should the default be? 18:31:16 ayoung: any way we can make that a configurable option? 18:31:23 heckj, it is already 18:31:36 ayoung: ah, we're just talking about sensible default then 18:31:37 the question is what should the default be, 18:31:43 yep 18:31:48 proposal: /var/lib/keystone 18:31:50 ? 18:31:58 I think /var/cache is slightly more correct 18:32:05 but then the issue is the user name 18:32:06 so 18:32:23 what's the issue with user name? 18:32:26 /var/cache//keystone-certs 18:32:31 gyee, OK possible race condition 18:32:44 assume that there are two services running as the same user, say nova 18:32:51 and both get a request at the same time 18:33:03 one fetches the certs, and starts writing 18:33:17 the other tests for existence of the files, which succeeds, and attempts to validate 18:33:28 ayoung: I'm ok with /var/cache - sounds like you've got to deal with the async race regardless of directory 18:33:28 validation will fail since they only have say, half a cert 18:33:55 heckj, so, will /var/cache be acceptable across the distros? 18:34:04 There is nothing in there right now 18:34:33 ayoung: as far as I know, yeah - I'd poke a quick question at adamg or zul in #openstack-packaging if you want an ubuntu check 18:34:38 we'll have to modify any install process to make a writable subdir in there 18:35:01 and I am not sure the correct general mechanism to do that 18:35:13 so lets take that as a #action? 18:35:28 ayoung, you can use a touch file to specify that a cert has been written completely. 18:35:39 liemmn, yep 18:35:46 ayoung: sounds reasonable 18:36:33 liemmn, maybe even the cert fingerprint.... 18:36:43 +1 18:36:54 we use fingerprint for out-of-band validation as well 18:37:07 #action use the cert fingerprint as a touch file to indicate download has completed 18:37:13 yep 18:37:16 heckj, can I get ops to post? 18:37:37 ayoung: I'm being dense. "ops to post"? 18:37:45 or, better yet, you repost my #actions, that way I get spellcheck :) 18:37:51 Ah! 18:38:03 #action ayoung to 18:38:09 #action ayoung to use the cert fingerprint as a touch file to indicate download has completed 18:38:11 heh 18:38:16 you're going to hate this 18:38:53 #action check with adamg or zul in #openstack-packaging about use of /var/cache for certificates 18:39:00 #action: ayoung to touch base with Zul/AdamG (or IRC #openstack-packaging or mailing list in general) to check on suitability of /var/cache/**/ directory creation on install 18:39:13 heckj, you are wrong. I love this 18:39:23 heh 18:39:31 more on PKI? 18:39:42 OK...let me come back to acceptance criteria... 18:39:46 two quick matters 18:39:55 #action: add domain_id as optional attribute to V3 API model on users 18:40:26 one, I've been told that the enable/disable for pki config options are poorly named 18:40:35 they don't like my double negatives 18:40:49 so I am thinking: token_format = PKI | uuid 18:41:04 heckj, is the /v3 path implemented, where am I going to park the domain code? 18:41:22 with uuid being the equivalent of the current default 18:41:44 gyee, do you mean in the future? 18:41:50 near future 18:41:56 I would assume it would have to be part of the identity provider 18:42:43 gyee: It's be under the identity provider for a V3 api route 18:42:52 oh ok 18:43:04 OK, I have to disappear 18:43:40 ayoung: ciao 18:43:59 I'll start an etherpad for Summit sessions. 18:44:16 We can argue there and get it down to areasonable number 18:44:44 unless there is a better suggestion? 18:45:30 OK...I'm gone. I'll beat you guys up over the rest of the Agenda items in #openstack-dev 18:46:08 kk 18:46:18 Other topics/issues? 18:48:03 v3 api 18:48:06 (DELETE) /users/{user_id}/roles/{role_id} ==> delete_role_from_user 18:48:31 if I assign the same role to multiple tenants, which role is the above deleting? 18:48:54 all of them? 18:49:31 unless the tenantId is part of the payload somewhere 18:49:48 but, that's not very restful 18:49:48 right, same for domain roles as well 18:50:16 gyee: good question 18:50:35 Also... we need an update API for credentials (my feedback on draft#3) 18:51:08 so, to allow update to an access key, for example (enable/disable) 18:52:18 speaking of access key, we are ready to start on the tempURL impl 18:53:22 I've got to run... Later, heckj 18:53:36 gyee: I believe so 18:53:53 liemmn: I'll hit a draft update this week/weekend if nothing else 18:54:13 then how do we remove just a tenant-role association? 18:54:26 or domain-role association 18:55:47 gyee: we should totally be able to do that - I need to re-read that section to see what the hell I was thinking 18:56:14 oh ok :) 18:56:26 yeah - very distracted right now 18:56:42 Im going to wrap this up 18:56:45 #endmeeting