Wednesday, 2017-11-22

*** itlinux has joined #openstack-keystone00:24
*** itlinux has quit IRC00:50
*** Chealion has quit IRC00:57
*** Chealion has joined #openstack-keystone00:58
*** daidv has joined #openstack-keystone01:15
*** lxnch has quit IRC01:17
*** lxnch has joined #openstack-keystone01:18
*** rcernin has quit IRC01:29
*** rcernin has joined #openstack-keystone01:30
*** links has joined #openstack-keystone01:44
*** itlinux has joined #openstack-keystone01:45
*** itlinux has quit IRC01:53
*** zhouyaguo has joined #openstack-keystone01:53
*** kukacz has quit IRC02:00
*** kukacz_ has joined #openstack-keystone02:01
*** zhurong has joined #openstack-keystone02:16
*** annp has joined #openstack-keystone02:27
*** korean101 has joined #openstack-keystone02:39
korean101HI guys02:42
korean101how can i downgrade?02:42
korean101i finished to deploy ocata release02:43
korean101and i finished to deploy pike release02:43
korean101and upgrade ocata to pike release02:43
korean101now i try to downgrade pike --> ocata release02:43
korean101how can I?02:43
korean101or some manuals for me?02:43
*** itlinux has joined #openstack-keystone02:47
*** ayoung has joined #openstack-keystone03:14
*** itlinux has quit IRC03:27
*** ayoung has quit IRC03:40
openstackgerritwangxiyuan proposed openstack/keystone master: Add schema check for OS-TRUST:trust authentication
*** korean101 has left #openstack-keystone04:01
*** itlinux has joined #openstack-keystone04:01
*** zhurong has quit IRC04:48
*** BenderRodriguez has quit IRC04:50
*** aselius has quit IRC04:51
*** zhurong has joined #openstack-keystone05:13
*** BenderRodriguez has joined #openstack-keystone05:31
*** markvoelker has quit IRC05:53
openstackgerritwangxiyuan proposed openstack/keystone master: Add schema check for OS-TRUST:trust authentication
*** openstackgerrit has quit IRC06:33
*** _ix has quit IRC06:49
*** openstackgerrit has joined #openstack-keystone06:53
openstackgerritwangxiyuan proposed openstack/keystone master: Update the help message for unique_last_password_count
*** markvoelker has joined #openstack-keystone06:54
*** namnh has joined #openstack-keystone06:54
*** itlinux has quit IRC07:07
*** josecastroleon has joined #openstack-keystone07:09
*** rcernin has quit IRC07:17
*** d0ugal has quit IRC07:21
*** josecastroleon has quit IRC07:41
*** d0ugal has joined #openstack-keystone07:42
*** enriquetaso has quit IRC07:43
*** enriquetaso has joined #openstack-keystone07:43
*** threestrands has quit IRC07:47
*** pcaruana has joined #openstack-keystone07:49
*** hoonetorg has quit IRC07:58
*** josecastroleon has joined #openstack-keystone08:08
*** hoonetorg has joined #openstack-keystone08:12
*** tesseract has joined #openstack-keystone08:14
*** KwozyMan has joined #openstack-keystone08:31
*** magicboiz has joined #openstack-keystone08:40
*** zhouyaguo has quit IRC09:09
*** zhurong has quit IRC09:09
*** AlexeyAbashkin has joined #openstack-keystone09:38
*** gmann is now known as gmann_afk10:24
*** annp has quit IRC10:24
*** namnh has quit IRC10:42
*** magicboiz has quit IRC10:45
*** josecastroleon has quit IRC10:46
*** josecastroleon1 has joined #openstack-keystone10:46
*** tsufiev has quit IRC10:49
*** tsufiev has joined #openstack-keystone10:55
*** josecastroleon1 has quit IRC11:09
*** magicboiz has joined #openstack-keystone11:12
*** AlexeyAbashkin has quit IRC11:31
*** tsufiev has quit IRC11:31
*** AlexeyAbashkin has joined #openstack-keystone11:34
*** tsufiev has joined #openstack-keystone11:41
*** raildo has joined #openstack-keystone12:06
*** kukacz_ is now known as kukacz12:20
*** hoonetorg has quit IRC12:23
*** AlexeyAbashkin has quit IRC12:29
*** KwozyMan has quit IRC12:30
*** tsufiev has quit IRC12:30
*** sticker has joined #openstack-keystone12:32
*** KwozyMan has joined #openstack-keystone12:32
*** tsufiev has joined #openstack-keystone12:39
*** josecastroleon has joined #openstack-keystone12:41
*** AlexeyAbashkin has joined #openstack-keystone12:44
*** gmann_afk is now known as gmann12:51
*** spectr has joined #openstack-keystone12:53
*** spectr has quit IRC13:04
*** gmann is now known as gmann_afk13:11
*** zhouyaguo has joined #openstack-keystone13:18
*** arxcruz has quit IRC13:35
*** josecastroleon1 has joined #openstack-keystone13:39
*** josecastroleon has quit IRC13:39
*** magicboiz has quit IRC13:40
*** dave-mccowan has joined #openstack-keystone13:40
*** AlexeyAbashkin has quit IRC13:43
*** links has quit IRC13:44
*** dave-mcc_ has joined #openstack-keystone13:44
*** dave-mccowan has quit IRC13:45
*** josecastroleon1 has quit IRC13:49
*** AlexeyAbashkin has joined #openstack-keystone13:50
*** josecastroleon has joined #openstack-keystone14:10
*** spectr has joined #openstack-keystone14:27
*** KwozyMan has quit IRC14:29
*** jose-phillips has quit IRC14:46
*** jose-phillips has joined #openstack-keystone14:48
*** akrzos has quit IRC14:49
*** jose-phillips has quit IRC14:49
*** rcernin has joined #openstack-keystone14:51
*** sticker_ has joined #openstack-keystone14:53
*** sticker__ has joined #openstack-keystone14:54
*** d0ugal has quit IRC14:56
*** sticker has quit IRC14:57
*** sticker has joined #openstack-keystone14:57
*** sticker_ has quit IRC14:58
*** sticker_ has joined #openstack-keystone14:59
*** d0ugal has joined #openstack-keystone14:59
*** d0ugal has quit IRC14:59
*** d0ugal has joined #openstack-keystone14:59
*** sticker__ has quit IRC15:00
*** sticker__ has joined #openstack-keystone15:00
*** sticker has quit IRC15:02
*** spectr has quit IRC15:03
*** sticker_ has quit IRC15:04
*** akrzos has joined #openstack-keystone15:04
*** sticker__ has quit IRC15:05
*** _ix has joined #openstack-keystone15:07
*** rmascena has joined #openstack-keystone15:09
*** raildo has quit IRC15:09
*** josecastroleon has quit IRC15:15
*** sticker has joined #openstack-keystone15:16
*** rcernin has quit IRC15:18
*** rmascena has quit IRC15:19
*** rmascena__ has joined #openstack-keystone15:19
*** rmascena__ is now known as raildo15:25
*** AlexeyAbashkin has quit IRC15:49
*** magicboiz has joined #openstack-keystone15:58
*** magicboiz has quit IRC16:08
openstackgerritColleen Murphy proposed openstack/keystone-specs master: Repropose application credentials to queens
cmurphymordred: lbragstad kmalloc ^16:20
*** magicboiz has joined #openstack-keystone16:21
lbragstadcmurphy: sweet - i'll review today for sure16:22
*** magicboiz has quit IRC16:26
*** itlinux has joined #openstack-keystone16:26
*** magicboiz has joined #openstack-keystone16:26
*** sticker has quit IRC16:27
lbragstadcmurphy: so - we're blacklisting the ability to get a token with an application credential?16:32
lbragstad(POST /v3/auth/tokens)16:33
cmurphylbragstad: that's my idea, what do you think?16:34
cmurphylbragstad: otherwise how do we prevent it from creating a new token that can circumvent the method check?16:35
cmurphyor can we implement this somehow in policy and not by looking at the token?16:35
lbragstadthis is to make sure we have a token that we can use to blacklist operations, right?16:36
lbragstadas the server, we need to know if this is an application credential token so that we can safeguard against bad things?16:36
cmurphylbragstad: right - so in my mind (maybe i'm on the wrong track) an application credential can of course get a token but it shouldn't be able to use that token just for getting a new token16:38
lbragstadthe first token's methods should be ['application-credential']16:38
lbragstadand the concern is that the second token's would be ['token']16:38
lbragstadok - we're on the same page then16:39
lbragstadwhen you get a token with a password the original methods are ['password']16:39
lbragstadthen if you rescope that token to get a new one, the methods should be ['password', 'token']16:39
lbragstadat least that's how i recall it working16:40
cmurphyoh i see, so this would be unnecessary16:40
lbragstadwell - if it works that way for other combinations of authentication and token scoping16:40
lbragstadwe might be able to build off of that behavior for this16:40
lbragstadbut still be able to blacklist based on 'application-credential' being in methods16:41
cmurphythere was a concern at the PTG about being able to circumvent this check, was it because of this or was it because of something else?16:41
lbragstadis there an example of the concern?16:42
lbragstadi can't remember it exactly16:42
cmurphyi don't have a specific one, i remember it came up when we were talking about heat16:42
lbragstadok - thinking about this from step 116:44
lbragstadwe have an application that monitors resources in our project16:44
lbragstadbut token expiration is defaulted to an hour16:44
lbragstadand the application checks ~30 minutes to see if things change or whatnot16:45
lbragstadan hour and a half in, wouldn't the application need to get a new token to continue monitoring resources?16:45
*** itlinux has quit IRC16:47
cmurphylbragstad: but couldn't it do that by using the id/secret instead of the token?16:47
cmurphylbragstad: but in any case i think you're right, this shouldn't be necessary16:47
openstackgerritColleen Murphy proposed openstack/keystone-specs master: Repropose application credentials to queens
lbragstadcmurphy: oh - yeah i guess we could limit application credentials to only reauthenticating...16:49
lbragstadbut... if an application-credential token is used to do something in another service, won't the service be validating that token?16:52
lbragstadso keystone should be able to validate those16:52
cmurphylbragstad: yeah i think i was missing some pieces, i removed that bit16:53
lbragstad(thinking if an application creates and instance and nova passes an application credential scoped token to glance to pull an image)16:53
*** tesseract has quit IRC16:57
*** itlinux has joined #openstack-keystone17:02
*** aojea has joined #openstack-keystone17:10
*** _ix has quit IRC17:12
*** itlinux has quit IRC17:15
*** pcaruana has quit IRC17:18
*** zhouyaguo has quit IRC17:24
*** josecastroleon has joined #openstack-keystone17:28
kmalloclbragstad, cmurphy: I glossed over app creds being under /project17:32
kmalloci *very* much dislike that17:32
kmalloci would have come out much more strongly against the proposal had I been paying a bit closer attention to that17:32
kmalloccredentials are not a project thing. they are always a user thing. they may have limited scope17:33
*** AlexeyAbashkin has joined #openstack-keystone17:33
kmallocI also do not agree with anyone-in-a-project-with-write-access-can-delete-creds17:33
lbragstadkmalloc: being under /project in the path?17:35
kmallocas part of the project api17:35
lbragstadi don't think that was ever proposed17:35
lbragstadif it was, i missed it17:35
kmalloclbragstad: based on cmurphy's comment: If we don't support general credential management by the whole project team, then it really stops making sense for this API to live under /projects and should be moved to /users.17:36
kmalloclbragstad: i'm very strongly -1 on it being under /project unless someone can sway me with a really strong case, possibly even -2.17:37
kmallocthis was in regards to the anyone with write access deleting a cred17:37
kmalloc(to the project)17:37
*** AlexeyAbashkin has quit IRC17:38
lbragstadi'm missing how application credentials are under /project... if by under /project you mean being able to delete creds based on writeable roles, then i get it17:38
lbragstadbut i don't think that has anything to do with the path17:38
kmallocright. i'm very confused now17:38
*** josecastroleon has quit IRC17:38
kmallocso, i think i need clarification on what is actually being proposed now =/17:39
lbragstadso - that was the requirement where an application credential needs to be managed when someone leaves the team17:40
kmallocbecause that comment is making me worried where this is planned on living17:40
lbragstadapplication credentials are still going to be tied to the user17:40
lbragstadthat hasn't changed17:40
kmallocand if someone leaves the team - the user is either losing the RBAC *or* deleted17:40
kmallocin either case the cred should be auto-deleted17:40
kmallocso -1 (possibly -2) on allowing direct deletion of app creds by *anyone* who has write access on the project17:40
*** edmondsw has joined #openstack-keystone17:41
kmallocit's a user's resource17:41
kmallockeystone should be handling the app-cred deletion internally.17:41
lbragstador handling it in the revoke case17:41
kmallocit's not a "user who has write on project X, deletes another user's app cred"17:41
lbragstadthat was part of the management bit, before a user leaves a team, another team member could rotate things out17:42
lbragstadand assume ownership of the application by updating the application credential17:42
lbragstadessentially the workaround to having application credentials tied to the lifecycle of the project instead of the user17:43
kmalloclbragstad: still a hard -1 from me on that17:44
kmallocthere is zero reason to need that for a work-around. before user leaves team, create new cred, update places that use it, remove old user.17:45
kmallocit's needless allowance of cross-ownership resource manipulation17:46
*** itlinux has joined #openstack-keystone17:49
lbragstadkmalloc: have you left a comment on the spec yet?17:49
*** aojea has quit IRC17:58
*** aojea has joined #openstack-keystone17:58
*** aojea has quit IRC17:58
*** aojea has joined #openstack-keystone17:58
mordredlbragstad, cmurphy: we discussed making the prevention of using an app-cred to create an app-cred tied to a role or policy thing- so that in some cases a user could be granted the role that would let them use an app-cred to create an app-cred (the driving use-case for that is heat needing to be able to make per-vm app-creds)18:00
* mordred hasn't read the whole scrollback yet18:00
kmallocmordred: that is fine, it's an API so we can gate on RBAC for it18:05
kmallocand prevent sub-app-creds18:05
kmallocthat's the easy part (so to speak)18:05
kmallocthe part i'm not happy about is the concept that anyone with write access to the project can delete any app-cred associated with the project18:06
kmalloc(or a specific app-cred-delete role)18:06
mordredkmalloc: yah - I don't think that's important any more with app-creds no longer being owned by a project18:07
mordredthat would be important if they had a project lifecycle rather than a user lifecycle, otherwise FAIL18:08
mordredbut since they don't, I agree18:08
kmallocand since we're user-lifecycle i'm a hard -1 on that project-lifecycle supprot bit18:08
kmallocmordred: ++ cool, we're on the same page18:08
kmallocotherwise i think the spec is solid18:09
lbragstadok - we can work that in18:10
*** aojea has quit IRC18:17
openstackgerritLance Bragstad proposed openstack/keystone master: Expose a bug when authenticating for a trust-scoped token
lbragstadwxy_: ^ that should expose the behavior you're fixing, you should be able to rebase on that and update the test in your patch (removing the wip decorator)18:50
*** edmondsw has quit IRC19:16
*** edmondsw has joined #openstack-keystone19:28
*** edmondsw has quit IRC19:32
*** aojea has joined #openstack-keystone19:52
*** edmondsw has joined #openstack-keystone20:02
*** edmondsw has quit IRC20:06
*** itlinux has quit IRC20:25
*** aselius has joined #openstack-keystone20:29
*** nkinder has quit IRC20:58
*** nkinder has joined #openstack-keystone21:01
mgagneis there a technical reason to not allow a cloud_admin to list a user's projects?
*** linkmark has joined #openstack-keystone21:13
*** jmlowe has joined #openstack-keystone21:32
lbragstadmgagne: if i understand that policy correctly, it's making sure the target user is within the domain the cloud admin is in21:39
*** dave-mcc_ has quit IRC21:39
mgagneok, I'm having problem making it work. my cloud admin is in the default domain and it's being denied although the target user is in the default domain too.21:40
mgagneit looks like the "domain_id:%(domain_id)s" part is not evaluating to True. I thought you needed a domain scoped token to get domain_id defined properly but no luck here.21:41
mgagnebut also, I'm not sure why a cloudadmin which is a super mega admin couldn't make this call and why rule:cloud_admin isn't used21:42
mgagnelbragstad: ^21:42
lbragstadmgagne: this sounds familiar to another bug that was just reported...21:43
lbragstadmgagne: let me grab the link21:44
*** threestrands has joined #openstack-keystone21:45
*** threestrands has quit IRC21:45
*** threestrands has joined #openstack-keystone21:45
*** jmlowe has quit IRC21:45
openstackLaunchpad bug 1732502 in OpenStack Identity (keystone) "project-list command does not work for a user with admin role on domain" [Undecided,New]21:47
lbragstadsounds like the same thing you're hitting21:47
lbragstadi think that was recreated using Newton21:47
mgagneI'm running Pike 12.0.021:48
*** raildo has quit IRC21:48
mgagneI'll read the bug and see if there is anything I can learn from it. otherwise yes, the domain_id part is problematic in my case21:49
lbragstadmgagne: it sounds really familiar to what you described21:50
lbragstadwxy_: FYI - cmurphy proposed this a while ago and you might be able to leverage some of it
mgagnethere is debug log I can read where I see domain_id defined with a domain scoped token (unlike a project scoped token). but still no success with the policy.21:51
mgagneI'm not hitting his problem because the user I'm testing with is a cloud_admin and the policy for identity:list_projects allows cloud_admin. (unlike identity:list_user_projects)21:54
mgagneI'll try with a domain admin instead...21:54
mgagnelbragstad: ok, I'm able to reproduce the bug linked above with a domain admin (not cloud admin)21:58
lbragstadok - you were able to recreate it with pike?21:59
lbragstadi wonder if it is recreateable in master then, too?21:59
mgagneso I think it's the same root cause where domain_id is not properly evaluated21:59
lbragstadwe don't have that great of test coverage with that specific policy file21:59
mgagneI could try but my setup doesn't allow me to easily test master21:59
mgagnewell, it's for keystone v3... and v2 is gone22:00
mgagneso I'm not sure what this is suppose to mean22:00
lbragstadright - but most of our unit tests in test the default policies22:00
mgagnewhich are v3 ? or "old" v2 default?22:00
lbragstadthe current default are very much geared towards v2.022:01
lbragstadbut we are working on a way to start deprecating them and moving towards something more sane22:01
mgagneIMO, it should be v3 because... come on =)22:01
lbragstadright - i know, i completely agree22:01
lbragstadthe problem is that we never really had a way to signal that those defaults are changing to operators22:02
mgagneI think it's unrelated because policies are not deprecated, they are getting their default value replaced?22:02
mgagneunless I'm mistaking the purpose/scope of the change22:02
lbragstadyeah - but that can still break a deployment22:02
mgagneok so review supports change in default rule?22:03
lbragstadthat change should allow us to change the default22:03
mgagnegood stuff then =)22:03
mgagneso if v3 sample is not tested, this could mean 2 things: domain_id is bugged and/or default rule is wrong (missing cloud_admin IMO)22:04
lbragstadexample and documentation if you care to see how it's used -
lbragstadmgagne: yeah - that could be22:04
mgagneI'll work from there then and add my finding to the bug. thanks!22:06
lbragstadmgagne: cool - thank you22:06
*** AlexeyAbashkin has joined #openstack-keystone22:09
*** Dinesh_Bhor has quit IRC22:11
*** gagehugo has quit IRC22:13
*** AlexeyAbashkin has quit IRC22:13
*** rcernin has joined #openstack-keystone22:20
openstackgerritGage Hugo proposed openstack/keystone master: Have project get domain_id from parent
*** jmlowe has joined #openstack-keystone22:32
*** aojea has quit IRC22:44
*** aojea has joined #openstack-keystone22:44
*** aojea has quit IRC22:48
lbragstadfor those traveling and taking time off, have a safe thanksgiving!22:51
lbragstadi'll be here friday if anyone needs anything22:52
*** aojea has joined #openstack-keystone22:53
*** aojea has quit IRC22:59
*** AlexeyAbashkin has joined #openstack-keystone23:08
*** AlexeyAbashkin has quit IRC23:12
*** lbragstad has quit IRC23:23
*** edmondsw has joined #openstack-keystone23:54
*** edmondsw has quit IRC23:59

Generated by 2.15.3 by Marius Gedminas - find it at!