18:02:47 <dolphm> #startmeeting keystone
18:02:48 <openstack> Meeting started Tue Nov 26 18:02:47 2013 UTC and is due to finish in 60 minutes.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:51 <openstack> The meeting name has been set to 'keystone'
18:02:52 <dolphm> #topic icehouse-m1
18:02:54 <dolphm> is next week!
18:03:05 <dolphm> our list of BP's is very short
18:03:07 <morganfainberg> so soon!
18:03:12 <ayoung> M1  always catches people by surprise
18:03:29 <dolphm> i bumped quotas to m2 recently, as warranted by the additional discussions at the summit
18:03:31 <morganfainberg> ayoung, no one expects M1 (eh, it's missing something)
18:03:34 <dolphm> ayoung: ++
18:03:53 <ayoung> #link https://launchpad.net/keystone/+milestone/icehouse-1
18:04:12 <dolphm> dstanek is working on two other bp's that i'm hoping to have merged this week
18:04:22 <dolphm> i think updates are in progress for both, but:
18:04:23 <dolphm> #link https://review.openstack.org/#/c/50491/
18:04:28 <dolphm> #link https://review.openstack.org/#/c/52456/
18:04:39 <dolphm> ayoung: danke
18:04:51 <ayoung> Code review or implemented for all.
18:04:55 <dolphm> if there are any other blueprints that should be targeting m1 - speak up!
18:05:03 <ayoung> KDS?
18:05:05 <ayoung> Heh
18:05:13 <ayoung> seriously, though, it should have been
18:05:37 <dolphm> that mailing list discussion is very indecisive -- i thought we had a firm direction on that early last week
18:05:39 <jamielennox> yes, well KDS doesn't look like it did at the end of H
18:05:50 <dolphm> now it should be in barbican and in keystone and it's own standalone service
18:06:09 <morganfainberg> dolphm, the decision i'm hearing is, in keystone, move to it's own thing or barbican later
18:06:17 <bknudson> I'm still a little confused about KDS -- PKI is no good, but you're going to need PKI anyways for SSL.
18:06:24 <morganfainberg> dolphm, otherwise you need to use a non-integrated project to secure messaging
18:06:25 <jamielennox> so my understanding is we are going with keystone extension - ?
18:06:38 <morganfainberg> dolphm, and separate wSGI/port
18:06:50 <jamielennox> i disagree on the seperate port
18:06:56 <jamielennox> or at least i don't see any reason for it
18:07:10 <dolphm> morganfainberg: then it might as well be based on falcon or pecan/wsme
18:07:14 <morganfainberg> jamielennox, isolation since it'll move out of keystone
18:07:28 <ayoung> jamielennox and I discussed this.
18:07:29 <bknudson> shouldn't need a separate port... that's what resource paths are for.
18:07:37 <jamielennox> but it's still going to have to live in keystone/contrib anyway
18:07:37 <morganfainberg> dolphm, i guess the last part, port/wsgi is not needed.
18:07:42 <ayoung> I suggested a separate port to facilitate splitting it of completely
18:07:44 <dolphm> bknudson: ayoung wants it to be a standalone service
18:07:49 <gyee> if its an *internal* service, why does it matter where you stash it as anything internal is subject to change
18:07:58 <bknudson> I thought ayoung wanted everything in httpd?
18:08:00 <ayoung> dolphm, still do...but we have committments to meet
18:08:22 <ayoung> bknudson, this is tactical, not strategic.  I don;t want KDS in Keystone long term
18:08:22 <jamielennox> if the config file is point to the base_url for KDS then it should make no difference if it is KDS=http://localhost:5000/v3/OS-EXT-KDS/v1 or KDS=http://localhost:8888/v1
18:08:29 <morganfainberg> so, short answer, it looks like it should be in keystone until it can be split. - and i'm fine with that.
18:08:35 <dolphm> bknudson: so, supported and reviewed by keystone-core, but a completely separate standalone service that has nothing to do with identity
18:08:40 <ayoung> and I sort of agree with jamielennox on his point
18:08:42 <dolphm> that means it's own catalog entry, etc
18:09:03 <jamielennox> before dolphm and ayoung's patch to port it various place i had mostly done a port to it's own service based on pecan/wsme
18:09:04 <bknudson> it's a good idea to have a catalog entry if it's going to move.
18:09:07 <ayoung> but still think we will have less trouble splitting it if we get people starting from KDS root instead of auth_url...
18:09:14 <morganfainberg> ayoung, dolphm, i think it needs to be in the catalog and be discoverable.
18:09:20 <dolphm> jamielennox: is that in review somewhere?
18:09:21 <ayoung> morganfainberg, hells not
18:09:26 <jamielennox> i was hoping that i could just drop it in as an extension using wsme and pecan in a way that it is easily extractable
18:09:26 <ayoung> no no no no no
18:09:28 <morganfainberg> ayoung, discoverable at least.
18:09:29 <jamielennox> dolphm: not finished
18:09:29 <ayoung> NO!
18:09:37 <ayoung> morganfainberg, not our job to do that
18:09:40 <jamielennox> no KDS should not be in the servcie catalog
18:09:56 <ayoung> you are lifting up the side of the tent and inviting the camel in
18:09:58 <dolphm> ayoung: you're asking for it to be a separate service, but you don't want it to be discoverable?
18:09:59 <morganfainberg> ayoung, so hard set uri?
18:10:15 <ayoung> sop many things need to be discoverable in the undercloud....but it is not for us to say how that is to be done
18:10:29 <lifeless> bauzas: I live in NZ - UTC+13
18:10:38 <dolphm> s/undercloud/meaningful language/g
18:10:40 <ayoung> dolphm, it is no different than compute figuring out where the RPC server/message broker is.
18:11:02 <morganfainberg> dolphm, in the triple-o sense, the management layer (e.g. nova processes themselves)
18:11:26 <morganfainberg> keystone service, not to be confused by something an end-user would access/consume to make an instance/project/etc
18:11:27 <lifeless> morganfainberg: oh man, so thats not the tripleo sense :)
18:11:37 <ayoung> dolphm, undercloud has come to be a useful term...out of tripleO to distinguish between the services exposed to end users vs those that are Internal to the OS deployment.
18:11:38 <lifeless> the undercloud is the openstack infrastructure deploying cloud.
18:11:40 <jamielennox> dolphm: KDS is going to be similar to configuring MySQL or AMPQ. It is not a service that is used at a client level
18:11:44 <morganfainberg> lifeless, ok ok fine, in the not-so-triple-o-sense
18:12:08 <morganfainberg> lifeless, in the.  not public consumption sense.
18:12:11 <dolphm> lifeless: ++
18:12:12 <bknudson> I think there's a DBaaS project.
18:12:26 <ayoung> so my suggesting:  use jamielennox 's pecan approach, but kick it off from keystone-all
18:12:34 <bknudson> https://wiki.openstack.org/wiki/Trove
18:12:41 <ayoung> suggestion
18:13:00 <dolphm> ayoung: why do you want it to be started by keystone-all? why not just bin/keydist or something?
18:13:00 <dstanek> ayoung: in the same process or using a different port?
18:13:04 <jamielennox> you can nest wsgi applications, so there should be no reason that the pecan/wsme app can't live and run as an extension
18:13:04 <bknudson> I don't have a problem with it as a different service.
18:13:08 <ayoung> bknudson, that is for end user consumption...just like Barbican was supposed to be.
18:13:19 <morganfainberg> if it's a separate service, keystone-all seems like the wrong place to start it.
18:13:26 <dolphm> morganfainberg: ++
18:13:28 <lifeless> morganfainberg: a key (har har) thing to note is that the nova cloud we deploy - the overcloud - can only use public services from the undercloud (e.g. heat) - so if KDS was 'within the cloud only' we'd deploy one KDS per overcloud.
18:13:33 <fabiog> morganfainberg +
18:13:36 <bknudson> shouldn't call it keystone-all if it doesn't start everything
18:13:42 <lifeless> morganfainberg: rather than one in the undercloud and use it from the overcloud
18:13:44 <dolphm> morganfainberg: i'd rather get as much of the separation correct from the beginning
18:13:45 <bknudson> change it to keystone-some
18:13:47 <morganfainberg> bknudson, but KDS isn't... keystone really.
18:13:53 <dolphm> bknudson: but it's not keystone-*
18:13:58 <morganfainberg> dolphm, ++
18:14:18 <morganfainberg> lifeless, as stated above, KDS would be like ZMQ or AMQ
18:14:21 <bknudson> so a new bin/kds ?
18:14:35 <ayoung> dolphm, you know what, that works too.  not keystone-all, but kdsd  or something works for me
18:14:45 * mordred lurking, reading through scrollback - I hear we're talking about fun things
18:15:36 <dolphm> bknudson: yeah
18:15:47 <dstanek> so what i'm hearing so far is new start script in bin and new service on a new port
18:15:47 <bknudson> I don't have a problem with a separate bin... seems like an impl detail.
18:15:49 <dstanek> is that right?
18:15:49 <ayoung> jamielennox, would bin/kdsd make more sense?  And then not an extension?
18:15:58 <dolphm> dstanek: ++
18:16:20 <jamielennox> ayoung: i'm still advocating the extension makes more sense, but if the consensus is new service then so be it
18:16:29 <jamielennox> i just want the consensus part
18:16:38 <dstanek> jamielennox: why do you think it makes more sense?
18:16:41 <bknudson> what's the port for kds?
18:16:54 <dolphm> #agreed kds to have it's own bin/* startup script to run on it's own port
18:17:08 <bknudson> (default port)
18:17:27 <jamielennox> dstanek: the reason for it being a new service is purely so it is easily extractable later - i don't think that this makes any sense as we can already nest all the kds info into the extension
18:17:33 <jamielennox> and this is what extensions are for
18:17:34 <atiwari> 239297
18:17:37 <ayoung> jamielennox, new service, with an eye to completely extracting it from the keystone code base.
18:17:45 <ayoung> bknudson, port 88
18:17:51 <dolphm> bknudson: random(1025, 32767)
18:18:05 <fabiog> dolphm: I would like to come to a conclusion with the OS-SHARED-SECRET, please. It has been around for too long ...
18:18:07 * ayoung waits for you all to look in /etc/services for port 88
18:18:16 <dolphm> fabiog: it's on the agenda
18:18:33 <dolphm> fabiog: kds has been around far longer :)
18:18:35 <fabiog> dolphm: thanks, just checking we will have time for it ...
18:18:46 <jamielennox> so out of interest where does a new service in keystone live (code wise)
18:18:58 <jamielennox> top level? keystone/kds
18:19:01 <morganfainberg> jamielennox, there was some talk of a new repo
18:19:06 <ayoung> jamielennox, we can leave it in contrib for now
18:19:11 <jamielennox> morganfainberg: can't happen for now
18:19:15 <morganfainberg> but contrib is the right place
18:19:24 <dolphm> jamielennox: sure -- it'd be nice if it didn't import anything from outside keystone.kds though :)
18:19:39 <dolphm> jamielennox: you could also isolate it's testing infrastructure -- keystone.tests.kds.*
18:19:47 <ayoung> dolphm, it just uses some keystone.common which should be acceptable
18:19:48 <bknudson> is there going to be a kds-manage ?
18:19:48 <mordred> dolphm: well, maybe keystone.openstack.common
18:19:52 <mordred> ayoung: ++ :)
18:19:53 <dolphm> ayoung: --
18:19:56 <jamielennox> dolphm: yep that was the idea - openstack.common was the only one i had to share
18:20:00 <bknudson> to create the db tables.
18:20:01 <dolphm> mordred: ++
18:20:06 <ayoung> bknudson, so far, no.  If we need it, then we will add it.
18:20:18 <dolphm> jamielennox: cool
18:20:21 <mordred> tests in kds.tests should work too
18:20:28 <dolphm> jamielennox: make it as easy as possible to move to a top level project
18:20:32 <mordred> shoudl be found by test discovery - doesn't matter - we do that in horizon
18:20:45 <dolphm> jamielennox: or if barbican is the correct home for it, base it on falcon...
18:20:55 <ayoung> We have a plan?  Itsounds like we have a plan.
18:21:01 <mordred> only thing that can be split split is distribution targets - only one setup.py/tarball output
18:21:08 <dolphm> mordred: that works for me keystone.kds.tests
18:21:12 <mordred> don't base anyhting on falcon please
18:21:13 <jamielennox> dolphm: my understanding is that we can mix pecan/wsme and keystone - but falcon is a framework as well
18:21:22 <morganfainberg> mordred, pecan/wsme?
18:21:25 <mordred> please
18:21:29 <jamielennox> sorry, falcon is a server as well
18:21:29 <morganfainberg> mordred, ok
18:21:34 <dolphm> mordred: fine by me
18:21:35 <mordred> we've got to stop having framework wars around here
18:21:40 <mordred> cause eek
18:21:58 <ayoung> I thought Barbican was a project, and Cloud Keep was a program.  Did that change?  KDS should stay its own project
18:21:59 <dolphm> mordred: pecan/wsme is more tempting to me for keystone, long term
18:22:09 <morganfainberg> mordred, lets make our own framework, that is subtly different and standardize on that /s (xkcd ref in here somewhewre)
18:22:09 <dolphm> ayoung: that's still the case
18:22:17 <ayoung> It can be under the CLoudKeep program then, when it spins up
18:22:20 <mordred> morganfainberg: YES! do that
18:22:37 <dolphm> morganfainberg: is that not keystone.common.wsgi lol?
18:22:43 <mordred> (programs usually have descriptive names. /me stop trolling)
18:22:45 <morganfainberg> dolphm, oh no, we need something new!
18:23:06 <dolphm> morganfainberg: oh right! keystone.common.superwsgi
18:23:15 <morganfainberg> dolphm, *stops being snarky / off topic*
18:23:34 <ayoung> jamielennox, do you have enough to execute off of here?
18:23:36 <dolphm> jamielennox: so, what milestone are we looking at :)
18:23:56 <dolphm> jamielennox: m2? possible for nova to consume by m3?
18:23:58 <bknudson> kds looks like a lot of work
18:23:59 <jamielennox> dolphm: well it's not m1
18:24:04 <bknudson> lots of code
18:24:06 <jamielennox> m2 should be fine
18:24:22 <morganfainberg> jamielennox, m2 would be _very_ good
18:24:37 <bknudson> I just hope it doesn't get dumped on us in one big review.
18:24:50 <jamielennox> bknudson: 1 for framework, 1 for host keys, 1 for group keys
18:24:52 <dolphm> jamielennox: do you have a link to the bp for kds?
18:24:54 <lbragstad> bknudson: +1
18:24:56 <dolphm> i can't find it...
18:24:57 <ayoung> We have nkinder from RH engaged as well. He is going to take a swipe at the API doc for KDS
18:25:08 <morganfainberg> ayoung, ++ nice.
18:25:26 <morganfainberg> ayoung, hopefully it isn't too much work to get it into shape
18:25:29 <ayoung> morganfainberg, he's the Manager for Dogtag, and has a strong crypto background.
18:25:31 <dolphm> ayoung: thank you!
18:25:37 <bknudson> jamielennox: 6 for framework, 8 for host keys, 4 for group keys.
18:25:37 <nkinder> ayoung: hi all
18:25:39 <morganfainberg> ayoung, woot!
18:25:46 <morganfainberg> nkinder, yay!
18:25:49 <ayoung> nkinder, was just saying...
18:25:53 <ayoung> We have nkinder from RH engaged as well. He is going to take a swipe at the API doc for KDS
18:25:56 <dolphm> alright, let's move on
18:25:59 <jamielennox> bknudson: takes me long enough to get my regular reviews past
18:26:05 <dolphm> jamielennox: poke me with the bp link if you have it
18:26:08 <bknudson> jamielennox: because they're too big!
18:26:14 <jamielennox> dolphm: this is the oslo one: https://blueprints.launchpad.net/oslo.messaging/+spec/trusted-messaging
18:26:14 <nkinder> Yep.  It's on my list for the thanksgiving break
18:26:31 <morganfainberg> nkinder, very awesome.  and thanks!
18:26:47 <nkinder> I'm curious to know how much belongs in the API doc vs. Keystone docs?
18:26:50 <jamielennox> maybe there isn't one for keystone... /me inheritted a lot of this
18:26:56 <dolphm> #link https://blueprints.launchpad.net/keystone/+spec/key-distribution-server
18:27:01 <nkinder> Some of this is really implementation behind the API
18:27:15 <bknudson> nkinder: implementation doesn't belong in api doc.
18:27:43 <gyee> if you use wsme, you auto generate the docs?
18:27:50 <dolphm> #topic Password rotation
18:27:51 <morganfainberg> nkinder, https://review.openstack.org/#/c/40692/ is the original api doc
18:28:03 <ayoung> nkinder, we were thinking more along the lines of "how would an end user actuall consume this, and what would they expect"
18:28:06 <morganfainberg> nkinder, if that helps.
18:28:11 <dolphm> fabiog: o/
18:28:18 <ayoung> OK, so multiple shared secrets is bad
18:28:30 <gyee> ayoung, is a business use case
18:28:32 <MarkAtwood> but useful
18:28:35 <ayoung> I've been reviewing, discussing, and stick to my guns on this one.
18:28:41 <ayoung> gyee, then do it outside of Keystone
18:28:48 <ayoung> or use the exsitng abstractions differently
18:28:53 <gyee> ayoung, services needs to integrate with it
18:29:02 <ayoung> gyee, no they don
18:29:03 <ayoung> t
18:29:08 <gyee> its been propose as *an extension*
18:29:14 <gyee> proposed
18:29:18 <ayoung> gyee, no
18:29:25 <ayoung> it is an end run around security
18:29:26 <dolphm> gyee: you can always publish extensions out of tree
18:29:32 <fabiog> ayoung: and it is using the same concept as EC2, that is already there
18:29:32 <ayoung> do it outside of Keystone altogether if you like
18:29:41 <MarkAtwood> and fork the keystone protocol
18:30:05 <bknudson> it's a lot of work to maintain something out of tree...
18:30:13 <gyee> this is no different than KDS, Trust, or OAUTH
18:30:14 <lbragstad> bknudson: +1
18:30:16 <bknudson> especially since we have no guarantee of internal API stability
18:30:22 <gyee> why is this an exception?
18:30:24 <fabiog> bknudson +
18:30:26 <dolphm> bknudson: it's a lot of work for keystone-core to maintain features that aren't consumed by openstack as well
18:30:56 <morganfainberg> fabiog, MarkAtwood, really quickly, you want to avoid using the current credential implementation? it seems to already hit the mark, just without the "password" mechanism directly
18:30:57 <gyee> dolphm, CI/CD and other service are waiting to integrate, so I heard
18:31:27 <MarkAtwood> monty, would CI use it if it was in?
18:31:28 <ayoung> the list of potential security concerns with multiple passwords/symetric shared secretes far outweighs the benefits.
18:31:51 <ayoung> outweigh
18:31:57 <gyee> ayoung, what security concern? the risk is no different that passwords
18:32:25 <gyee> did you read my responses in the review?
18:32:30 <ayoung> gyee, it multiplies the issues with passwrods, and adds in the "oh, I disabled this one, but that one is still active"
18:32:36 <dolphm> ayoung: that seems very backwards to me - do you have reasoning?
18:32:42 <MarkAtwood> google does it, amazon does it, fb auth does it
18:32:42 <bknudson> one could use an ldap server that supported multiple passwords.
18:32:42 <bknudson> not sure if there are any, but if you had your own ldap implementation...
18:32:46 <gyee> ayoung, you disable a user, not a password
18:32:47 <fabiog> morganfainberg: we need an auth method to leverage the current credential API
18:32:59 <mordred> wait - can someone talk to me very shortly like I'm a moron?
18:33:05 <nachi> gyee +
18:33:12 <dolphm> gyee: users aren't much more than passwords anyway :)
18:33:13 <mordred> is this about the rackspace extension that's not compatible with anything ?
18:33:21 <mordred> we stoped using that in infra
18:33:28 <mordred> because it's not in keystone for real
18:33:31 <MarkAtwood> mordred, no its about the one that hpcloud is running
18:33:37 <mordred> we don't use that either
18:33:37 <gyee> dolphm, points is once you disabled a user, all his credentials are effectively disabled
18:33:45 <bknudson> is hpcloud using this already?
18:33:45 <gyee> easy to contain the risk
18:33:50 <MarkAtwood> if it was in keystone, would you use it?
18:33:51 <ayoung> gyee, right now, the "user" object is really an ID and a  password.  There is nothing more to it.  The same thing that you were trying to do with multiple shared secrets can be done with multiple user accounts.  Yes, it complicates external systems mapping one external acount to Keystone, but that is not a keystone issue.
18:33:51 <morganfainberg> mordred, no. this would be to be able to rotate passwords without eliminating access until it is explicitly revoked
18:33:52 <mordred> can anyone explain to me, in very simple terms, why haivng an api key is better than having a password?
18:33:55 <MarkAtwood> bknudson
18:34:04 <MarkAtwood> yes we are, we want to give this work to the community
18:34:09 <ayoung> I see no benefit to contributing to the mess that is the Keystone password system already
18:34:10 <mordred> when the password gives me access to muck with api keys?
18:34:17 <MarkAtwood> basically ALL of our industrial users are using the feature
18:34:31 <dolphm> ayoung: agree - the only downside (at minimum) is having to manage group membership to apply authorization
18:34:34 <morganfainberg> mordred, that is the crux of the argument, but in short the argument is to allow access w/o having to change all systems that use that password at once (rolling auth change)
18:34:49 <bknudson> seems like if it's been implemented somewhere already for some time and have found it useful then that's a good candidate to go into keystone proper.
18:34:51 <jamielennox> mordred: as i understand it the main benefit would be allowing different api keys on for example different nova hosts but still sharing the same service user
18:34:57 <dolphm> ayoung: multiple 'passwords' per user ID avoids the re-assignment problem
18:34:58 <jamielennox> i don't think this is about rotation yet
18:35:04 <ayoung> dolphm, and, if they use external auth, the logic that they want can be done, without adding anything to keystone
18:35:04 <MarkAtwood> our users assign a different "application password" to each app or subsystem
18:35:07 <mordred> ok. I can see why people might want that
18:35:18 <mordred> well, some of your users do
18:35:24 <mordred> some of us just use the one password
18:35:26 <MarkAtwood> and then can track which ones are being used, and can disable indivual ones, and set expirations for them
18:35:27 <morganfainberg> mordred, jamielennox, rotation is part-in-parcel of this but it is a side effect.
18:35:42 <jamielennox> morganfainberg: yea, it allows rotation but it's a side effect
18:35:47 <morganfainberg> what MarkAtwood  just described ^
18:35:51 <ayoung> So if you want multiple passwords, go for it, but use basic-auth and external, and then map from the credential to the user id in an auth plugin
18:36:19 <MarkAtwood> ayoung, can you explain basic-auth to me and "external"
18:36:35 <gyee> MarkAtwood, means using Apache :)
18:36:41 <gyee> or Nginx
18:36:42 <MarkAtwood> http basic auth cannot be trusted to go through SSL accelerations and load balancers
18:36:43 <ayoung> gyee, or even in Keystone
18:36:47 <bknudson> doesn't seem like any clients actually support using basic-auth.
18:36:50 <mordred> ayoung: I would like for our public clouds to stop having divergent auth methods
18:37:00 <mordred> ayoung: because that's the first thing people interact with
18:37:01 <ayoung> MarkAtwood, basic auth is the HTTP mechanism for userid and password
18:37:07 <gyee> bknudson, nope, not right now
18:37:10 <ayoung> I have a proof of concept...one sec
18:37:11 <mordred> and if you have to do something 'special' that's not discoverable
18:37:14 <dolphm> MarkAtwood: interesting, i've never thought about that
18:37:19 <MarkAtwood> ayoung, it doesnt work.  i have been down this path when writing OAuth
18:37:20 <mordred> to conenect to rackspace and to connect to hp
18:37:32 <mordred> then we're not interoperable
18:37:35 <mordred> and all of openstack dies
18:37:47 <mordred> this is the reason I'm so generally pissed off about the rackspace auth extension
18:37:56 <ayoung> https://github.com/admiyo/keystone/commit/2f5243d779c39f8f5ed2df128e68090df440012f
18:37:59 <mordred> because it's TECHNICALLY a legal auth extension
18:37:59 <MarkAtwood> basic auth looks great, excpe that load balancers mangle it, transparent proxys mangle it, ssl accelerators mangle it, and apache does not pass it down to the app
18:38:15 <mordred> but it changes the user experience in ways they have to know more than "this is an openstack cloud"
18:38:41 <mordred> so if this is an issue that we know is going to make all of our public clouds diverge from what openstack is - I think that's a Really Bad Thing
18:38:41 <bknudson> mordred: I hope that doesn't mean we're stuck with least-common-denominator (user+password)
18:38:43 <mordred> THAT SAID
18:38:51 <gyee> mordred, we can propose it a core if makes you a happier man :)
18:38:51 <dolphm> mordred: ++
18:38:52 <MarkAtwood> hp's fallback is to stop this merge effort and put it under the HPAPI: extenstion, which just makes it worse
18:38:53 <mordred> the public clouds should have more devs working on keystone
18:39:01 <gyee> core API I mean
18:39:14 <dolphm> mordred: working on it!
18:39:23 <MarkAtwood> mordred: working on it!
18:39:25 <MarkAtwood> :)
18:39:31 <mordred> so - I'm a bit more than pissed off at the fac that we have companies in here trying to throw weight behing "we're a big company, listen to us"
18:39:41 <ayoung> MarkAtwood, you know what, you just argued against doing anything with standard HTTP.
18:39:52 <MarkAtwood> ayoung yes i know i did.  and it sucks
18:40:02 <MarkAtwood> i was on your side of this argument 6 years ago
18:40:04 <ayoung> I realize Apache does not pass it down to the app, but Apache can handle basic auth for you already
18:40:12 <ayoung> so that one gets passed through as REMOTE_USER
18:40:16 <MarkAtwood> not all of use run Apache
18:40:34 <dstanek> MarkAtwood: i have not seen the issues your talking about with basic-auth
18:40:37 <MarkAtwood> do you really want to make the web server daemon a dependency
18:40:43 <ayoung> MarkAtwood, absolutelty
18:40:55 <morganfainberg> dstanek, i've seen those issues with some SSL accelerators and LB systems
18:41:10 <morganfainberg> dstanek, they do a lot of mangling at the larger scale implementations ot get their job done
18:41:12 <bknudson> a web server is better at serving web responses than our basic keystone impl will be.
18:41:14 <dstanek> morganfainberg: do they remove the headers?
18:41:18 <morganfainberg> dstanek, they can.
18:41:23 <MarkAtwood> and REMOTE_USER doesnt work when you're running apache as a proxy
18:41:26 <morganfainberg> dstanek, depends on the LB etc
18:41:42 <dstanek> morganfainberg: that sucks, sounds like broken gear
18:41:45 <morganfainberg> dstanek, and reverse proxying does lots of odd stuff.
18:42:03 <dolphm> MarkAtwood: i'm in favor of leveraging what we can, and i have yet to see *any* specific pushback against requiring httpd
18:42:06 <morganfainberg> dstanek, not so much broken, but configured as such because it's needed to leverage the farm behind it.
18:42:33 <dstanek> morganfainberg: broken in that they are violating the HTTP protocol right?
18:42:48 <MarkAtwood> dstanek, its not even a violation of protocol
18:42:52 <mordred> so - is the opposition to the mutliple token thing
18:42:54 <morganfainberg> dstanek, headers dont have to be passed on. etc.
18:42:59 <MarkAtwood> the w3c have beeen rank cowards about it
18:43:00 <mordred> the implementaion of managing the tokens?
18:43:08 <mordred> or being able to expose the consumption one in the protocol?
18:43:15 <mordred> s/one/of one/
18:43:17 <ayoung> mordred, multiple tokens?  Or multiple passwords?
18:43:23 <gyee> if we are using external auth it means accounts are managed outside of Keystone
18:43:24 <mordred> ayoung: passwords
18:43:29 <morganfainberg> mordred, correct inverse, mutiple passwords any one of them can issue the same token.
18:43:56 <dstanek> gyee: do you have a review or bp i can look at?
18:43:58 <morganfainberg> same token in this context = same roles/etc in the data (not physically the exact same token)
18:44:00 <ayoung> mordred, my feeling is that Keystone should never have been attempting to manage passwords in the first place, and we should not attempt to increase its scope.
18:44:08 <mordred> ayoung: honestly, the thing I care about is that there is a consistent user-facing api to access this stuff for cloud consumers - if HP and rax each do a plugin to deal with multi-passsword-mapping-to-user on the admin side, I dont care
18:44:23 <gyee> dstanek, https://review.openstack.org/#/c/46771/
18:44:24 <mordred> ayoung: well, thing is - it's an interface to the exstence of passwords
18:44:30 <mordred> whether it manages them itself or not
18:44:34 <gyee> #link https://review.openstack.org/#/c/46771/
18:44:51 <mordred> I mean, the system that actually owns the passwords at HP is not keystone, it's something else - but keystone is the thing that the user talks to
18:45:01 <ayoung> mordred and the use case they are asking for could be done in the existing mechanisms
18:45:04 <mordred> I imagine at many private clouds it's AD or LDAP that owns the passwords
18:45:16 <ayoung> mordred, or even a pre-existing SQL database
18:45:17 <morganfainberg> mordred, one challenge comes from IdP (identity provider such as ldap) and now having passwords that are indepenant/managed separately from it.  you're no longer relying on the IdP for AuthN
18:45:26 <dolphm> gyee: thanks, i should have linked that at the top
18:45:29 <ayoung> that does not map to what SQLAlchemy in Keystone expectes or provides
18:45:48 <MarkAtwood> does anyone use the idp for passwords at scale?
18:46:02 <mordred> ayoung: by existing mechanism, you mean in the keystone protocol? or using specific things in an apache deployment choice
18:46:03 <gyee> please take a look at the comments in detail in that review
18:46:03 <MarkAtwood> i remember watching the rdo demo about how they dont either
18:46:10 * mordred trying to catch up on lots of tech details really quickly
18:46:33 <gyee> alternatively, we can add the "expried_at" field for a password
18:46:43 <dolphm> ayoung: by your reasoning, all of this should be handled by an alternative password auth plugin, correct?
18:46:48 <gyee> so a password is no longer valid after the upgrade
18:46:52 <ayoung> BTW, there are several other security professionals that have weighed in on that review.  I'll leave it to you guys to read their feedback
18:47:13 <MarkAtwood> we keep the passwords and appkeys in a seperate system because it's keep MUCH more secure against read and access than the IdP
18:47:24 <gyee> ayoung, I've responded to the security professionals in that review
18:47:26 <ayoung> dolphm, I would not even feel comfortable agreeing to that
18:47:34 <dolphm> ayoung: why not?
18:47:45 <morganfainberg> MarkAtwood, that argues for a separate auth plugin, that just overloads the current password one.
18:47:50 <morganfainberg> MarkAtwood, simplest solution?
18:47:59 <morganfainberg> s/overloads/overrides
18:48:01 <MarkAtwood> ayoung, you want to remove login shared secrets from keystone entirely?
18:48:07 <ayoung> dolphm, we can do it with the mapping piece from federation
18:48:19 <mordred> MarkAtwood: that sounds sane to me - no?
18:48:35 <mordred> the end user shouldn't need to tell keystone anything new about the tyep of password, no?
18:48:36 <dolphm> ayoung: i don't follow that at all?
18:48:52 <dolphm> ayoung: this is about keystone's idp, not delegated authorization
18:48:56 <jamielennox> so would a compromise be to bump the role for installing a SHARED-SECRET to admin (or something new) so that it could be set up for use by services but not be user facing?
18:49:08 <morganfainberg> and we have agreed internally to maintain internal API stability for 1 cycle (to the best of our ability) so maintaining the plugin shouldn't be too onerous.
18:49:08 <gyee> this is not about federation, it a simple case of password rotation for rolling upgrade
18:49:12 <MarkAtwood> its useful for user facing
18:49:14 <MarkAtwood> users use it
18:49:16 <gyee> please don't make it any more complicated
18:49:19 <dolphm> jamielennox: that's entirely user facing
18:49:23 <ayoung> dolphm, I was saying that they could keep the passwords outside of Keystone using mod_auth_sql  and then map REMOTE_USER to user_Id  and get the same effect
18:49:30 <ayoung> that does not require an explicit plugin
18:49:33 <dolphm> jamielennox: that's just a question of "which" users
18:49:37 <mordred> MarkAtwood: but where do users use it? and does that require protocol violations?
18:49:47 <mordred> for normal auth
18:49:56 <ayoung> but that keeps it from being Keystone's problem, and uses a well tested mechanism.
18:50:04 <dolphm> gyee: and you specifically only care about "service users", correct?
18:50:17 <gyee> dolphm, yes, but service user is a user
18:50:18 <ayoung> dolphm, I would allow for an extension that did the same based on the current password plugin
18:50:19 <MarkAtwood> users use it when they are running multiple applications in their account
18:50:29 <jamielennox> fair enough, guess my expected usage is different
18:50:33 <dolphm> gyee: correct- i'm just pointing out that's our agreed long term use case for keystone's own idp
18:50:34 <ayoung> but I would not want it installed by default
18:50:38 <MarkAtwood> telling the users and operators to open a new account for each application is a non-starter
18:50:55 <ayoung> and...no.  Each time I think it htrough, I see a slew of problems.
18:51:14 <ayoung> MarkAtwood, I thought all of that was handled through your backend CRM system anywa
18:51:14 <ayoung> y
18:51:48 <gyee> ayoung, suspending multiple account in order to suspend a user is pretty complicated
18:51:54 <bknudson> ayoung: are the problems worse than just having username/password ? How is 2 passwords worse than 1?
18:52:05 <ayoung> But password rotation needs two passwords, and unique ways to identify them.  If you want rotation, use two users.
18:52:07 <gyee> look, this is being proposed as an extension, means disabled by default
18:52:07 <morganfainberg> ayoung, it's a fair request that a service user can be used for multiple things.
18:52:09 * dolphm 8 minutes remaining
18:52:15 <MarkAtwood> no.  the links between CRM and the operations are not deep, for security and auditing reasons
18:52:35 <mordred> ayoung: so, it has just been pointed out that multi-password would be useful by openstack-infra
18:52:48 <lifeless> I'm going to pipe up here
18:52:55 <gyee> mordred, for password rotation, heck yeah!
18:52:58 <mordred> we currently maintain 3 different accounts on each cloud so that we can ensure that one of our apps doesn't accidentally delete gerrit
18:53:02 <mordred> no - not for that
18:53:06 <atiwari> ayoung, can we talk about service scoped roles definition link:https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition?
18:53:11 <mordred> for role protection
18:53:15 <mordred> we have nodepool, which is very dynamic
18:53:18 <lifeless> and say this is an important story for ops in TripleO's opinion. There are many ways to slice it but: we want graceful rotations.
18:53:20 <atiwari> I looked at your proposal which is like "keystone:manager" name spacing the role name, does not handle all the issue mentioned in BP.
18:53:23 <mordred> and then we have some servers which deleting is BAAAAAAD
18:53:29 <mordred> so we have different accounts
18:53:47 <mordred> and keep precious servers there and do not put that password anywhere that dynamically creates/destroys nodes
18:54:00 <MarkAtwood> hp was able to give CI/CD multiple accounts only because CI/CD is extremely special
18:54:04 <lifeless> mordred: I think the infra story is not one that maps well here, because an account can generally do anything to itself.
18:54:13 <mordred> lifeless: righ t- but the thing is
18:54:14 <ayoung> atiwari, No.  BUt we can talk about mapping nested role definitions to services :)
18:54:18 <nkinder> ayoung: rotation can be performed with an expiration/changeover period.  This is similar to what AD does.
18:54:44 <gyee> nkinder, but you still have to maintain both new and old passwords right?
18:55:04 <lifeless> gyee: for the changeover period; but password reuse policies mean you are anyway :)
18:55:07 <gyee> so isn't that *multiple credentials active* at the same time?
18:55:08 <atiwari> atiwari, let talk after the meeting
18:55:20 <nkinder> gyee: for a very limited period of time (and you only allow 2 ever - old and current)
18:55:25 <atiwari> ayoung ^^^
18:55:29 <ayoung> atiwari, I see it
18:55:43 <nkinder> gyee: it's much different than allowing 40 creds to be created for a single account that live that way long-term.
18:55:50 <gyee> nkinder, so that's essentially what we are proposing, we can add the "expired_at" field in there
18:56:03 <gyee> so the old password expired after some time
18:56:22 <dolphm> mordred: should that just be different tenants, ideally?
18:56:28 <gyee> 40 creds is only allowed if the business process allows it
18:56:36 <gyee> users can't create credentials at well
18:57:20 <MarkAtwood> well, they can, but "too many" trips a security alert and its looked at
18:57:29 <gyee> heck, keystone credential APIs are admin-protected out-of-the-box
18:57:30 <dolphm> mordred: meh, nvm. i guess i see the use case for a set of credentials not being able to cross tenant boundaries at all
18:57:46 <morganfainberg> gyee, fabiog,
18:57:51 <morganfainberg> *retypes*
18:57:54 <bknudson> can keystone even be configured to allow a user to create their own creds?
18:58:05 <dolphm> bknudson: revise the policy.json ?
18:58:07 <morganfainberg> bknudson, i think so?
18:58:16 <gyee> bknudson, not the default policy
18:58:25 <bknudson> you'd need a mapping from cred to user
18:58:26 <morganfainberg> gyee, ok, but it's just policy.json mangling iirc
18:58:27 <gyee> bknudson, cred APIs are admin-protected out-of-the-box
18:58:38 <morganfainberg> bknudson, thats in the cred table already, afaik
18:58:45 <gyee> morganfainberg, correct, but that's a deployment option
18:58:51 <bknudson> ok, it's got user_id
18:58:54 <morganfainberg> bknudson, yep
18:59:00 <bknudson> but it's not in the url
18:59:03 <ayoung> gyee, extending the password API to check (current, old)  is way different than what you are proposing.  Allowing simple rotations in the current paradigm is scary, but preferable.
18:59:09 <morganfainberg> ah, fair enough.
18:59:25 <lifeless> ayoung: what is a 'simple rotation' ?
18:59:32 <ayoung> lifeless, just rotations
18:59:38 <lifeless> ayoung: I need detail.
18:59:49 <lifeless> ayoung: like, do we have nova-compute processes on servers doing their own password updates?
18:59:51 <dolphm> so -- to meekly summarize in the last couple minutes... password rotation is desirable for service users, the only long term use case for keystone's own idp. for end users, password rotation would likely be managed by a federated or external auth source anyway
19:00:06 <nkinder> lifeless: the old password is still allowed to be used for some period after it is changed.  This gives a window to go update your services to use the new password.
19:00:06 <ayoung> lifeless, new and old are both valid for a short period of time, as Nathan said.  Not an open ended numer, and not a new API.
19:00:14 <lifeless> ayoung: this is a huge operational thing : auditors and compliance /care/, and if we get it wrong downtime ensues.
19:00:26 <lifeless> ayoung: ok, cool. *that* I love.
19:00:31 <nkinder> lifeless: That period should be configurable, but ideally short
19:00:32 <lifeless> ayoung: and AFAICT it meets the use case put up.
19:00:42 <lifeless> nkinder: matter of hours be ok ?
19:00:47 <MarkAtwood> there are more use cases then key rotation
19:00:48 * dolphm (time's up)
19:01:04 <dolphm> switching to -dev!
19:01:05 <lifeless> MarkAtwood: may need to take it to the list
19:01:06 <gyee> dolphm, we have to give users a bridge in the mean time, which means implementing the extension
19:01:06 <nkinder> lifeless: yep, that's ideal in my mind, but it's a policy decision
19:01:07 <dolphm> #endmeeting