Tuesday, 2016-12-06

*** adrian_otto has joined #openstack-keystone00:01
*** dave-mccowan has quit IRC00:08
*** tqtran has quit IRC00:25
*** catintheroof has quit IRC00:25
*** mfisch has quit IRC00:28
*** mfisch has joined #openstack-keystone00:29
*** mfisch has quit IRC00:29
*** mfisch has joined #openstack-keystone00:29
*** tqtran has joined #openstack-keystone00:43
*** Marcellin__ has quit IRC00:49
*** rcernin has quit IRC01:01
*** adrian_otto has quit IRC01:28
*** adrian_otto has joined #openstack-keystone01:28
openstackgerritGage Hugo proposed openstack/keystone: WIP - Allow user to change own expired password  https://review.openstack.org/40402201:30
*** davechen_afk is now known as davechen01:31
*** zhangjl has joined #openstack-keystone01:33
*** narasimha_SV has quit IRC01:37
*** shuquan has joined #openstack-keystone01:40
*** gyee has quit IRC01:40
*** shuquan has quit IRC01:49
*** shuquan_ has joined #openstack-keystone01:50
*** adrian_otto has quit IRC01:52
*** chrisplo has quit IRC01:56
*** shuquan_1 has joined #openstack-keystone02:01
*** shuquan_ has quit IRC02:03
*** magic has joined #openstack-keystone02:12
*** agrebennikov has quit IRC02:13
*** xiaoyang has quit IRC02:16
*** spzala has quit IRC02:18
*** guoshan has joined #openstack-keystone02:21
*** browne has quit IRC02:28
openstackgerritRodrigo Duarte proposed openstack/python-keystoneclient: Refactor test_projects  https://review.openstack.org/40535902:41
openstackgerritRodrigo Duarte proposed openstack/python-keystoneclient: Refactor test_projects  https://review.openstack.org/40535902:42
openstackgerritRodrigo Duarte proposed openstack/python-keystoneclient: WIP: Do not skip test_acess  https://review.openstack.org/40722102:42
openstackgerritRodrigo Duarte proposed openstack/python-keystoneclient: Refactor test_credentials  https://review.openstack.org/40504402:42
*** Ephur has quit IRC02:44
*** edmondsw has quit IRC02:55
*** woodster_ has quit IRC02:56
openstackgerritRodrigo Duarte proposed openstack/python-keystoneclient: Refactor test_projects  https://review.openstack.org/40535902:58
openstackgerritRodrigo Duarte proposed openstack/python-keystoneclient: WIP: Do not skip test_acess  https://review.openstack.org/40722102:58
*** adrian_otto has joined #openstack-keystone03:17
*** udesale has joined #openstack-keystone03:23
*** adrian_otto has quit IRC03:23
*** adrian_otto has joined #openstack-keystone03:25
*** adrian_otto has quit IRC03:33
*** adrian_otto has joined #openstack-keystone03:33
*** spzala has joined #openstack-keystone03:42
*** code-R has joined #openstack-keystone03:42
*** adrian_otto has quit IRC03:43
*** adrian_otto has joined #openstack-keystone03:43
*** code-R_ has joined #openstack-keystone03:45
*** adrian_otto has quit IRC03:46
*** adrian_otto has joined #openstack-keystone03:47
*** adrian_otto has quit IRC03:47
*** code-R has quit IRC03:48
*** adrian_otto has joined #openstack-keystone03:48
*** links has joined #openstack-keystone03:52
*** adrian_otto1 has joined #openstack-keystone03:58
*** code-R_ has quit IRC03:59
*** code-R has joined #openstack-keystone03:59
*** zhangjl has quit IRC03:59
*** adrian_otto1 has quit IRC04:00
*** zhangjl has joined #openstack-keystone04:00
*** adrian_otto has quit IRC04:01
*** guoshan has quit IRC04:02
*** tqtran has quit IRC04:03
*** masber has joined #openstack-keystone04:07
openstackgerritMerged openstack/keystone: Remove CONF.os_inherit.enabled  https://review.openstack.org/40567904:12
*** smaktub has joined #openstack-keystone04:16
smaktubHi. Are multiple endpoints for same service supported?04:17
smaktubFor example, If I add first endpoint with url http://controller:5000/v2.0 and another with http://controller:5000/v304:19
smaktubAlso, if there are multiple endpoints for the same service (API), which one would be used?04:21
*** GB21 has joined #openstack-keystone04:21
*** edmondsw has joined #openstack-keystone04:24
*** mnaser has quit IRC04:25
*** mordred has quit IRC04:26
*** afazekas has quit IRC04:26
*** edmondsw has quit IRC04:29
*** spzala has quit IRC04:30
*** GB21 has quit IRC04:33
*** adrian_otto has joined #openstack-keystone04:42
*** diazjf has joined #openstack-keystone04:43
*** nicolasbock has quit IRC04:48
*** GB21 has joined #openstack-keystone04:49
*** alex_xu has joined #openstack-keystone04:49
*** alex_xu has quit IRC04:49
*** alex_xu has joined #openstack-keystone04:51
*** shuquan_1 has quit IRC04:53
*** afazekas has joined #openstack-keystone04:58
*** guoshan has joined #openstack-keystone05:03
*** mordred has joined #openstack-keystone05:04
*** nkinder has quit IRC05:07
*** guoshan has quit IRC05:08
*** mnaser has joined #openstack-keystone05:10
*** mfisch has quit IRC05:16
*** anteaya has quit IRC05:16
*** mordred has quit IRC05:18
*** mnaser has quit IRC05:18
*** nkinder has joined #openstack-keystone05:23
*** mfisch has joined #openstack-keystone05:23
*** mfisch is now known as Guest1619705:23
*** code-R has quit IRC05:23
*** mordred has joined #openstack-keystone05:26
*** anteaya has joined #openstack-keystone05:29
*** code-R has joined #openstack-keystone05:29
*** mnaser has joined #openstack-keystone05:39
*** shuquan_ has joined #openstack-keystone05:40
openstackgerritChetna proposed openstack/keystone: Corrects sample-data incorrect credential call  https://review.openstack.org/40733105:40
openstackgerritRichard Avelar proposed openstack/keystone: Rename doctor symptom in security_compliance  https://review.openstack.org/40720605:41
*** shuquan_ has quit IRC05:41
*** adriant has quit IRC05:53
*** gagehugo_ has joined #openstack-keystone05:56
*** adrian_otto has quit IRC05:56
*** gagehugo_ has left #openstack-keystone05:56
*** kiran-r has joined #openstack-keystone05:57
*** GB21 has quit IRC06:01
*** tqtran has joined #openstack-keystone06:03
*** guoshan has joined #openstack-keystone06:04
*** kiran-r has quit IRC06:05
*** tqtran has quit IRC06:07
*** adrian_otto has joined #openstack-keystone06:07
*** guoshan has quit IRC06:09
*** GB21 has joined #openstack-keystone06:14
*** guoshan has joined #openstack-keystone06:23
*** adrian_otto has quit IRC06:24
*** tovin07 has joined #openstack-keystone06:25
*** adrian_otto has joined #openstack-keystone06:25
*** adrian_otto has quit IRC06:27
*** spzala has joined #openstack-keystone06:30
*** rcernin has joined #openstack-keystone06:34
*** spzala has quit IRC06:34
*** code-R has quit IRC06:38
*** richm has quit IRC06:41
*** code-R has joined #openstack-keystone06:55
*** code-R has quit IRC07:00
*** smaktub has quit IRC07:01
*** rcernin has quit IRC07:12
*** code-R has joined #openstack-keystone07:14
*** voelzmo has joined #openstack-keystone07:22
*** voelzmo has quit IRC07:23
*** voelzmo has joined #openstack-keystone07:23
*** mordred has quit IRC07:25
*** Guest66666 has quit IRC07:27
*** Guest66666 has joined #openstack-keystone07:29
*** mnaser has quit IRC07:30
*** mrsoul has quit IRC07:32
*** mordred has joined #openstack-keystone07:34
*** rcernin has joined #openstack-keystone07:34
*** mrsoul has joined #openstack-keystone07:35
*** mnaser has joined #openstack-keystone07:39
*** GB21 has quit IRC07:39
*** pcaruana has joined #openstack-keystone07:42
*** code-R has quit IRC07:47
*** d0ugal has joined #openstack-keystone07:57
*** d0ugal has quit IRC07:57
*** d0ugal has joined #openstack-keystone07:57
*** mvk has quit IRC08:01
*** GB21 has joined #openstack-keystone08:02
*** pnavarro has joined #openstack-keystone08:05
*** mnaser has quit IRC08:15
*** code-R has joined #openstack-keystone08:18
*** code-R_ has joined #openstack-keystone08:21
*** edisonxiang has joined #openstack-keystone08:22
*** code-R has quit IRC08:24
*** ccard_ has quit IRC08:25
*** edisonxiang has left #openstack-keystone08:26
*** mnaser has joined #openstack-keystone08:33
*** mvk has joined #openstack-keystone08:33
*** pnavarro has quit IRC08:45
*** zzzeek has quit IRC09:00
*** zzzeek has joined #openstack-keystone09:00
*** GB21 has quit IRC09:05
*** asettle has joined #openstack-keystone09:09
*** GB21 has joined #openstack-keystone09:18
*** spzala has joined #openstack-keystone09:30
*** spzala has quit IRC09:35
*** daemontool has joined #openstack-keystone09:35
*** udesale has quit IRC09:43
*** udesale has joined #openstack-keystone09:49
*** huhaoran has joined #openstack-keystone10:01
*** voelzmo has quit IRC10:03
*** tqtran has joined #openstack-keystone10:06
*** tovin07 has quit IRC10:09
*** tqtran has quit IRC10:10
*** voelzmo has joined #openstack-keystone10:11
huhaoranHey, I am working on HA of keystone. I have seen the HA doc from the community. But the doc does not apply to the new keystone. Do anyone have some suggestion or docs to share? Thanks in advance.10:15
*** eandersson has joined #openstack-keystone10:15
*** daemontool has quit IRC10:23
*** voelzmo has quit IRC10:30
*** voelzmo has joined #openstack-keystone10:32
*** guoshan has quit IRC10:34
*** voelzmo has quit IRC10:36
*** huhaoran has quit IRC10:46
*** huhaoran has joined #openstack-keystone10:47
*** Ephur has joined #openstack-keystone10:47
*** huhaoran has quit IRC10:51
*** huhaoran has joined #openstack-keystone10:51
*** Ephur has quit IRC10:52
*** narasimha_SV has joined #openstack-keystone10:54
narasimha_SVhttp://paste.openstack.org/show/591515/ according to this log is this trying to create admin user or is this trying to modify the user details ???10:54
*** udesale has quit IRC11:03
*** chrisplo has joined #openstack-keystone11:10
*** zhangjl has quit IRC11:11
*** daemontool has joined #openstack-keystone11:11
*** richm has joined #openstack-keystone11:13
*** chrisplo has quit IRC11:15
*** faizy has joined #openstack-keystone11:35
*** voelzmo has joined #openstack-keystone11:36
*** nicolasbock has joined #openstack-keystone11:38
*** GB21 has quit IRC11:38
*** voelzmo has quit IRC11:40
*** jamielennox is now known as jamielennox|away11:44
*** faizy has quit IRC11:54
*** GB21 has joined #openstack-keystone11:55
*** voelzmo has joined #openstack-keystone11:56
*** GB21 has quit IRC12:07
*** GB21 has joined #openstack-keystone12:16
*** narasimha_SV has quit IRC12:16
*** code-R_ has quit IRC12:30
*** code-R has joined #openstack-keystone12:31
*** GB21 has quit IRC12:54
*** belmoreira has joined #openstack-keystone12:56
*** edmondsw has joined #openstack-keystone13:08
*** edmondsw_ has joined #openstack-keystone13:13
*** edmondsw_ has quit IRC13:17
*** dave-mccowan has joined #openstack-keystone13:19
*** lamt has joined #openstack-keystone13:19
samueldmqgood morning keystone13:20
lbragstadsamueldmq morning13:21
samueldmqlbragstad: o/13:21
openstackgerritMerged openstack/keystone: Correct minor issues in test schema  https://review.openstack.org/40723413:24
*** huhaoran has quit IRC13:25
*** adrian_otto has joined #openstack-keystone13:29
*** spzala has joined #openstack-keystone13:31
*** code-R_ has joined #openstack-keystone13:33
*** spzala has quit IRC13:36
*** code-R has quit IRC13:36
openstackgerritMerged openstack/keystone: Rename doctor symptom in security_compliance  https://review.openstack.org/40720613:37
openstackgerritMerged openstack/keystone: Add unit tests for doctor federation file  https://review.openstack.org/40718813:37
*** chrisplo has joined #openstack-keystone13:38
samueldmqlbragstad: couple of questions on https://review.openstack.org/#/c/407036/13:38
lbragstadsamueldmq sure13:38
samueldmqlbragstad: overall it looks great and very well written :)13:39
lbragstadsamueldmq thanks!13:39
lbragstadsamueldmq i see henry commented on it, too... i'll get around to answering those shortly13:42
samueldmqlbragstad: awesome13:42
*** chrisplo has quit IRC13:42
lbragstadi want to have an updated version ready before the meeting today13:43
*** catintheroof has joined #openstack-keystone13:43
samueldmqlbragstad: that'd be nice13:43
*** faizy has joined #openstack-keystone13:44
*** huhaoran has joined #openstack-keystone13:47
*** hrybacki|l4mG3 is now known as hrybacki13:53
*** Marcellin__ has joined #openstack-keystone13:58
openstackgerritSamuel Pilla proposed openstack/keystone: api-ref update for roles assignments with names  https://review.openstack.org/40636614:01
*** lamt has quit IRC14:01
*** lamt has joined #openstack-keystone14:02
*** Guest16197 is now known as mfisch14:03
*** mfisch is now known as Guest7303714:04
*** daemontool has quit IRC14:04
*** adrian_otto has quit IRC14:11
*** faizy_ has joined #openstack-keystone14:11
*** faizy has quit IRC14:13
*** Guest73037 is now known as mfisch14:15
*** mfisch is now known as Guest1328114:16
*** Guest13281 is now known as mfisch14:16
*** mfisch is now known as Guest4066414:17
*** Guest40664 is now known as mfisch14:17
*** mfisch has quit IRC14:17
*** mfisch has joined #openstack-keystone14:17
*** faizy_ has quit IRC14:25
lbragstadstevemar o/14:25
*** thiagolib has joined #openstack-keystone14:31
openstackgerritMerged openstack/python-keystoneclient: Refactor test_credentials  https://review.openstack.org/40504414:35
openstackgerritMerged openstack/python-keystoneclient: Refactor test_projects  https://review.openstack.org/40535914:35
*** links has quit IRC14:40
*** Ephur has joined #openstack-keystone14:49
*** agrebennikov has joined #openstack-keystone14:50
*** Ephur has quit IRC14:53
*** udesale has joined #openstack-keystone14:59
*** narasimha_SV has joined #openstack-keystone15:08
*** udesale_ has joined #openstack-keystone15:08
*** phalmos has joined #openstack-keystone15:10
*** tqtran has joined #openstack-keystone15:10
*** udesale has quit IRC15:12
dstanekagrebennikov: when  you have some time can you document the usecase that's not solved with db replication?15:12
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Get assignments with names honors inheritance flag  https://review.openstack.org/38097315:14
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Add test to expose bug 1625230  https://review.openstack.org/40755815:14
openstackbug 1625230 in OpenStack Identity (keystone) "Role Assignment Incorrectly Reports Inheritance when --name is Used" [Medium,In progress] https://launchpad.net/bugs/1625230 - Assigned to Kanika Singh (kanikasingh-1490)15:14
agrebennikovdstanek, I probably can, but most likely I'm just going to abandon it. Geo galera replication is ugly from any standpoint - deployment, maintenance, support, handling quorum etc. I mean specifically OpenStack db usecase15:15
agrebennikovand I see that the conversation goes nowhere15:15
*** tqtran has quit IRC15:15
*** phalmos has quit IRC15:15
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Get assignments with names honors inheritance flag  https://review.openstack.org/38097315:15
dstanekagrebennikov: i think it's that you haven't actually show why this is needed. from what i can tell you just open up more holes and problems.15:16
openstackgerritColleen Murphy proposed openstack/keystone: Add anonymous bind to get_connection method  https://review.openstack.org/40756115:18
dstanekagrebennikov: i'd also be interested in alternatives. for example, has you looked at writing your own selective sync db->db?15:19
agrebennikovdstanek, I'm not sure if discussing proc and cons of db replication in "keystone" threads and the channel is a very good idea. It means we can end up with discussing the alternatives of the pacemaker, docker and aws benefits at the end of the day :D15:21
*** phalmos has joined #openstack-keystone15:22
openstackgerritColleen Murphy proposed openstack/keystone: Add anonymous bind to get_connection method  https://review.openstack.org/40756115:22
dstanekagrebennikov: to some extent you'll have to give specifics why this won't work and why we'd want to open up this new functionality15:22
agrebennikovin a few words it is this. From the day 1 when we started working with restful apis, we were always told: "you should Never Ever (if there is NOOO alternatives of course) touch the database. Ever" Use clients, use wrappers, add flexibility to the API15:24
agrebennikovsince touching the DB is Always hacky15:24
agrebennikovin addition to that, you should Never expose your DB to the public network15:25
agrebennikovsetting up geo replication means you are exposing your db engine into routable network15:25
agrebennikovthis is literally similar to what are you guys explaining to me "allowing custom ID breaks everything". Where everything means the concept15:27
dstanekagrebennikov: there is nothing wrong with certain types of tools using the database directly. *you must only use REST* is a myth15:31
*** diazjf has joined #openstack-keystone15:31
*** diazjf has quit IRC15:31
dstanekagrebennikov: don't expose your DB to a customer routable network unless it's over a secure connection15:32
*** knasim-wrs has joined #openstack-keystone15:35
*** agrebennikov has quit IRC15:39
*** faizy_ has joined #openstack-keystone15:41
*** kiran-r has joined #openstack-keystone15:43
*** faizy__ has joined #openstack-keystone15:43
*** faizy_ has quit IRC15:46
*** chris_hultin|AWA is now known as chris_hultin15:46
openstackgerritRichard Avelar proposed openstack/keystone: Add unit tests for doctor's database symptoms  https://review.openstack.org/40706215:47
openstackgerritRichard Avelar proposed openstack/keystone: Add unit tests for doctor's database symptoms  https://review.openstack.org/40706215:47
*** ravelar has joined #openstack-keystone15:49
*** agrebennikov has joined #openstack-keystone15:50
*** adrian_otto has joined #openstack-keystone15:52
agrebennikovdstanek, that's the whole point. I'm not a developer, I'm a deployment guy. And I have to choose between the frankenstein of multiple galera cluster with arbitrator and all that stuff, and maintain/backup it separately and so on15:55
agrebennikovand one 3-lines patch which will be local for the custom repo, very easy to port to the newer versions and which solves the problem.15:56
agrebennikovyou see the point?15:56
dstanekagrebennikov: it's not just a 3-line patch because you open a bunch of problems15:59
dstanekwe historically don't like features that we discourage people from using, which is what i think this would be16:00
agrebennikovdstanek, no, I mean - in the way I propose it. And it doesn't break anything in current customer's architecture16:00
dstanekagrebennikov: it could if it were to be used16:01
*** nk2527 has joined #openstack-keystone16:03
*** nkinder has quit IRC16:05
agrebennikovdstanek, maybe. And it will be Only clear when I started to use it. And because of this reason I have to put it into production now and watch. I bet with 99% probability it will be fine because I already tested it. Yes, there willbe some specific cases which I'll fix down the road. I also understand that using this new functionality users May get issues with tokens working in different clouds16:05
*** HenryG has left #openstack-keystone16:05
*** ayoung-afk is now known as ayoung16:05
agrebennikovbut is is not more complicated than for example domain/project scoped tokens and policy16:05
jgrasslerayoung: do you have time to talk me out of https://review.openstack.org/#/c/396331/ properly? :-)16:06
agrebennikovdstanek, this is why I ask you guys Not to Change the functionality but just Extend it16:06
ayoungjgrassler, yes.  BTW, I love that proposal, and the way you are thinking.  You are just not quite going far enough16:06
agrebennikovso that I may use it If necessary16:06
agrebennikovwell, it is pointless anyway16:07
jgrasslerayoung: not far enough?16:07
agrebennikovI'll go replicate my database16:07
jgrasslerayoung: because it's limited to trusts?16:07
ayoungjgrassler, I want it on every token16:07
jgrasslerayoung: ah...ambitious :-)16:07
ayoungjgrassler, so trust based tokens are no different from other tokens16:07
ayoungand the enforcement you need to make that happend would have to be done for tokens in general16:08
*** jaugustine has joined #openstack-keystone16:08
ayoungjgrassler, so...let's restate your goals...16:08
ayoung"Capabilities that impose additional limitations on the trust's access to oslo.policy targets"16:08
ayoungI.E I want a token that can only execute  service:api16:08
ayoungthat is the big one16:09
ayoungso...that is essentially what I am shooting for with RBAC16:09
jgrasslerYes, that would fit my goal16:09
ayoungbut we need an inventory of the APIs first off16:09
ayoungjgrassler, lets hand wave that away for  a moment16:09
jgrasslerayoung: agreed - that would go very far down the rabbit hole..16:10
ayoungsay we have that...how does a user know what policy rule they are trying to execute?16:10
ayoungjgrassler, heh...I've got a drone down that rabbit hole ATM16:10
ayoungthe Rabbits are quivering with excitement16:10
ayoungto do delegation, a user needs to be able to answer the question:  what role(or other attribute) do I need to delegate in order to make this happen16:11
ayoungand, with the oslo based approach, it is not clear that there is any way to answer it16:11
ayoungI want to make it clear, and enforce that based on the URL called.16:11
dstanekagrebennikov: from my perspective that preferable. it's not wise for us to make experimental change to APIs anyway16:11
jgrasslerayoung: I'm absolutely with you there16:11
*** ravelar has quit IRC16:12
jgrasslerayoung: full, keystone side RBAC is the way to go eventually16:12
*** ravelar has joined #openstack-keystone16:12
ayoungjgrassler, this is a shorter distance16:12
jgrasslerayoung: my spec is more of a stopgap measure to have similar functionality for trusts until all the infrastructure for proper RBAC is in place16:12
ayoungjgrassler, can't enforce on your spec, though16:13
ayoungneed all the enforcement pieces in place, and that is where things will fall down16:13
ayoungso, forget about trusts for a moment...lets say that we need a mechanism to say "this token can only execute this API"16:13
jgrasslerayoung: you mean oslo.policy is handled too inhomogenously in individual services?16:13
ayoungand, if we have it working for norma; tokens, trust will inherit it16:13
ayoungjgrassler, not so much "inhomogenously"  as monolithically16:14
*** catinthe_ has joined #openstack-keystone16:14
ayoungright now, there is no role check16:14
ayoungadmin or "does tjhe project match" is it16:14
ayoungso...I want to add the role check as an additional pre-check16:15
jgrasslerYes, and I agree on that needing to be fixed16:15
jgrasslerSo do for the capability check16:15
*** faizy__ has quit IRC16:15
ayoungjgrassler, now, on the "per endpoint" thing, I don't know that I have a better answer for you.  We've been over a few things along this line, and I would say that if you want to pursue that, go ahead16:15
*** faizy has joined #openstack-keystone16:15
ayoungit would have to be in the body of the token, and an explicit opt-in, not the service catalog16:16
ayoungremember, though, that endpoints don't know their own ID16:16
jgrasslerayoung: actually the per-endpoint thing is not too important to me16:16
ayoungand that was a killer issue in the past16:16
*** daemontool has joined #openstack-keystone16:16
ayoungOK...so lets get through RBAC first, and we can revisit per-endpoint later16:16
jgrasslerayoung: it is problematic, to say the least. Capabilities are way more important.16:16
*** catintheroof has quit IRC16:16
ayoungjgrassler, but to do the per endpoint, I do have a starting point...16:16
*** chrisplo has joined #openstack-keystone16:17
*** code-R_ has quit IRC16:17
jgrasslerayoung: You mean the service= setting in keystone_authtoken you suggest in your spec?16:17
*** rcernin has quit IRC16:17
*** nkinder has joined #openstack-keystone16:17
*** catinthe_ has quit IRC16:18
ayoungjgrassler, right16:18
ayoungjgrassler, that too16:18
ayoungbut also this:16:18
jgrasslerayoung: (that together with the is_admin flag struck me as a good-enough (and far more robust) approach than full endpoint ID/URL matching)16:18
*** pcaruana has quit IRC16:19
ayoungjgrassler, we can't do just a single service in a token, as they are used for multi-service use cases.  Well, we can, actually, but it involves some messing with the whole service token spec.16:19
ayoungthe idea of a catalog subset, however, is that, once calculated, it could be used for the "limit the token to this subset" in a single value16:20
ayoungand that could be then tied to a trust, a token, enforced, etc16:20
ayoungbut it still has the "what is my Identity" problem in the endpoints....so lets defer for now16:20
jgrasslerAs I said, endpoints are not that important to me. I'm more concerned with having a white list of API operations.16:21
*** faizy has quit IRC16:21
jgrasslerFor that would allow for clean handling of all these situations where people play with fire^Wtrusts in their current very permissive shape.16:23
ayoungjgrassler, ok...let me show you my trick...16:23
openstackgerritBrant Knudson proposed openstack/keystone: Use consistent role schema in token response validation  https://review.openstack.org/40758716:24
ayoungfind ./api-ref/source/ -name \*inc | xargs awk '/rest_method/ {print "{ verbs=[\"" $3"\"], url_pattern=\""$4"\" role=\"Member\" },"}'16:24
bknudsontrying to figure out why role sometimes has domain_id in it.16:25
bknudsonin the token response16:25
ayoungjgrassler, run that in the keystone repo, or nova, and you get a first take on the set of apis required for the RBAC approach16:25
ayoungbknudson, whoah16:25
ayoungin the role name?16:25
ayoungor as a separate field?16:25
*** mvk has quit IRC16:26
openstackgerritSamuel Pilla proposed openstack/keystone: Domain included for role in list_role_assignment  https://review.openstack.org/37351616:26
bknudsonayoung: it's a separate field. domain_id16:26
jgrasslerayoung: yes...and if you add a `| wc -l` to that and sum the result up over all resources you see where my objection about the RBAC approach's daunting logistics comes from.16:26
bknudsonit's always null in the tests... not sure if it can ever be something else.16:27
ayoungbknudson, could it be from a "v2 token validated via v3 API" or comparable code path?16:27
ayoungjgrassler, its roughly the same number of lines as on the policy.json files16:27
bknudsonayoung: I'll look into the tests some more. It's not mentioned in the API spec.16:27
jgrasslerayoung: Do you have a plan for ensuring all the roles required for finely grained RBAC are present in any cloud?16:27
ayoungjgrassler, I have a plan for a starting point16:28
ayoungjgrassler, I am not moving this mountain alone.  But I do think we will end up with something like this:16:28
jgrasslerayoung: if that can be done I'm happy. For that's the main reason I still prefer the trusts based approach.16:28
ayoungjgrassler, they are complementary, but you still need this, or you need to  go and change the policy enforcement in every.single.service16:29
jgrasslerayoung: well, that's why I suggested a pre check in oslo.policy (much like your pre check in keystonemiddleware)16:30
jgrasslerayoung: I definitely wouldn't want to go any deeper than that. That's truly insane, yes :-)16:30
ayoungjgrassler, I think that we will end up with some catch all roles like "Reader" for auditing.  WOrkflow based roles like "create_server"  that touch a few different services, and then a need to enforce on them based on the implied-roles16:32
jgrasslerBecause oslo.policy has a canonical name for each API operation/verb combination and that's enough information for a pre check16:32
ayoungwe need a way to map from role to operation, and we don;'t have that yet16:32
ayoungjgrassler, it still doesn't gie a way to query, or even to generate in a generic way16:33
jgrasslerHow about getting the services to create these roles?16:33
ayoungjgrassler, do you really hate me that much?16:33
*** chrisplo has quit IRC16:33
jgrasslerayoung: no, querying won't work16:33
bknudsonayoung: turns out it is all trust scoped tokens that have null domain_id in the token roles. Here's the tests that failed: http://paste.openstack.org/show/591561/16:34
jgrasslerayoung: well, the services would have to maintain basic rules anyway, wouldn't they?16:34
jgrasslerayoung: (at least you mentioned that in your spec)16:34
*** peterstac has joined #openstack-keystone16:35
jgrasslerayoung: so if we need to get them to provide these, we might as well get them to create and maintain a list of roles.16:35
ayoungjgrassler, and that is why .... find ./api-ref/source/ -name \*inc | xargs awk '/rest_method/ {print "{ verbs=[\"" $3"\"], url_pattern=\""$4"\" role=\"Member\" },"}'16:36
ayoungBut we also can get the name of the URL called from the openstack CLI, or from any other tool16:36
ayoungits not buried in code, it can be deduced at run time...16:37
jgrasslerYes, the information is definitely there.16:37
jgrasslerBut a way to convert it into as set of hmm, let's call it "system roles", that can be expected to be there for each service running on any sufficiently up-to-date Openstack cloud would be nice to have.16:38
*** kiran-r has quit IRC16:40
ayoungjgrassler, start with everything using Member16:40
ayoungthen, on a case by case basis, we will make the more specific roles16:40
ayoungwe can do that this way:16:41
*** knasim-wrs has quit IRC16:41
jgrasslerThat will take very long...16:41
ayoungsay we want to make a specific role for compute:do_thing16:41
ayoungjgrassler, everything in Openstack takes long16:41
ayoungI've been here since Keystone was incubated, and it still has this shortcoming16:41
*** knasim-wrs has joined #openstack-keystone16:41
jgrasslerHow about generating specific roles for everything and making Member imply all of the roles that previously specified role=Member?16:42
jgrasslerLet me rephrase that: How about generating specific roles for everything and making Member imply all of the roles that resulted form verb/URL combinations with role="Member"16:43
*** knasim-wrs has quit IRC16:44
jgrasslerBecause one could put that through the "it takes long" process once16:45
jgrasslerIncrementally adding roles would go through that process for _every_ new role16:46
*** diazjf has joined #openstack-keystone16:46
*** belmoreira has quit IRC16:47
jgrasslerIf one could (purely hypothetically) mandate that every project have a `$project-manage keystone-roles sync` and `$project-manage rbac-rules sync` command and get that through that slow, slow process once...16:48
jgrasslerAlso, on the Keystone side there would have to be some sort of mechanism to prevent role name collisions16:50
*** diazjf has quit IRC16:50
jgrasslerI.e. to guard against scenarios where an operator manually creates a role compute_server_create, say and uses it for a very different purpose than the identically named upstream role16:51
peterstacHi all, I'm trying to debug an authentication error in the gate16:53
peterstacif I run the curl command locally (env set up with devstack) it works16:53
peterstacany glaring errors there that would typically only occur in the gate?16:54
jgrasslerayoung: but yeah, the "things take long" bit is why I opted for the trusts based approach, basically16:54
ayoungjgrassler, "Hear you nothing that I say?"  Yoda16:54
ayoungTHe issue is enforcement16:54
ayoungtrusts do nothing for that16:54
ayoungTrust do a better job of defining delegation, period16:55
*** LamT__ has joined #openstack-keystone16:55
ayoungjgrassler, add a role per operation and you would be closer16:55
ayoungand that you could do automatically16:55
jgrasslerayoung: yes...I'm looking for ways to do that in a standardized manner (that's why I indulged in that bit of speculation just now)16:56
ayoungjgrassler, so work with me on this16:56
ayoungIf we work with the roles appraoch, and it does get too large, what we do is find a way to distinguish between classes of roles16:57
ayoungan operational role maps one to one with an operation16:57
ayounga workflow role maps to a set of operational roles16:57
ayoungan organizational role maps to a set of workflows16:57
jgrasslerayoung: I do realize trusts are not the ideal vessel for this - I just went for them on a "I could get this to work" now approach16:57
ayoungwhen you list roles, you can specificy which class of roles you want to list16:58
jgrasslerAnd I will join for the roles approach either way16:58
jgrasslerIn the mid to long term it's definitely more sensible16:59
jgrasslerAlso useful for things other than trusts, not least.17:00
jgrasslerI used to operate an Openstack cloud in another life and the whole policy.json based RBAC thing messed with our lofty goals for clean role assignment something fierce...17:01
*** Ephur has joined #openstack-keystone17:03
*** catintheroof has joined #openstack-keystone17:03
*** catintheroof has quit IRC17:03
*** catintheroof has joined #openstack-keystone17:04
jgrasslerAlso, proper RBAC being in place will get me most of the way to my goal (nailed down trusts), too.17:05
*** adrian_otto has quit IRC17:05
*** voelzmo has quit IRC17:07
jgrasslerBecause if it's there I can use configuration management to create a designated "this role only gets to create Cinder volumes" role and make "Member" imply it, plus configure it as delegation role for whatever service creates a trust used for that operation.17:07
jgrasslerayoung: so in short, I'll work with you on the RBAC thing, yes :-)17:08
jgrasslerayoung: and I'm definitely up for any plot/scheme/conspiracy that aims to automatically create per-operation roles for every service...17:09
*** pnavarro has joined #openstack-keystone17:11
*** diazjf has joined #openstack-keystone17:11
*** tqtran has joined #openstack-keystone17:12
ayoungjgrassler, Excellent17:12
openstackgerritRon De Rose proposed openstack/keystone: WIP - Require domain_id when registering Identity Providers  https://review.openstack.org/39968417:12
*** rcernin has joined #openstack-keystone17:26
*** code-R has joined #openstack-keystone17:33
*** code-R_ has joined #openstack-keystone17:36
stevemarlbragstad: oh nice bug17:38
*** pnavarro has quit IRC17:38
stevemarmorgan: does your taskmanager interface for ksa need to be on the agenda?17:38
*** code-R has quit IRC17:38
lbragstadstevemar yeah17:39
lbragstadstevemar that was a fun one ;)17:39
*** spilla has joined #openstack-keystone17:41
*** asettle has quit IRC17:42
stevemaragrebennikov: did you want to still discuss the custom project id in the meeting also?17:43
openstackgerritLance Bragstad proposed openstack/keystone-specs: Expose password requirements through API  https://review.openstack.org/40703617:43
stevemarits on the agenda (whatever wasn't discussed from last week)17:43
agrebennikovyes sir17:43
stevemarbut given the conversations here... okay.17:43
*** chrisplo has joined #openstack-keystone17:44
*** udesale_ has quit IRC17:44
stevemaragrebennikov: i'll try to motor though the first 2-3 topics so we have sufficient time for yours17:45
agrebennikovhopefully you'll not get stuck with the task manager ;)17:46
agrebennikovlike last time with mfa17:46
*** adrian_otto has joined #openstack-keystone17:47
*** Zer0Byte__ has joined #openstack-keystone17:52
edmondswstevemar if you get a chance, take a look at https://bugs.launchpad.net/python-cinderclient/+bug/1472295 . If you agree I think that bug can be rejected17:54
openstackLaunchpad bug 1472295 in Glance Client "Cinder and glance client have endpoint selection issues" [Undecided,New]17:54
stevemaragrebennikov: shouldn't be, i asked morgan to remove that, the patch is being worked on, no reason to talk about it17:54
stevemaredmondsw: si?17:54
edmondswif there is anything to fix there, it's probably in keystoneclient, not glanceclient/cinderclient17:54
*** browne has joined #openstack-keystone17:55
lbragstadstevemar if you want to bump my first topic you can - i just wanted it to be there to get focus on it/talk about options17:55
stevemarlbragstad: okay, i'll bump it17:57
stevemaredmondsw: thats a toughie17:57
*** mvk has joined #openstack-keystone18:00
*** annakoppad_ has joined #openstack-keystone18:00
edmondswstevemar you thinking that keystoneclient shouldn't have used the links from the version check API response?18:02
edmondswif you had keystone properly configured it wouldn't matter, because the link would have been correct18:02
*** cbits has joined #openstack-keystone18:03
*** code-R_ has quit IRC18:06
*** huhaoran has quit IRC18:07
*** code-R has joined #openstack-keystone18:07
*** ravelar has quit IRC18:08
*** ravelar has joined #openstack-keystone18:08
*** diazjf has quit IRC18:09
*** eandersson has quit IRC18:10
openstackgerritRichard Avelar proposed openstack/keystone: Add unit tests for doctor's database symptoms  https://review.openstack.org/40706218:11
*** faizy has joined #openstack-keystone18:25
*** faizy_ has joined #openstack-keystone18:31
*** faizy_ has quit IRC18:32
*** faizy has quit IRC18:33
*** faizy_ has joined #openstack-keystone18:33
*** asettle has joined #openstack-keystone18:35
*** spzala has joined #openstack-keystone18:50
*** ravelar has quit IRC18:50
*** asettle has quit IRC18:54
*** asettle has joined #openstack-keystone18:55
ayoungOK here to answer stevemar and samueldmq ?s one RBAC18:59
*** asettle has quit IRC18:59
ayoungor anyone elses that cares to join in18:59
stevemarayoung: can you give me 15 minutes, i need a caffeine injection19:00
ayoungstevemar, I'm not going anywhere.19:00
lbragstadsame here - i have to get something to eat quick19:01
ayoungsamueldmq, here is an autogenerated subset of what the Keystone RBAC rules would look like to start https://paste.fedoraproject.org/500624/1050892119:01
*** LamT__ has quit IRC19:02
*** pnavarro has joined #openstack-keystone19:02
*** narasimha_SV_ has joined #openstack-keystone19:04
samueldmqayoung: remember everything as Member may open security issues. e.g delete a domain19:04
samueldmqayoung: that's just a nit19:04
narasimha_SV_http://paste.openstack.org/show/591515/ keystone woth LDAP backend is giving this error19:05
samueldmqayoung: my question in the meeting was if you are creating a new syntax to represent RBAC-only policy19:05
narasimha_SV_password which I am am supplying for the admin user is the same password which I have in LDAP19:05
samueldmqwhich seems to be the case, right ?19:05
*** narasimha_SV has quit IRC19:06
dstaneknarasimha_SV_: it appears that you are trying to create a user and you don't have the authorization to do that19:07
*** huhaoran has joined #openstack-keystone19:07
*** jamielennox|away is now known as jamielennox19:07
samueldmqnarasimha_SV_: you must set the option user_allow_create to True in your config file19:08
samueldmqdstanek: ++ ^19:08
ayoungsamueldmq, it does not lessen existing policy19:09
ayoungthis is just *in addition* to19:09
ayoungso if it is not a security issue now, it will not be with the additional RBAC]19:09
narasimha_SV_+dstanek: http://paste.openstack.org/show/591587/19:09
narasimha_SV_these are my ldap configurations19:10
ayoungsamueldmq, I have sample code that gives the idea of how I plan to enforce:19:10
openstackgerritMerged openstack/keystone: api-ref update for roles assignments with names  https://review.openstack.org/40636619:10
ayoung https://paste.fedoraproject.org/500634/8105144019:10
samueldmqayoung: what about APIs that accept unscoped tokens ?19:10
dstaneknarasimha_SV_: does the user you are using have the right assignments?19:10
narasimha_SV_+samueldmq: as per specification keystone will not create the LDAP users right . we need to use those users created in LDAP19:11
ayoungsamueldmq, we'll have to make sure those continue to pass19:11
narasimha_SV_+dstanek: what do you mean by right permissions ?19:11
dstaneknarasimha_SV_: what operation are you trying to do? it looks to me like you are trying to create a user19:11
samueldmqnarasimha_SV_: in your first paste http://paste.openstack.org/show/591515/ you are trying to create a user19:11
samueldmqayoung: looking19:12
*** huhaoran has quit IRC19:12
narasimha_SV_no no I am runing keystone-manage bootstrap command I am getting above issue19:12
ayoungsamueldmq, but I think those are only the ones for creating tokens in the first place, or rescoping, right>?19:12
dstaneknarasimha_SV_: ah, that doesn't work with ldap yet19:12
ayoungnarasimha_SV_, that will never work with LDAP...19:12
ayoungdo this instead:19:12
dstaneknarasimha_SV_: you can try the existing patch if you like. that's what i'm testing now19:12
dstanekayoung: not true19:12
ayoung1.  set up your system with SQL for identity19:12
ayoung2. asdd a domain specific backedn for LDAP in its own domain19:13
samueldmqayoung: yes, like the federation ones for discovering what porjects and/or domains you can scope to19:13
ayoungsamueldmq, we'll have to make a special exception for those.19:13
dstanekwhen that merges it won't do the user stuff, but will bootstrap everything else19:13
*** catinthe_ has joined #openstack-keystone19:14
*** bapalm_ has quit IRC19:14
samueldmqayoung: honestly I am all for it. but I'd go with defining the roadmap. agreeing in the policy meeting19:15
samueldmqayoung: and keeping track of all the bits and what implements each part19:16
*** catintheroof has quit IRC19:16
samueldmqayoung: also Ocata is a shorter cycle :(19:16
ayoungsamueldmq, the spec window is a bout to close.  I need active support or its going to die via pocket veto19:16
*** nk2527 has quit IRC19:17
samueldmqayoung: how do those policies get distributed to the endpoints ?19:18
*** bapalm has joined #openstack-keystone19:18
samueldmqayoung: so that the middleware can enforce them ?19:18
*** faizy_ has quit IRC19:19
*** code-R has quit IRC19:20
*** AlexeyAbashkin has joined #openstack-keystone19:22
*** spzala has quit IRC19:23
*** AlexeyAbashkin has quit IRC19:23
openstackgerritMorgan Fainberg proposed openstack/keystone-specs: Specification for MFA support  https://review.openstack.org/40500719:23
morgandstanek: ^ addressed the two typos. other comments seemed to be addressed via the comments back and forth19:24
*** pnavarro has quit IRC19:24
morganayoung: ^ if you care to look (i know you're on your own spec)19:25
ayoungmorgan, ok...so, what is the goal of MFA support?  As I see it, it is to require MFA for certain operations, right?19:25
morganayoung: set MFA for a given user19:25
morganrequired to authn19:26
ayoungmorgan, for all operations?  Not that we will look in the token later to see if MFA was used when, say, executing an operation against a more secure endpoint or something?19:26
morganno for auth19:26
morganjust for auth.19:27
morganyou can add that feature later19:27
samueldmqmorgan: you want that in this cycle ?19:27
morganbut this is just getting auth to require specific plugins/combinations19:27
morgansamueldmq: yes. talked with stevemar.19:27
* samueldmq nods19:27
ayoungmorgan, that really needs external references19:29
morganayoung: i am open to requiring MFA for some ops (or everything we do as admin), but this is the github-like setup. as a user you can opt-in to mfa19:29
ayoungcan go in later, but this should be built on a well established security principal19:29
morganthere really aren't any external references at this point19:29
morganthat are well defined in a place I can link19:29
morganshort of maybe... github?19:29
ayoungmorgan, that can be an update, though19:29
ayoungI get it.  "I want to set this on MY account"19:30
ayoungor "I want this for my people"19:30
ayoungmorgan, per user first, per domain later?19:30
morganit's setting the framework for additional features as well19:30
morganper-user first19:30
morganif we want to expand to "all users in a domain" the mechanism is going to be the same19:30
morganin the auth-processing code that is19:31
ayoungmorgan, +2 from me19:31
morganit wont ever be (as long as I have a say) "for scoping to this domain" or be "scope specific" (short of something in policy)19:31
*** gyee has joined #openstack-keystone19:31
morganjust because the UX on it starts looking terrible that someone needs to re-auth to re-scope19:32
morganayoung: cool19:32
ayoungmorgan, got it.19:32
morganayoung: thx19:32
ayoungmorgan, you cool with the RBAC spec as is?19:32
morganayoung: for the RBAC thing, maybe the "new rabc stuff" only applies to v3 and later tokens?19:32
morganayoung: re the earlier convo about v2 security holes19:32
ayoungmorgan, I don;t see why, though19:32
ayoungI could see not appliying to V2 APIs19:33
morganin general I need to re-review it, but it wasn't looking awful.19:33
*** spzala has joined #openstack-keystone19:33
ayoungbut the V2 tokens still have the role data in it19:33
morganyeah I think we should not apply it to v2 apis19:33
morganv2 is on the short list to be removed in 2 cycles19:33
ayoungthat is a keystone decision, but I think it can easily work with any of the APIs we have19:33
openstackgerritMerged openstack/keystone-specs: Specification for MFA support  https://review.openstack.org/40500719:34
morganenhancements should be 100% "is it a real security issue (aka CVE)" imo. but i'm also not PTL19:34
*** pleia2 has quit IRC19:34
samueldmqmorgan: just to make sure, is the token request is backwards compatible?19:34
ayoungIdeally, this is done prior to any mapping, so we don't really know whether it is going to be a v2 or v3 api.  We just need to skip it for unscoped apis19:34
morganayoung: uh.19:34
*** pleia2 has joined #openstack-keystone19:34
morganayoung: you shouldn't have single-core approved that man19:34
ayoungI did not mean to +2A that19:34
ayoungso sorry19:34
morgani figured it was a mistake19:34
samueldmqmorgan: I was wondering if what we have today is identity/method or identity/methods (plural)19:34
morganlets ask samueldmq, stevemar, and dstanek if they are ok with it19:34
*** slunkad has quit IRC19:35
*** andreaf has quit IRC19:35
ayoungmorgan, ++19:35
morganwe can revert it out or update it19:35
morganayoung: let me circle back on RBAC after i discuss with samueldmq so we can address the oops on approval :)19:35
samueldmqinfra was too fast to revert the W+119:35
morgansamueldmq:  today you can supply multiple methods19:35
*** nk2527 has joined #openstack-keystone19:36
morgansamueldmq: and all must pass if you do19:36
morganbut there is no way to explicitly require multiuple methods to auth19:36
*** slunkad has joined #openstack-keystone19:36
samueldmqmorgan: and that's your proposal19:36
morganso if keystone.conf uses totp,password,external for example19:36
morganyou can use any of them19:36
*** ravelar has joined #openstack-keystone19:36
morganindividually or in a grouping19:36
morganwith this spec, we will have a way to say "you must use totp and password"19:37
samueldmqmorgan: and that is on a per user basis19:37
ayoungI think we are good here.  We can always accept updates to the spec if there are details we want to make different.  dstanek 's message was "Overall I'm strongly for something like this."19:37
morganand if you don't supply both auth plugins in the auth request, keystone would reject it19:37
*** andreaf has joined #openstack-keystone19:37
morganayoung: i think so too :)19:37
morgansamueldmq: correct, per user to start19:38
morgansamueldmq: with a self-service api (can also be set via admin "update user")19:38
samueldmqayoung: how do users discover their required methods ?19:38
ayoungsamueldmq, can be out of band to start19:38
morganin the case of admin setup, it is out of band19:39
samueldmqperhaps providing useful error messages is a good approach19:39
*** diazjf has joined #openstack-keystone19:39
morganin the case of user-initiated, you have set the values via self-service api19:39
samueldmqlike specifying methods in the error message19:39
morgani am inclined to leak what auth-types are required if we have rules for a given user19:40
morgansince today it is assumed you have "password"19:40
morganit's not really a mystery19:40
samueldmqmorgan: yes I agree with you19:40
samueldmqmorgan: putting that in the error messages would be nice, as I just said19:40
morganand by leak: i mean explicitly not obscure it in the 401 response.19:40
samueldmqmorgan: x,y and z auth methods are required for the specified user19:41
samueldmqmorgan: an API for it ?19:41
dstanekmorgan: catching up...19:41
morgan"401, insufficient auth types, requires: JSON(x and y, or X and Z)19:41
samueldmqmorgan: yes I like that19:41
morgandstanek: the spec was oopse merged so doing the "what needs to change now or are we reverting it" with the interested cores19:41
morgansamueldmq: if there are no rules for a given user, it's just going to work like it does today with the 401.19:42
samueldmqmorgan: tbh I'd like to see that in the spec because it describes how UX will be19:44
samueldmqmorgan: I am also taking another look at it now19:44
morgansamueldmq: it is in the spec already19:45
morgansamueldmq: If insufficient auth plugins are supplied a ``HTTP 401`` with a JSON response19:45
morganindicating insufficient auth parameters will be returned to the requestor.19:45
dstanekmorgan: adrian had an interesting point about allowing certain plugins only in combination with others, but i'm not sure it's worth the complexity19:45
morgandstanek: i am going to punt on that19:45
morganfor now19:45
morganwe can add complexity in19:46
morganbut we need basic functionality19:46
morganif ocata wasn't a short cycle19:46
morgani'd be more open for it19:46
*** ravelar has quit IRC19:46
samueldmqmorgan: also, how does this behavior with federated users ?19:46
dstaneki'm fine with that is there assuming that we'll makes updates if we need to19:46
morgansamueldmq: since this is per-user base, federated user(s) are unaffected.19:47
morgansince either they don't exist in keystone (ephemeral) or are mapped to a real user19:47
samueldmqmorgan: federated users are not ephemeral anymore19:47
morganthe federated plugin would be one-of-the auth methods19:47
samueldmqmorgan: they exist in keystone tables after the first login, then we can do assignments, etc as any other user19:48
morganfor the most part, federated logins use an IDP19:48
ayoungsamueldmq, if you are Ok with it, add the +2 even though it went through19:48
morganit would be assumed the IDP does MFA19:48
morgandstanek, samueldmq: can you add a comment you're +2 on it even though it merged19:48
samueldmqayoung: I will leave a comment, can't +2 something that has merged19:49
dstanekmorgan: already did19:49
ayoungat least leave a comment19:49
morgani'll create the BP now then.19:49
samueldmqmorgan: rderose has a spec for exposing federated attributes via API19:50
samueldmqmorgan: we might want to restrict federated plugin for federated users to avoid inconsistencies19:50
morganayoung: going to review a couple patches, then on to your spec. (need to look at something for shade right now)19:54
samueldmqmorgan: security impact section is TBD yet. do you have somthing in mind we could patch with another review ?19:55
morgansamueldmq: i'm thinking just add in that it is adding in optional security features19:56
morganbut doesn't really impact security overall.19:56
morgani'll spin a patch up for that today or thursday (tomorrow I am  booked solid trying to get a place locked down in Seattle to live)19:57
samueldmqmorgan: yes, at least mentioning it is allowing to enforce different security levels for different users or somethign like that19:57
samueldmqmorgan: I can do that now19:57
stevemarayoung: sorry, around-ish now19:59
*** ravelar has joined #openstack-keystone20:00
stevemarayoung: in https://review.openstack.org/#/c/391624/15/specs/keystone/ongoing/role-check-from-middleware.rst20:00
stevemarwhen you say "Create an entity in the resource backend" -- who creates that entity?20:00
stevemaris it for people who want to proactively add role-checking in middleware? they create some keystone db entry that maps URL + VERB to a role?20:01
ayoungstevemar, when a user (probably the admin setting up the remote sercvice) calls the API to upload the rules20:01
ayoungstevemar, yes20:01
ayoungit will be part of the cluster initialization20:01
ayoungwe could probably trigger a default rule off the service catalog "Create service" api20:02
*** catintheroof has joined #openstack-keystone20:02
ayoungbut this is the per VERB + URL_Pattern version20:02
stevemarayoung: OK, maybe part of bootstrap we could do a bulk initiatilization one day20:02
ayoungstevemar, yes, at least for default, but we can figure out the overall ownership over time20:03
*** catinthe_ has quit IRC20:04
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone-specs: Add security impact on per user auth plugin spec  https://review.openstack.org/40768820:04
samueldmqmorgan: ayoung: dstanek: stevemar ^20:05
morgansamueldmq: ah ty!20:05
ayoungsee...we can approve specs and continue to improve them.  Living docs20:06
samueldmqmorgan: my pleasure20:06
samueldmqayoung: ...20:06
morganayoung: OMG no way! :) ;) :P20:07
*** asettle has joined #openstack-keystone20:11
*** asettle has quit IRC20:14
stevemarayoung: my concern is with getting the RBAC data back for validation20:16
stevemarbut this is pretty isolated20:16
stevemarand opt-in20:16
stevemarthis will take a while, i see now why you placed it in ongoing20:17
stevemarayoung: http://i.imgur.com/ZQS0vpF.gif20:18
ayoungstevemar, what do you mean by  "getting the RBAC data back for validation"20:19
stevemarayoung: the calls from middleware to keystone server20:19
stevemarThere would be a small, but non-zero impact in the remote service due20:20
stevemarto the need to fetch and cache the RBAC data. Since the API matching20:20
stevemarrules fetched from in the Keystone server will likely be cached in20:20
stevemarthe remote server, there should be minimal impact on the Keystone side20:20
ayoungstevemar, so that will  be "list all rules for service"20:20
stevemardue to database lookups.20:20
stevemarayoung: i'm interested to see what those numbers look like20:20
openstackgerritMerged openstack/keystone-specs: Add security impact on per user auth plugin spec  https://review.openstack.org/40768820:21
ayoungstevemar, roughly an additional token verification would be my guess20:21
ayoungand, cahcing will mitigate, but delay the freshness...as in all things20:21
stevemarayoung: +220:22
*** narasimha_SV_ has quit IRC20:22
*** adriant has joined #openstack-keystone20:25
stevemarmorgan: gah, adriant isn't around, do you know if he still wants to go down the self management of TOTP creds spec?20:25
morganstevemar: not sure20:26
morganhe should be around alter on20:26
morganhe tends to clock in mid afternoon my time20:26
stevemarmorgan: yeah, he's in NZ i think20:26
stevemarmorgan: okie dokie20:28
morganstevemar: i'd be ok with landing that spec / new plugin since we're getting the MFA one... but honestly I'd rather see that combined password+totp one be an auth plugin in KSA20:33
morganthat dfoes the split for us20:33
morganmake it a client logic thing20:34
adriantstevemar: am here now!20:34
stevemaradriant: heyo!20:34
stevemarmorgan: so i like the idea of a new auth plugin that is smart enough to handle this20:35
*** spzala has quit IRC20:35
stevemarmorgan: but user management of credentials is still a PITA i think?20:35
morganstevemar: yes.20:36
morganlook it's adriant !20:36
adriantmorgan: hello :)20:36
adriant9:37am here. I'm not much of a morning person :(20:37
morganstevemar:  i think the totp self management should be a client side thing in general. not server20:37
morganstevemar: thats all20:37
adriantmorgan: I don't mind where it is, just I do think we need to consider it as part of openstack, because setting up MFA with no way to use it natively is useless MFA.20:38
adriant"We have this feature!" "How can I use it?!" "Be admin, or ask your admin to set it up."20:39
adriantnot exactly good UX20:39
stevemaradriant: i agree that is a sad20:39
morganright. if the client can create the totp credential sanely and upload it20:39
morgani'm all for it20:39
morganand with the self-service mfa stuff20:40
morganyou still need to verify the cred is working before you make it mandatory20:40
morganin the case of deployer setup, the external portal would handle both of those parts20:40
morgan(still client side, effectively)20:40
stevemarmorgan: so i wouldn't be able to do it myself through APIs i have access to?20:41
*** asettle has joined #openstack-keystone20:41
morganstevemar: you would be able to store a credential20:41
morganyou would not be able to generate a totp secret20:41
morganand you wuold be able to use and change the auth-plugin rules20:42
morgankeystone wont have an api to generate a specific type of credential (excluding ec2)20:42
samueldmqmorgan: so ec2 is kinda special ?20:43
morganec2 is "special"20:43
*** nk2527 has quit IRC20:43
morganin.. a negative way20:43
samueldmqmorgan: my concern there was that it's proposed to create new api entries for that20:43
morganit also doesn't really work like normal auth workflows20:43
*** daemontool_ has joined #openstack-keystone20:44
adriantmorgan: the problem is the ec2 stuff is useful. It might be an idea to look at rebuilding it better in future, and deprecate the old stuff.20:45
morganadriant: we can't really remove it at this point20:45
morganit's special20:45
morganwe'll leave it as special20:45
*** knasim-wrs has joined #openstack-keystone20:46
morganbut we don't need to add "more" special cases, especially when it works like normal auth-workflows20:47
*** daemontool has quit IRC20:47
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Invalidate token cache after token delete  https://review.openstack.org/31699120:47
*** diazjf has quit IRC20:54
*** david-lyle has quit IRC20:55
morganayoung: +220:58
openstackgerritRon De Rose proposed openstack/keystone: WIP - Require domain_id when registering Identity Providers  https://review.openstack.org/39968421:00
ayoungmorgan, stevemar TYVM21:06
*** catintheroof has quit IRC21:06
*** diazjf has joined #openstack-keystone21:08
*** huhaoran has joined #openstack-keystone21:09
*** dave-mccowan has quit IRC21:10
*** huhaoran has quit IRC21:14
*** chris_hultin is now known as chris_hultin|AWA21:20
*** spzala has joined #openstack-keystone21:26
openstackgerritRon De Rose proposed openstack/keystone: WIP - Require domain_id when registering Identity Providers  https://review.openstack.org/39968421:34
openstackgerritRichard Avelar proposed openstack/keystone: Print name with duplicate error on user creation  https://review.openstack.org/40510421:42
*** chlong has joined #openstack-keystone21:43
ayoungmorgan, with bootstrap and a developer setup, how are we supposed to initialize the service catalog?21:51
openstackgerritRichard Avelar proposed openstack/keystone: Add unit tests for doctor's database symptoms  https://review.openstack.org/40706221:52
stevemarayoung: why not use bootstrap?21:52
ayoungstevemar, I did.  No catalog21:53
ayoungwhat did I miss?21:53
stevemarayoung: oh, bootstrap with no opts doesn't set it up21:53
stevemarayoung: http://docs.openstack.org/developer/keystone/configuration.html#bootstrapping-keystone-with-keystone-manage-bootstrap21:53
ayoungso I need --bootstrap-service-name21:53
stevemar$ keystone-manage bootstrap \21:53
stevemar    --bootstrap-password s3cr3t \21:53
stevemar    --bootstrap-username admin \21:53
stevemar    --bootstrap-project-name admin \21:53
stevemar    --bootstrap-role-name admin \21:53
stevemar    --bootstrap-service-name keystone \21:53
stevemar    --bootstrap-region-id RegionOne \21:53
stevemar    --bootstrap-admin-url http://localhost:35357 \21:54
stevemar    --bootstrap-public-url http://localhost:5000 \21:54
stevemar    --bootstrap-internal-url http://localhost:500021:54
morganthat will get you the basic catalog21:54
bknudsonis this a joke?21:54
morganthen you can setup the rest21:54
ayoungstevemar, we need to make it clearer that without at l;east the identity ones we don't get a functioning keystone21:54
stevemaryou can probably omit the username, project, role, and service name21:54
morganyou need a keystone entry21:54
ayoungyou can't perform normal operations without identity21:54
stevemarbknudson: sorry for the spam21:54
bknudsonall the arguments really start with --bootstrap?21:55
*** daemontool_ has quit IRC21:55
annakoppad_hello all, I ran the stack script, then unstacked it, enabled ldap, and then ran stack, its throwing up this error, Volume group "stack-volumes-lvmdriver-1" not found devstack. I have configured ldap as per https://wiki.openstack.org/wiki/OpenLDAP#Ubuntu, and http://www.ibm.com/developerworks/cloud/library/cl-ldap-keystone/cl-ldap-keystone-pdf.pdf21:55
*** daemontool_ has joined #openstack-keystone21:55
annakoppad_can someone help?21:55
morganayoung: you can technically do it w/o the catalog21:55
morganayoung: but you have to pass other args to osc21:55
stevemarayoung: it functions, you have an admin user that can do admin-y stuff now21:55
ayoungmorgan, can you?21:55
morganayoung: it is much easier to do with the args to keystone-manage21:55
morganayoung: yes. it'sd the same way you used to pass old-admin token21:55
morganbefore the catalog was populated21:56
ayoungmorgan, say I did it without bootstrap, and I wanted to add a service catalog later.21:56
morganit is way more difficult to get right21:56
stevemarbknudson: yeah, all prefixed by --bootstrap-21:56
morganand has more edge-cases21:56
morganayoung: it is much better to add it via bootstrap21:56
stevemarannakoppad_: whats your local.conf look like?21:57
morganok i need lunch21:57
ayoungannakoppad_, I saw that error, too.  It looks like an error with Cinder21:58
ayoungI still got it once I unstacked and restacked, I tink...let me check21:59
ayoungNo, mine worked...lets see...21:59
ayoungI wanted to work devstack with just ENABLED_SERVICES=key,g-api,g-reg,rabbit,mysql22:00
bknudsonthat's how I run devstack22:01
*** Ephur has quit IRC22:01
annakoppad_I think I am going to sleep.its been a couple of times that I tried several workarounds for the same. Good night all. But I will be up tomorrow.22:03
*** ravelar has quit IRC22:03
*** ravelar has joined #openstack-keystone22:03
*** chlong has quit IRC22:06
stevemarannakoppad_: gn!22:06
mfischlbragstad: I just noticed we have some new errors in our Newton deploy22:07
stevemarmfisch: ?22:07
mfischits when ldappool binds to AD22:07
*** chlong has joined #openstack-keystone22:07
mfischI never saw it in M and keystone appear functional22:07
mfischits an LDAP invalid creds error which is odd22:08
bknudsonwe aim for appearing functional.22:08
mfischI can't cause it with a bad auth request22:08
mfischI was going to roll N into prod tomorrow but this is concerning22:08
*** annakoppad_ has left #openstack-keystone22:10
stevemarmfisch: we only had a few changes to ldappool after taking ownership of it22:10
mfischthis looks like a straight up fail to auth but odd that it just started showing up22:11
mfischor maybe its been there but the error stack changed?22:12
stevemarmfisch: maybe, only a handful of commits: https://github.com/openstack/ldappool/compare/1.0...2.0.022:12
*** chlong has quit IRC22:12
mfischI did go from 1->222:13
mfischstevemar: https://github.com/openstack/ldappool/commit/91f5cbc36f7bd9d3c0516249bcb871b8841a4f9622:14
mfischhmm thats not it22:14
mfischbut something being logged that wasnt before could be22:14
mfischstevemar: looks like python-ldap to pyldap?22:16
mfischthat could explain new behavior22:16
lbragstadmfisch hmmm - what's the error?22:19
mfischits that commit22:20
mfisch"Failure attempting to create and bind connector"22:20
mfischI do know for sure that we have packet loss between us and the LDAP server thats being worked on22:20
mfischwhich explains why its failing probably just that the message is new22:20
stevemarmfisch: ah okay22:22
stevemarthat makes sense22:22
* mfisch is unworried now22:22
stevemarmfisch: that one was merged before we took ownership of the project, it was just unreleased22:22
lbragstadmfisch move along citizen - nothing to see22:23
mfischif you are curious22:23
mfischhopefuly my password isnt in there22:23
mfischstevemar: you work at IBM you can probably decode those horrible AD codes22:23
lbragstadmfisch AD decoding is part of big blue orientation ;P22:24
*** david-lyle has joined #openstack-keystone22:24
mfischI worked at little blue so all I know is Itanium interrupt handling22:25
*** spilla has quit IRC22:32
*** dave-mccowan has joined #openstack-keystone22:32
*** daemontool_ has quit IRC22:33
*** dave-mcc_ has joined #openstack-keystone22:34
*** daemontool_ has joined #openstack-keystone22:34
*** dave-mccowan has quit IRC22:37
*** asettle has quit IRC22:40
stevemarerhm... DSID-0C0903A822:40
stevemaryep, no idea22:40
stevemarmfisch: little blue?22:40
stevemarmfisch: http://www.ca.com/us/services-support/ca-support/ca-support-online/knowledge-base-articles.tec1135548.html22:41
*** david-lyle has quit IRC22:41
*** david-lyle has joined #openstack-keystone22:41
stevemar"i'm helping" http://stream1.gifsoup.com/view6/4659509/i-m-ralph-o.gif22:42
openstackgerritRon De Rose proposed openstack/keystone: WIP - Require domain_id when registering Identity Providers  https://review.openstack.org/39968422:42
*** harlowja has quit IRC22:43
*** harlowja has joined #openstack-keystone22:43
*** david-lyle has quit IRC22:46
*** knasim-wrs has quit IRC22:48
*** adrian_otto has quit IRC22:50
*** chris_hultin|AWA is now known as chris_hultin22:50
*** edmondsw has quit IRC22:51
*** edmondsw has joined #openstack-keystone22:59
openstackgerritRichard Avelar proposed openstack/keystone: Print name with duplicate error on user creation  https://review.openstack.org/40510422:59
*** chris_hultin is now known as chris_hultin|AWA23:00
*** asettle has joined #openstack-keystone23:00
*** asettle has quit IRC23:01
*** rcernin has quit IRC23:02
*** jamielennox is now known as jamielennox|away23:05
ayoungmfisch, I'm going to go out on a limb here and say that you are trying to log in with invalid credentials23:05
ayoungwere you doing anonymous bind for the the service user in the past?23:06
*** edmondsw has quit IRC23:06
*** jamielennox|away is now known as jamielennox23:06
*** chris_hultin|AWA is now known as chris_hultin23:07
*** dave-mcc_ has quit IRC23:08
*** cbits has quit IRC23:11
mfischayoung: those errors are not when users fail to sign in, its our service account failing23:11
mfischwhich is why I suspect the packet loss, its caused similar issues23:11
mfischanyway I'm no longer worried, I suspect we've had it for a long time but just see the errors with the new ldappool module23:12
jamielennoxsorry i miseed the meeting earlier23:12
lbragstadjamielennox no worries23:13
lbragstadjamielennox everyone gets a mulligan from time to time23:13
morganjamielennox: i also missed the meeting23:31
morganjamielennox: sooooo23:31
jamielennoxmorgan: you had the topic i thought i should most listen to, so ok23:31
morganwhich one?23:32
morganMFA one?23:32
jamielennoxi figure i knew most of it23:32
morganyeah. lets just  discuss in IRC and get mordred to help doc it23:32
morganand then land it23:32
morganno meeting needed now23:32
morgansince it';s just context manager23:33
mordreduhoh. what did I do?23:33
mordredhahahah. morgan said "get mordred to help doc it"23:33
morganhelp document the contextmanager ksa session thing23:33
morgansince.. shade/nodepool uses it23:34
morganjust a concrete example or so23:34
morganmostly the docstrings are enough beyond that23:34
mordredI was actually planning on making a quick local patch on the plane to show shade usage of it - just in case any gotchas arise23:35
mordredso yeah - that's totes legit23:35
morganso lets use that as the example for docs :)23:35
*** diazjf has quit IRC23:35
*** masber has quit IRC23:37
openstackgerritRichard Avelar proposed openstack/keystone: Revert "Rename doctor symptom in security_compliance"  https://review.openstack.org/40776323:39
*** agrebennikov has quit IRC23:42
*** jaugustine has quit IRC23:49
ayoungmorgan, I like what I saw of it last...23:54
*** catintheroof has joined #openstack-keystone23:58
*** Marcellin__ has quit IRC23:59

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!