18:00:39 #startmeeting Keystone 18:00:40 Meeting started Tue Jan 13 18:00:39 2015 UTC and is due to finish in 60 minutes. The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:41 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:43 o/ 18:00:44 The meeting name has been set to 'keystone' 18:00:55 Good morning! Quick housekeeping. 18:00:58 o/ 18:01:12 Next week no irc meeting, mid cycle instead. 18:01:17 hello 18:01:39 midcycle should have a hangout... just saying.. 18:01:39 I will try and setup a hangout (Google) for one of the days to get folks not in San Antonio involved 18:01:43 yay 18:01:50 \o/ 18:01:52 But no guarantees it'll work. 18:01:57 \o 18:02:15 morganfainberg: would be appreciated 18:02:24 o/ 18:02:33 If you haven't voted on the board of directors and bylaws changes. Go do it. 18:02:36 morganfainberg, turns out monday is MLK holiday 18:02:44 hi 18:02:47 It is really really important to get votes. 18:02:59 o/ 18:02:59 gyee: working holiday for us! :P 18:03:00 yeah, we really need the voter turnout 18:03:16 gyee: oops 18:03:33 I'm a little lost: where is this voting? 18:03:38 hahaha 18:03:40 gyee I've already booked my flight 18:03:49 amakarov: if you're a foundation member, you'll have an email with a personalized voter link 18:03:49 So please vote. If you are a foundation member and didn't get a ballot (and have been since July 20 2014) make sure you contact secretary@openstack.org for your ballot link 18:04:11 email subject is "OpenStack Foundation - 2015 Individual Director Election" 18:04:20 amakarov: if you joined the foundation on or before July 20, 2014 18:04:30 You should have gotten that email. 18:04:40 morganfainberg, dolphm ok, I'm too young )) 18:04:41 I missed it. Are you recommending particular folks? 18:04:41 but it's not just a director election, there are proposed changes to the bylaws 18:04:51 o/ 18:04:57 Topol no, just go vote. 18:04:59 any recommended bylaw changes? 18:05:06 topol - lol 18:05:12 morganfainberg OK 18:05:15 Oh, is it that time already? 18:05:19 topol, yes, yes, and yes 18:05:25 Read them, I won't recommend yes or no on any director or bylaw changes. 18:05:53 Big tent, lawyer count, and % of community for bylaw changes are he resolutions 18:06:58 #info vote on board of directors and bylaw changes if you are eligible. 18:07:15 #info Spec proposal deadline for keystone: feb 5 18:07:27 Get your specs proposed and approved. 18:07:36 Last bit of house keeping. 18:07:58 I'd like to propose a code-feature proposal freeze 2-weeks prior to k3 18:08:29 Meaning no feature code after that mark. Will help limit last minute breaking things before feature freeze 18:08:38 Any complaints or concerns? 18:08:47 sounds very good 18:08:51 ++ 18:08:52 that sounds good to me 18:09:02 sounds good to me 18:09:04 amakarov, ++ 18:09:06 so it is a proposal freeze or an actual code freeze 18:09:09 so that's a code feature freeze and not a code feature proposal freeze, right? 18:09:15 ha! 18:09:20 henrynash: code freeze for new features. 18:09:25 so we will officially enter bug mode two weeks before k3 18:09:30 ok 18:09:32 lbragstad: correct. 18:09:37 joesavak: code freeze 18:09:44 s/code/feature/ 18:09:44 +1 18:09:59 It gives us a window to fix anything outstanding on features but limits rebase hell 18:09:59 +1 18:10:00 I think Jenkins freeze happens 4 weeks before :) 18:10:09 I thought we were going to be more forgiving than that 18:10:18 we used to say "Milestone 2" 18:10:29 and with the spec adoption, I thought we were going with Milestone 3\ 18:10:34 ayoung: we are now saying 2-weeks prior to hard feature freeze 18:10:53 Just so we can limt rebase hell and last minute "omg we broke everything" 18:11:07 morganfainberg, does that mean that the review must be submitted, or that the review must be accepted and merged? 18:11:15 cuz we have so little time and so much process 18:11:32 Must be gating or ready to gate. This is milestone 3 18:11:42 Not milestone 2 18:11:53 I understand 18:12:32 Heh, you can't get anything through Gate during M3 week anyway 18:12:38 Basically get your code ready to merge by 2-weeks prior to feature freeze. If we get most stuff done there, we will have less headaches to fight the gate at 1day before m3 18:12:53 Exactly. 18:13:07 We can revisit next week on Monday. 18:13:12 On to topics. 18:13:27 #topic OS-INHERIT 18:13:33 henrynash: o: 18:13:37 O/ even 18:13:53 actuall I think samuel was rasing this one... 18:13:58 Ack, battery is about to die, running to my desk. 18:14:05 Ok samueldmq o/ 18:14:07 :) 18:14:25 hi :) 18:14:35 so we have one proposal regarding role inheritance 18:14:56 currently we have OS-INHERIT:inherited_to: ['projects'] 18:15:19 this is in the spec, but we have implemented as OS-INHERIT:inherited_to: 'projects' (without list) 18:15:50 but instead of just fixing the spec, I was thinking about removing inherited_to: ['projects'], and keep just inherited=True/False 18:15:52 (that’s what gets returned by list_role_assignments to indicated that an assigment is inherited) 18:16:15 henrynash, ++ 18:16:27 or passed to list_role_assignments to apply filtering 18:16:44 so a little background for everyone 18:16:57 I think we need to go with changing the spec to match the code... openstack rules. 18:17:22 why's there a list to begin with? we have something other than projects in mind? 18:17:26 bknudson, yes, that would be the first step, to get consistency asap 18:17:29 if you remember when I first proposed inheritance from domain->projects we had a long debate about how “inheritanc” should work 18:17:51 make domain is-a project and that issue goes away 18:17:56 if we don't have anything else, true/false make sense 18:18:00 I don't think we can go changing the spec to inherited=True/False since that's against the stability rules. 18:18:13 bknudson: ++ 18:18:26 plus I think it's a poor design choice to use a boolean where a more descriptive string would explain things. 18:18:32 bknudson, we don't even support role inheritance on the clients I think (will recheck) 18:18:33 gyee: with domain is a project, we need to inehrited to - subdomains 18:18:52 so we update the spec to OS-INHERIT:inherited_to: 'projects' right? 18:19:03 does it give any actual benefits? 18:19:03 at least one person was concerned that we might need more than just “inherit down the tree”..ans we might, in the future, want “directed inheritance”…i.e. OS-INHERIT: inherited_to : [“project_id”: 123, “project_id”:564] 18:19:05 I like that 18:19:11 samueldmq, we don't 18:19:18 rodrigods, thx 18:19:22 the change to add support to inheritance in keystoneclient is under review 18:19:23 henrynash, that's more flexible 18:19:29 gyee: so I think that we need to create a OS-INHERIT:inherited_to: 'domains' or something like that 18:19:41 raildo, nah 18:19:49 domain is-a project means we don't need it 18:19:51 so since we don't even support role inheritance on the clients, and it's still an extension, I don't see a big concern on changing the API 18:19:55 ayoung, ++ 18:19:55 lets drive that one home instead 18:20:04 domain -> special project 18:20:04 ayoung, i agree, if we push domains == projects, this issue goes away 18:20:20 morganfainberg, and we need to get that working for HMT anyway 18:20:26 ayoung, yes 18:20:49 raildo, and rodrigods are going to take a hack at it from my WIP 18:21:05 I personally think that anying other than “inheritance down the tree” plus teh ability of a node to block inheritance is about as much as any adminstrator will be able to cope with 18:21:06 henrynash, I like the inherited_to : [“project_id”: 123, “project_id”:564] 18:21:07 ayoung:but if I inherited a role in all subdomains, i broke the reseller, because a user in a parent domain can manager users in a subdomain 18:21:26 henrynash, ++ 18:21:52 Ah... 18:21:59 raildo, that should be solved by what henrynash just proposed 18:22:07 raildo, a flag to block inheritance 18:22:14 OS-INHERIT:inherited_to: 'not projects' 18:22:19 er 18:22:20 ayoung: so while directed inheritance sounds kind of cool…if you really had complex usage model of that……would an admin have any clue what was going on? 18:22:22 OS-INHERIT:inherited_to: 'not domains' 18:23:03 henrynash, depends on the quality of the admin, as always 18:23:04 inherited_to would have to be a dict. 18:23:31 ayoung, may it be just omitted? 18:23:36 bknudson, we should be able to handle both a single value and a dict 18:23:42 an alternative would be to shelve OS-INHERIT and make inheritance a first-class part of the assignment api 18:23:47 amakarov, no, 18:23:53 OS-INHERIT would be maintained as is for legacy/compat 18:23:54 things never change, people always fight over inheritance :) 18:23:59 amakarov, they need to say "inherited to projects that are not domains" 18:24:11 #link the spec as it is today http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-inherit-ext.html#list-effective-role-assignments 18:24:19 this feels like a more complex topic given everyone’s views…sounds like we might want to have asession on this next week 18:24:26 samueldmq, API spec 18:24:26 ayoung, reminds 'redelegation_count' :) 18:24:31 amakarov, yes. 18:24:45 amakarov, comparable, but different 18:24:48 henrynash, ++ 18:24:55 henrynash: +1 to all your comments here 18:26:03 if we do have directed sessions like that i'll work to make sure we have a hangout for those 18:26:07 as well. 18:26:14 ++ 18:26:16 esp since iirc samueldmq isn't there 18:26:16 the short, though, is that we should update the spec to match the code at a minimum, right? 18:26:31 ayoung, or ^^ my suggestion there [more work though] 18:26:48 ayoung, but the spec will need to match the code if we keep it in OS-INHERIT 18:26:53 morganfainberg, I think anythinig beyond what the code does today should be future work 18:26:56 ayoung: at a minimum, yes… 18:27:03 ayoung, correct 18:27:14 ayoung, minimum spec needs to match code 1st 18:27:26 if we have to update the spec because of the code, the process is somewhat broken isn't it? 18:27:29 having them out of sync is problematic. Since we have released code, lets agree to first update the spec, second solve the problem for the duration 18:27:38 gyee, some of this documentation was out of sync 18:27:40 morganfainberg, so I'll submit a patch to fix the api spec 18:27:47 samueldmq, ++ 18:27:50 gyee, this is a case where we keep contract with functionality 18:27:52 morganfainberg, and then we decide further next week 18:28:01 gyee: well, only because we shipped that code 2 releases ago! 18:28:09 oh 18:28:11 gyee, and ^^ what henrynash just said 18:28:15 * gyee stfu now 18:28:19 gyee, this is API spec not new-code spec 18:28:47 gyee: i wouldn't expect an unimplemented spec to be "final" until it has shipped as stable/* 18:28:49 #action samueldmq to update API spec to match actual code. 18:28:56 dolphm, ++ 18:28:57 unimplemented api* spec 18:28:59 I know that Chadwick's new Postdoc is somewhere in Brazil, but I assume it is too much to hope he is anywhere near the rest of you guys, is it? 18:29:22 yes 18:29:25 ayoung, lets discuss that in -keystone post meeting, we have a full agenda 18:29:32 moving on 18:29:35 #topic Multifactor Authentication 18:29:37 dolphm, in that case, would it make send to write the code first, then change the spec 18:29:38 nonameentername, o/ 18:29:48 s/send/sense/ 18:29:56 o/ 18:30:01 gyee, that is the point of the experimental -> stable workflow 18:30:05 gyee, for new stuff. 18:30:23 anyway, nonameentername floor is yours 18:30:39 morganfainberg, so with MFA, it seems like he first should be submitting a patch for OTP, no? 18:30:55 I wanted to get some eyes and feed back on my spec. It had a lot of possitive reviews but then died down 18:30:56 #link https://review.openstack.org/#/c/130376/ 18:31:52 This is defintely on the list of specs to hit while at the mid-cycle, but i think most of the major concerns have been addrressed. 18:32:13 how does an auth plugin require another plugin (e.g., the otp plugin requires password plugin)? 18:32:19 nonameentername: I know marekd had a bunch of questions before the holidays, but you addressed those? 18:32:32 also, should the otp plugin require password? what if I wanted to use something better? 18:32:50 oh, it's going to do both. 18:32:51 where do we store the seed/secret? 18:32:56 cred api? 18:32:57 lbragstad: he wanted me to add api information, but I don't know if that belongs in the spec or if it should live in the identity-api project 18:33:12 bknudson, right now the architecture doesnt support requiring a plugin from another plugin, but a user can request multiple plugins 18:33:28 it would be interesting to see barbican integration with credentials. 18:33:38 gyee, i am pushing for barbican in general 18:33:44 as an option 18:33:58 bknudson: yes, that is part of the spec 18:34:02 bknudson: the v3 plugins are designed so that there can be multiple 'methods' just nothing uses it at the moment 18:34:04 bknudson, +∞ 18:34:14 I thought we already had support for multi-factor authentication in the original auth plugin design. 18:34:24 bknudson, sortof. 18:34:30 bknudson: you could write a plugin that essentially does multiple methods for you 18:34:34 bknudson, this is the plugin itself 18:34:39 not the framework 18:34:58 gyee ++ 18:35:03 MFA can be implementd in so many ways 18:35:07 bknudson, nonameentername wants to enforce that in cases MFA is used [sometimes for all authentications], which today isn't there. no plugin for it. 18:35:12 if this is just proposing another plugin then that seems to be different than what the spec says. 18:35:46 bknudson, the spec is mostly implying a new auth-plugin 18:36:02 password = pin + one time hash code 18:36:13 bknudson, but also proposing the framework change to allow a demand of multiple plugins for auth 18:36:17 bknudson, vs only on user request 18:36:36 bknudson, so you can say "user X must use MFA" vs "did user X use MFA" 18:36:37 gyee: is that how pam implements otp? 18:36:47 bknudson, depends on the OTP. 18:36:49 morganfainberg: ++ 18:36:50 so the question is whether the rule should be "no token without MFA" enforced by auth pipeline or "this API requires MFA" enforced by policy/ 18:36:53 bknudson, that's how google authenticator works afaik 18:36:57 the first is easier 18:37:07 I had a prototype on that awhile back 18:37:09 ayoung, this is allowing for the first case 18:37:20 ok, I just wanted to understand it... I don't have a problem with the proposal. 18:37:22 ayoung, and providiung the plugin. 18:37:41 ayoung, the latter case is in the token-constraints type spec 18:38:08 ayoung, or part of policy language+middleware to expose 18:38:12 bknudson, ack 18:38:12 so this is going to cause all sorts of problems with reauthentication 18:38:24 reason I didn't propose the google authenticator change was that I was under the impression we are not going to do anything with IdP till we separate the identity piece from Keystone first 18:38:37 it's not useful for any sort of automated service, are we mostly just considering horizon here? 18:38:45 auth pipeline right now is "or" and this calls for "and" 18:38:45 jamielennox: good point... token only lasts 30 mins so I'll need to look at my keyfob again. 18:39:03 jamielennox, this is why it needs to be per-user. service users may not need/get it 18:39:05 jamielennox, MFA that is 18:39:22 jamielennox OR the service consumption would need to know how to do OTP for re-auth. 18:39:31 so then we also need a mechanism to store per user which auth is required. 18:39:34 morganfainberg: right - didn't expect them to, i'm just wondering how the flow will work 18:39:36 morganfainberg, right, MFA is generally bad for non-interactive users 18:39:48 it also means that our clients need to start actually caching authetnication 18:39:50 jamielennox, please comment on the spec, that is where this should be defined. 18:39:54 jamielennox, ++ 18:40:15 lets get the comments in order so we can get this landed monday/cleaned up ready on mondy 18:40:36 * topol just saw morganfainberg do +∞ and thought that is really cool 18:40:41 i think the major hurdles are solved in the proposal, now it's the "here are all the things that could be affected, lets not forget it" 18:41:32 as in the proposal is good. but we have associated functionality that would be impacted and can't be forgotten 18:41:42 use federation instead. 18:41:56 so does this mean that we are adding a per user auth column/table? 18:42:08 no 18:42:19 it should be on assignment, not on the user side 18:42:41 dstanek, you don't need to, you can have policy around auth methods 18:42:47 specifically "in order to get a token for this role in this project, use needs to authentiate iwht F1, F2" 18:43:07 ayoung: that makes sense - so on a per assignment basis 18:43:55 dstanek, ayoung, i think that makes a lot of sense 18:44:01 you can get a token with any method, but you may not be able to access certain apis with that method 18:44:06 i need to go back and read the spec again - it's been a while 18:44:09 lets comment on the spec. 18:44:15 with mod_shib can you put in a constraint on how the user authenticated? 18:44:19 we need to move on, still a lot to cover 18:44:27 bknudson, i think that falls into how the IDP auths 18:44:32 thanks 18:44:34 bknudson, idp would enforce MFA or not 18:44:47 #topic Domain Config 18:44:48 we need to cleanly separate out authn and authz 18:44:48 you could almost make it a property of the role 18:44:52 #link https://review.openstack.org/#/c/123238/ 18:45:06 henrynash, o/ 18:45:12 ok, so reminder on domain configs - this is to enable clouds admins to on-board a customer into a domain who has their own ldap settings...letting them doing it all via REST, rather than having to set up those hokey domain-specifc config files that I dreamt up a while back 18:45:24 intention is that we will deprecate the domain-specific config files, but still support for 2 release 18:45:25 henrynash, i support this change! 18:45:34 Most people seem OK on the spec, but wanted to see what the API might look like 18:45:40 so have prepared the simplest version: https://review.openstack.org/#/c/123238/10/api/v3/identity-api-v3.rst 18:45:54 but wanted to see what peopel thought about that vs alternatives 18:45:57 henrynash, you just inherited the hokyness from my LDAP config. 18:46:18 playing hokey was always good fun 18:46:18 that's what its all about. 18:46:19 I'm just glad we dropped XML support. 18:46:23 ha! 18:46:53 so the simpel proposal just puts the config as an attrivute in teh domain entity 18:46:59 feels a bit weird, but simple 18:47:00 bknudson, not quite, SAML2 assertion 18:47:25 so...domain config in SQL by itself makes sense. The question is does maintaining LDAP as a mapping separate from the way we do federation make sense? 18:47:27 alternative would be to perhaps suppost somthing a bit liek nova’s server details, i.e 18:47:34 henrynash: so, you're expecting ldap passwords and stuff to be in the API? 18:47:41 GET /domains/{domain_id}/config 18:48:05 dolphm: nice point 18:48:42 may want to do another survey to see how many LDAP out there are password protected even for searches 18:48:45 dolphm: would have to be the encrypted version 18:48:49 gyee, surveys are sent. 18:48:59 gyee to all three MLs 18:49:01 henrynash, or template of some sort 18:49:07 password protected LDAP searches specifically? 18:49:11 gyee, lets see how those retuern before asking about passwords 18:49:16 k 18:49:17 ldap passowrds are ONLY reequired if anonymous searching is not supported 18:49:23 dolphm, this can also be brokered by credential/barbican 18:49:24 henrynash, with 'the stuff' to be inserted locally 18:49:33 otehrwise, no passwords needs 18:49:35 I personally have not came across anything like that 18:49:40 gyee, we have to assume that there is a high lilkyhood that the user to do the LDAP query needs to be authenticated somehow 18:49:47 gyee, AD often does require bind to search 18:49:51 ayoung, unlikely 18:50:09 gyee, its common to require some authentication 18:50:14 even if it is just a service user 18:50:26 gyee non-anon bind that is 18:50:34 not for searches 18:50:37 something about SOCKS compliancy. 18:50:41 it was a requirement we had to implement in FreeIPA 18:50:42 gyee, yes. i've seen it. 18:50:52 I assume gyee is talking about large corporate directories... the one I know about doesn't require auth. 18:50:59 gyee almost every AD integration we did at metacloud needed a user/pass to bind for searches against AD 18:51:05 yes, happens all the time due to regulations 18:51:45 SOX compliance? 18:51:47 in anycase henrynash, i think we need credential API support or barbican support for this. 18:52:05 SOCKS! toe socks comp... sorry i'll stop 18:52:08 so I had assumed we would use the same encyption technique taht we do in the config files. 18:52:14 SUCK compliance :) 18:52:17 SUCKS 18:52:37 henrynash, i think we should discuss this at the midcycle as well specifically on the security and password concerns 18:52:37 morganfainberg: meaning you store the ldap creds and then fill it in “on teh backend” 18:52:39 config files aren't encrypted 18:52:55 bknudson: but I think the password is, no? 18:53:02 henrynash, not really. 18:53:04 henrynash: when pulling out the config from SQL would you whitelist what can be return or blacklist passwords, keys, etc? 18:53:17 obfuscated 18:53:46 gyee, not enough 18:53:47 dstanek, this is why i think it needs to go in credential or barbican - something we can be more watchful of 18:53:58 morganfainberg: ++ 18:54:06 dstanek: we certainly could (in teh same way we do with the user record) 18:54:13 * morganfainberg comments on needing to "fix" credential 18:54:14 I think wee punt on this henrynash . We kindof want to go a different way 18:54:29 since we can stick anything in credential or policy backend, put the config file in there. 18:54:30 And it avoids all these issues 18:54:31 ayoung: on which bit? 18:54:38 amakarov, did oslo.config have the secured option? 18:54:44 bknudson, that might be the easiest solution 18:54:45 if we say "non trivial LDAP is done using SSSD and Federation" 18:54:52 ayoung, that is a separate discussion 18:54:58 ayoung, but related 18:55:06 gyee: what's your definition of secured? 18:55:06 morganfainberg, it is an argument against his proposal 18:55:08 this is something we'll need to discuss at the midcycle. 18:55:16 oslo.config has a secret=True option but that just means it's not printed out when debug the config. 18:55:16 and I don't want to just say "no" without explaining why 18:55:20 we have 5 mins, so lets table 18:55:24 and discuss next week 18:55:28 gyee, don't know 18:55:33 ideally, LDAP would be just another form of Federation 18:55:38 ok, sounds like yamd (yet another midcylce discussion) 18:55:54 krykowski, o/ 18:56:04 hi :) 18:56:06 #topic Keystone upgrades implementation status and known problems 18:56:09 lbragstad, I thought oslo.config have an secured property for a config option, no? 18:56:14 I wanted to ask if Keystone is going to adopt oslo.versionedobjects? any status on that? 18:56:15 this is short i know, but wanted to get you a couple minutes 18:56:26 krykowski, not in kilo 18:56:46 krykowski, but i'd like to see it on the table and evaluated for L. 18:56:50 are there are plans for it to land? a spec for example? 18:57:05 krykowski, no spec yet. there hasn't been any real discussion on it 18:57:40 got it, you probably seen that there is already a spec in Heat to adopt this, to be ready to handle such updates 18:57:45 #link http://specs.openstack.org/openstack/heat-specs/specs/kilo/versioned-objects 18:57:47 i'd be happy to see some discussion occur in #openstack-keystone on it (please come and bug us!) so it can be made a priority/or determine why it wont work for L-cycle 18:57:59 in keystone 18:58:10 ayoung, if we use SSSD, we have to make CMS a hell lot easier 18:58:21 unless SSSD can dynamically reload the config files 18:58:33 henrynash, we can also continue discussion on it in -keystone today/this week 18:58:36 gyee, heh...exactly what I was wondering myself. 18:59:04 krykowski, so i think the option is there, but it wont happen in Kilo, if we have the discussion now we can prioritize for L 18:59:10 krykowski, is the answer to your question 18:59:11 morganfainberg: yep, good…tomorrow..for me 18:59:29 ok last thing to be said 18:59:30 krykowski: are you asking if keystone would approve use of oslo.versionedobjects, or asking for a volunteer to implement it? 18:59:55 I'd like to submit some spec for it for further discussion (event if occur in L-release) 19:00:01 ++ 19:00:20 krykowski, we would need someone to help with the impl. on it / drive it 19:00:24 anyway we're out of time. 19:00:30 Last note: 19:00:46 please do bug triage! ( lbragstad has been doing it, some more eyes would help) 19:00:56 further talk on all topics in -keystone channel 19:00:58 #endmeeting