Monday, 2017-04-03

*** henrynash has joined #openstack-keystone00:03
*** masber has joined #openstack-keystone00:05
*** aojea has joined #openstack-keystone00:30
*** aojea has quit IRC00:35
*** erlon has quit IRC00:45
*** jamielennox|away is now known as jamielennox01:06
*** richm has quit IRC01:15
*** stradling has quit IRC01:22
*** thorst has joined #openstack-keystone01:37
*** thorst has quit IRC01:42
*** namnh has joined #openstack-keystone01:48
*** tovin07 has joined #openstack-keystone01:50
*** rcernin has joined #openstack-keystone01:58
openstackgerritSean McCully proposed openstack/keystoneauth master: KeystoneAuth should default to system CAFile.
*** thorst has joined #openstack-keystone02:38
*** rcernin has quit IRC02:45
*** catintheroof has joined #openstack-keystone02:55
*** dave-mccowan has joined #openstack-keystone02:55
*** thorst has quit IRC02:57
*** dave-mcc_ has quit IRC02:57
*** dave-mccowan has quit IRC03:05
*** namnh has quit IRC03:06
openstackgerritSean McCully proposed openstack/keystoneauth master: KeystoneAuth should default to system CAFile.
*** thorst has joined #openstack-keystone03:54
*** thorst has quit IRC03:58
*** Dinesh_Bhor has joined #openstack-keystone04:01
*** catintheroof has quit IRC04:10
*** thorst has joined #openstack-keystone04:54
*** rcernin has joined #openstack-keystone04:56
*** thorst has quit IRC04:59
openstackgerritSean McCully proposed openstack/keystoneauth master: KeystoneAuth should default to system CAFile.
*** knangia has joined #openstack-keystone05:07
*** lamt has quit IRC05:14
*** rcernin has quit IRC05:18
*** rcernin has joined #openstack-keystone05:31
*** IRCFrEAK has joined #openstack-keystone05:49
*** IRCFrEAK has left #openstack-keystone05:50
*** Aqsa has joined #openstack-keystone05:54
*** adriant has quit IRC05:55
*** thorst has joined #openstack-keystone05:55
*** thorst has quit IRC05:59
*** oomichi has quit IRC06:03
*** oomichi has joined #openstack-keystone06:04
openstackgerritSean McCully proposed openstack/keystoneauth master: KeystoneAuth should default to system CAFile.
*** oomichi has quit IRC06:29
*** oomichi has joined #openstack-keystone06:30
*** voelzmo has joined #openstack-keystone06:31
*** tesseract has joined #openstack-keystone06:34
*** Elaine_wu has joined #openstack-keystone06:35
*** hoonetorg has quit IRC06:37
*** wuyanjun has quit IRC06:38
*** voelzmo has quit IRC06:38
*** voelzmo has joined #openstack-keystone06:42
*** belmoreira has joined #openstack-keystone06:50
*** thorst has joined #openstack-keystone06:56
*** pcaruana has joined #openstack-keystone06:57
*** jaosorior has joined #openstack-keystone06:57
*** thorst has quit IRC07:00
*** Aqsa has quit IRC07:21
*** aojea has joined #openstack-keystone07:21
openstackgerritMerged openstack/keystone master: Differentiate between dpkg and rpm for libssl-dev
*** knangia has quit IRC07:31
openstackgerritMerged openstack/keystone master: Remove unnecessary setUp function in testcase
*** thorst has joined #openstack-keystone07:56
*** zzzeek has quit IRC08:00
*** zzzeek has joined #openstack-keystone08:00
*** bjornar_ has joined #openstack-keystone08:01
*** openstackgerrit has quit IRC08:03
*** tuan_ has joined #openstack-keystone08:09
tuan_Morning guys08:10
tuan_i have had a look to the patch of "allow fetching an expired token" in keystone08:11
tuan_it is merged in octaka08:11
tuan_does it mean that with the service-token fetched in request, from Octaka, keystone allows this feature08:11
tuan_therefore with the deffered actions later, we do not need to worry about the expired tokens08:12
*** Aqsa has joined #openstack-keystone08:12
*** thorst has quit IRC08:16
*** aojea_ has joined #openstack-keystone08:21
*** aojea has quit IRC08:24
*** lxnch_ has joined #openstack-keystone08:51
*** mtreinish has quit IRC08:53
*** lxnch has quit IRC08:55
*** sjain has joined #openstack-keystone08:57
*** mtreinish has joined #openstack-keystone08:57
*** sjain has quit IRC09:04
*** Aqsa has quit IRC09:04
*** henrynash has quit IRC09:04
*** openstackgerrit has joined #openstack-keystone09:13
openstackgerritSamriddhi proposed openstack/keystoneauth master: Updated inconsistent value of scope parameter
*** thorst has joined #openstack-keystone09:13
*** thorst has quit IRC09:17
*** szaher has quit IRC09:25
*** szaher has joined #openstack-keystone09:30
*** szaher has quit IRC09:33
*** szaher has joined #openstack-keystone09:39
*** Aqsa has joined #openstack-keystone10:00
*** tovin07 has quit IRC10:01
*** szaher has quit IRC10:01
*** szaher has joined #openstack-keystone10:04
*** rcernin has quit IRC10:05
*** hoonetorg has joined #openstack-keystone10:07
*** szaher has quit IRC10:10
*** szaher has joined #openstack-keystone10:11
*** nicolasbock has joined #openstack-keystone10:23
*** rcernin has joined #openstack-keystone10:24
*** raildo has joined #openstack-keystone10:45
*** ayoung has quit IRC11:05
*** ayoung has joined #openstack-keystone11:07
*** tuan_ has quit IRC11:11
*** Aqsa has quit IRC11:13
*** Aqsa has joined #openstack-keystone11:14
*** 07EAANV6F has joined #openstack-keystone11:16
*** thorst has joined #openstack-keystone11:34
*** thorst has quit IRC11:36
*** ma9_ has joined #openstack-keystone11:45
*** jgr is now known as jgrassler11:49
*** voelzmo has quit IRC11:52
*** voelzmo has joined #openstack-keystone11:53
openstackgerritM V P Nitesh proposed openstack/keystonemiddleware master: replace_six_iteritems
*** thorst has joined #openstack-keystone12:00
*** henrynash has joined #openstack-keystone12:01
*** Aqsam has joined #openstack-keystone12:01
*** Aqsa has quit IRC12:03
*** henrynash has quit IRC12:04
*** henrynash has joined #openstack-keystone12:05
*** henrynash has quit IRC12:06
*** nle5223__ has joined #openstack-keystone12:25
*** Aqsam has quit IRC12:27
*** henrynash has joined #openstack-keystone12:31
*** edmondsw has joined #openstack-keystone12:32
*** jaosorior is now known as jaosorior_brb12:36
dolphmif anyone is interested in reviewing this nova-spec, i think it would benefit from feedback from the keystone community
dolphmcc- lbragstad ^12:47
dolphmlbragstad: would be relevant to rderose and jamielennox, for sure12:48
lbragstaddolphm nice - i just starred it12:49
*** ravelar has joined #openstack-keystone12:50
openstackgerritM V P Nitesh proposed openstack/python-keystoneclient master: Replace six.iteritems() with .items()
*** spilla has joined #openstack-keystone12:57
*** voelzmo has quit IRC13:03
*** cristicalin has joined #openstack-keystone13:08
cristicalindoes anybody have a config example for keystone with redis as the caching backend ?13:09
*** adu has quit IRC13:13
*** mordred has left #openstack-keystone13:15
*** mordred has joined #openstack-keystone13:16
*** stradling has joined #openstack-keystone13:18
dstanekdolphm: do you know what the usecase is for that?13:19
ma9_Does the Openstack CLI support a Keystone which uses OIDC as backend?13:21
*** bjornar_ has quit IRC13:24
*** ayoung has quit IRC13:26
openstackgerritM V P Nitesh proposed openstack/keystonemiddleware master: replace_six_iteritems
*** catintheroof has joined #openstack-keystone13:31
*** belmorei_ has joined #openstack-keystone13:31
*** jaosorior_brb is now known as jaosorior13:33
*** belmoreira has quit IRC13:33
*** voelzmo has joined #openstack-keystone13:33
*** ma9_1 has joined #openstack-keystone13:37
*** ma9_ has quit IRC13:39
openstackgerritRichard Avelar proposed openstack/keystone master: Remove unused methods in unit test test_revoke
openstackgerritRichard Avelar proposed openstack/keystone master: Refactor test_revoke to call check_token directly
*** stradling has quit IRC13:48
*** cristicalin has quit IRC13:53
*** knangia has joined #openstack-keystone13:56
*** henrynash has quit IRC13:58
*** belmorei_ has quit IRC13:58
dolphmdstanek: there were a few that came up, and there's a few already in openstack. for example, glance creates a container in swift to store your images, but you shouldn't be able to mess with them through swift13:59
*** voelzmo has quit IRC14:00
dolphmdstanek: same for snapshots, etc.14:00
dolphmdstanek: and a bunch of the services that layer on top of openstack IaaS don't want you to be able to mess with those resources without going through them14:01
*** belmoreira has joined #openstack-keystone14:01
openstackgerritRichard Avelar proposed openstack/keystone master: Remove unused method _sample_data in test_revoke
dstanekdolphm: gotcha...the spec was lacking examples when i did a quick pass-thru14:04
dolphmdstanek: kubernetes VMs, maybe octavia VMs (although they don't want to consume the user's VM quota)14:04
dolphmdstanek: it definitely is14:05
dolphmdstanek: my high level criticism of the spec is that there seems to be an opportunity to create a generalized solution for all openstack services, rather than something nova-specific and having to generalize later14:06
*** belmoreira has quit IRC14:06
dolphmi.e. the problem is not limited in scope to nova14:06
*** lucasxu has joined #openstack-keystone14:06
*** voelzmo has joined #openstack-keystone14:08
*** voelzmo has quit IRC14:08
*** henrynash has joined #openstack-keystone14:11
*** voelzmo has joined #openstack-keystone14:14
ma9_1about my previous question on whether OpenStack CLI work with OpenID Connect, I found this blueprint:
ma9_1I guess it means it's not implemented yet.14:37
lbragstadma9_1 keystone supports oidc, that spec is specifically to improve certain aspects of it.14:40
lbragstadma9_1 which is laid out in more detail here -
lbragstadbut that's all keystone server related work14:40
lbragstadand doesn't really consist of any client changes14:40
*** nicolasbock has quit IRC14:41
lbragstadma9_1 it looks like python-keystoneclient does have an oidc authentication method - which might be exposed through python-openstackclient14:42
*** chlong has joined #openstack-keystone14:45
*** nicolasbock has joined #openstack-keystone14:48
*** rderose has joined #openstack-keystone14:56
openstackgerritRichard Avelar proposed openstack/keystone master: Move and refactor test_by_domain_user
*** stradling has joined #openstack-keystone15:01
*** voelzmo has quit IRC15:01
*** voelzmo has joined #openstack-keystone15:02
*** voelzmo has quit IRC15:02
openstackgerritRichard Avelar proposed openstack/keystone master: Move and refactor test_by_domain_project
*** agrebennikov has joined #openstack-keystone15:17
*** dave-mccowan has joined #openstack-keystone15:20
openstackgerritRichard Avelar proposed openstack/keystone master: Move and refactor test_by_domain_domain
openstackgerritRichard Avelar proposed openstack/keystone master: Remove unused methods in unit test test_revoke
*** adrian_otto has joined #openstack-keystone15:26
*** agrebennikov has quit IRC15:27
*** henrynash has quit IRC15:31
*** tesseract has quit IRC15:31
openstackgerritRichard Avelar proposed openstack/keystone master: Move and refactor test_by_domain_domain
*** thorst is now known as thorst_afk15:33
*** 07EAANV6F has quit IRC15:36
*** aojea_ has quit IRC15:45
*** richm has joined #openstack-keystone15:46
*** mvk has quit IRC15:47
*** nle5223__ has quit IRC15:52
*** pcaruana has quit IRC15:53
*** stradling has quit IRC16:00
*** adrian_otto has quit IRC16:05
*** ma9_1 has quit IRC16:17
*** ma9_ has joined #openstack-keystone16:18
*** d0ugal has quit IRC16:19
*** ma9_ has quit IRC16:22
*** lucasxu has quit IRC16:25
*** ma9_ has joined #openstack-keystone16:28
openstackgerritKristi Nikolla proposed openstack/keystone master: URL pattern based RBAC Management Interface
*** stradling has joined #openstack-keystone16:35
*** thorst_afk is now known as thorst16:42
openstackgerritOpenStack Proposal Bot proposed openstack/keystone master: Updated from global requirements
jaosoriorHey guys, were these options deprecated?
*** ma9_ has quit IRC16:55
knikollajaosorior: yep16:56
knikollajaosorior: some of them, so read the help16:56
*** stradling has quit IRC16:57
jaosoriorknikolla: what about identity_uri?16:57
lbragstadthat one shouldn't be deprecated16:57
knikollajaosorior: identity_uri is not deprecated.16:57
lbragstadjaosorior is it advertised as deprecated?16:57
lbragstadjaosorior or are you seeing it as deprecated somewhere?16:57
jaosoriorEmilienM: ^^16:59
jaosoriorlbragstad: it's not advertised. Just wondering cause it was unclear. Thanks for the info.16:59
EmilienMjaosorior: ok thanks. Sorry for confusion17:00
EmilienMI don't know why but I always believed that auth_uri and auth_url was enough17:00
lbragstadjaosorior which part was unclear specifically, the usage of identity_uri?17:00
jaosoriorlbragstad: identity_uri isn't mentioned in the keystonemiddleware docs. So it's a bit confusing17:00
lbragstadjaosorior ah - sure17:01
jaosorioractually, the deprecated options are still there.17:01
* lbragstad goes to pull up the ksm docs17:01
EmilienMwhen do we need identity_uri?17:02
lbragstadEmilienM jaosorior knikolla so in the configuration section we have a section that uses the deprecated options -
lbragstadfor example -
knikollalbragstad: adding it on my todo list17:04
knikollashould be a quick fix17:04
lbragstadknikolla ++17:04
lbragstadknikolla i'm creating a bug report so we can track it17:05
knikollalbragstad: sounds good. assign me.17:05
*** chlong has quit IRC17:05
*** stradling has joined #openstack-keystone17:09
*** adrian_otto has joined #openstack-keystone17:10
lbragstadknikolla EmilienM jaosorior
openstackLaunchpad bug 1679238 in keystonemiddleware "documented config options are deprecated" [Medium,Confirmed] - Assigned to Kristi Nikolla (knikolla)17:10
EmilienMbut we don't need identity_uri if we use auth_url and auth_uri, right?17:11
jaosoriorlbragstad: ^^17:12
knikollaEmilienM: IIRC, those options were not in the authtoken group. but in some other section of the service conf17:13
lbragstadknikolla correct17:13
lbragstadinstead of using auth_admin_prefix, auth_host, auth_port, and auth_protocol, identity_uri should be used17:14
jaosoriorknikolla, lbragstad it is in the keystone_authtoken group as far as I can see17:14
*** d0ugal has joined #openstack-keystone17:14
knikollayes, but there is no auth_uri, url there. so the docs are probably wrong.17:15
*** chlong has joined #openstack-keystone17:21
EmilienMwe have been using auth_uri and auth_url for some time now and everything is fine17:21
EmilienMwe don't use identity_uri for long time17:21
jaosoriorunder the kestone_authtoken group17:21
EmilienMthat is what our nova deployment is using:
EmilienMand it works perfectly fine17:23
EmilienMthe whole config file is here:
lbragstadknikolla we should make a note to look into auht_url/auth_uri and see what the differences are from identity_uri17:25
*** jaosorior is now known as jaosorior_away17:29
jaosorior_awaylbragstad, knikolla: Thanks for looking into it.17:29
lbragstadjaosorior_away thanks for bringing it to our attention17:30
EmilienMlbragstad: is there anything wrong in our config?17:30
* lbragstad EmilienM this is your auth_token section specifically -
EmilienMlbragstad: yes, it is. And is it good?17:32
*** nicolasbock has quit IRC17:35
lbragstadEmilienM double checking it against whats in keystonemiddleware17:36
lbragstadEmilienM aha - so I think I'm getting things figured out here17:38
lbragstadwe shouldn't be using identity_uri either17:38
lbragstadcc knikolla ^17:38
EmilienMah :)17:38
EmilienMI KNEW IT lol17:38
lbragstadknikolla those directions really need to be updated with some context around the fact that ksm *now* relies on keystoneauth for all the plugin bits17:38
EmilienMcan I get my keystone sticker now?17:39
lbragstadEmilienM i thought you already had one!17:39
EmilienMnope :(17:39
notmorganEmilienM: the keystone sticker is a lie (just like the cake)17:39
* lbragstad writes EmilienM's name on a sticker17:40
lbragstadEmilienM here is where we ask for a plugin name -
SamYaplewith keystone v3, do keystone-wsgi-admin and keystone-wsgi-public do the same thing?17:41
lbragstadSamYaple yes17:41
SamYapleso i can safely jut run one of them? sweet17:41
lbragstadSamYaple correct - in v2.0 we had two separate endpoints, one for admin things and one for user things (basically just authenticate and validate)17:42
lbragstadso it was a way to use two separate applications to enforce policy17:42
SamYapleright. im doing a uwsgi deploy orchestration for the first time and wanted to make sure i had my facts straight17:43
SamYaplethanks. always helpful in here17:43
lbragstadwith one of the goals of v3 to provide/implement a better policy model, the two separate API endpoints were merged together into a single application17:43
lbragstadSamYaple good deal!17:43
lbragstadEmilienM so if you look at
lbragstadEmilienM you'll see that we use keystoneauth to load a plugin, and only if we can't do that do we actually rely on the AuthTokenPlugin module17:44
lbragstadEmilienM which is using/defining some of those deprecated options17:44
*** lucasxu has joined #openstack-keystone17:47
*** ayoung has joined #openstack-keystone17:49
*** stradling has quit IRC17:49
*** jamielennox is now known as jamielennox|away17:50
*** nicolasbock has joined #openstack-keystone17:51
*** d0ugal has quit IRC17:59
knikollalbragstad: oooo right. i remember now.18:09
knikollalbragstad: so should we deprecate the others too?18:09
*** harlowja has joined #openstack-keystone18:12
knikollaayoung: is passing now. had to fix a few small things.18:13
*** TravT has quit IRC18:14
ayoungknikolla, Merge it!18:16
ayoungknikolla, ModelDictMixinWithExtras.  Lovely18:17
knikollaayoung: sounds like a plan. i'll also play a bit around with the api.18:18
knikollaayoung: should i start on the ksm change in the meanwhile?18:18
ayoungknikolla, need the client change first18:19
knikollaright. s/play around with the api/write a client for the api/g18:19
*** d0ugal has joined #openstack-keystone18:20
knikollaayoung: argh, i messed up the bp name again. it's role-check-from-middleware18:21
ayoungknikolla, you can edit that right in the web browser18:22
knikollaayoung: yep, gonna do that now.18:22
openstackgerritKristi Nikolla proposed openstack/keystone master: URL pattern based RBAC Management Interface
knikollaayoung: done. you can reiterate your +1.18:23
*** ravelar has quit IRC18:25
*** victorssilva_ has joined #openstack-keystone18:26
*** ravelar has joined #openstack-keystone18:28
*** stingaci has joined #openstack-keystone18:33
*** victorssilva_ has quit IRC18:37
*** bjornar_ has joined #openstack-keystone18:39
openstackgerritKristi Nikolla proposed openstack/python-keystoneclient master: WIP - Client functions for url_patterns
*** rmascena has joined #openstack-keystone18:41
*** raildo has quit IRC18:41
*** ravelar1 has joined #openstack-keystone18:42
*** ravelar1 has quit IRC18:42
*** ravelar1 has joined #openstack-keystone18:42
*** ravelar has quit IRC18:42
*** ravelar1 is now known as ravelar18:43
*** ravelar1 has joined #openstack-keystone18:48
*** aojea has joined #openstack-keystone19:01
*** rderose has quit IRC19:02
*** adrian_otto has quit IRC19:04
*** agrebennikov has joined #openstack-keystone19:06
ayoungdstanek, would appreciate a review on
ayoungOr I could just merge now :)19:18
lbragstadayoung the spec hasn't even been proposed to pike yet19:18
ayounglbragstad, yes it has19:18
ayounglbragstad, so what.  Spec was approved.  Just merging it for pike is just a commitment to releasing it in Pike19:19
ayounglbragstad, undercommit and oversomethingsomething19:19
lbragstadayoung there are several parts of that spec that are out-dated an misleading19:19
ayounglbragstad, eyebrows?19:20
ayounglbragstad, primary assignee is still me.  Other contributors listed just for citation sake19:21
ayounglbragstad, do you have any real objections to the approach?19:21
lbragstadayoung my primary objection is that most of the conversations we had around the approach were never finished19:22
lbragstadwe *just* started getting into discussions with other projects on the approach when the spec merged to ongoing19:22
ayounglbragstad, were there any other proposals on the table?  has anyone actually either proposed a solution to RBAC, or provided a criticism of a problem with this approach?19:23
*** d0ugal has quit IRC19:23
lbragstadayoung no one is telling you this can't happen19:23
openstackgerritRichard Avelar proposed openstack/keystone master: Move and refactor project_and_user_and_role
ayounglbragstad, is there any other effort being made?19:24
lbragstadayoung sure19:24
lbragstadantwash and ravelar did a whole bunch of work to improve the policy we have19:24
ayounglbragstad, I know, this is a bit of a rush, as it has only been out for review since November.  Kindof fast by Keystone standards.19:24
ayounglbragstad, the RBAC side or just policy-in-code for scope check?19:25
lbragstadayoung did you ever follow up with johnthetubaguy and oomichi about their concerns here?
ayounglbragstad, I'm not really planning on merging it myself.  But some actual review of the change would be nice.19:25
*** d0ugal has joined #openstack-keystone19:25
ayounglbragstad, yeah.  The biggest issue is that the Nova API sucks and RBAC would be of limited value there19:26
ayounglbragstad, but they accepted that they could always do more finegrained checks inside nova if they wanted19:26
lbragstadayoung just because another project made a mistake in their implementation doesn't mean we just write their usecases off19:26
ayounglbragstad, exactly19:27
lbragstadthat's what we're doing19:27
ayounglbragstad, they could still make use of the RBAC stuff, just it would take additioanl code19:27
ayounginside Nova19:27
lbragstadwe're going to commit to a whole bunch of work that will no benefit several projects19:27
ayoungNo, you have that backwards19:27
ayoungwe can't do anything about Nova.  Its their code, and they have to chose how to do it19:27
ayoungthis benefits nova, just jnot a specific chunk of the API19:27
ayoungand it benefits everyone else19:28
lbragstadit doesn't benefit anyone who has made that mistake19:28
ayoungand it does not prevent the Nova folks from making use of it, it just requires *additional* work on their part19:28
lbragstadand i believe there are a couple projects that have done that19:28
ayounglbragstad, and that is OK19:28
*** stradling has joined #openstack-keystone19:28
ayoungwe cannot solve everythimng for everyone, but it still has benefit19:28
lbragstadayoung i think you're confusing my objections with needing a proposal that makes everyone happy19:29
lbragstadwhich i'm not proposing19:29
ayounglbragstad, remember ,this is just *in addition* to existing policy, so the existing stuff for nova still takes effect19:29
lbragstadinstead, I want to make sure we take the time and due diligence to *finish* the conversations we started before we start adding APIs to keystone19:30
ayounglbragstad, just trying to give a summary of the discussion with johnthetubaguy .  We basically went over this exact patjh19:30
lbragstadi completely understand the fact that this is additional work, but it's also something we'll have to maintain forever19:30
ayounglbragstad, I was thinking about that.  THere really is no reason it has to be inside Keystone except that we've made it quite painful to add additional services.  I'd even be OK with it being served by the Keystone server, but being a separate service in the catalog19:31
ayoungThe more I see of Kubernetes, the more I hate our service catalog approach19:32
ayounglbragstad, I would absolutely love it if someone could poke holes in the actual approach.  THe problem is that no one has actually taken the time to understand the problem to the degree necessary to do that.19:33
ayoungI've done what I could to lay it out.  It is, I think, the longest spec we've had in Keystone19:34
*** d0ugal has quit IRC19:36
ayounglbragstad, the issue is commands like ^^ which cannot be RBAced at the URL level need to have introspection of the payload.  But that is the exception19:36
lbragstadayoung so what would it take to make it so that could be enforced with what you're proposing?19:37
ayoungIf they really want RBAC at the URL level after that, they could always provide an alternative API like this: /servers/{server_id}/actions/action-name19:37
*** chlong has quit IRC19:37
*** harlowja has quit IRC19:37
ayounglbragstad, well, inside of Nova's handler for the URL, they could look at the method in the payload, and use a hacked version of the URL that happened to match the pattern above19:37
ayoungso if the payload had the action `resume`  pull the policy for  /servers/{server_id}/actions/resume and apply that19:38
lbragstadso why not just have the service maintain the url -> operation mapping and only store the operations in keystone instead of the urls?19:39
ayoungbut prior to that, all the addition of the RBAC in middleware would do would be to enforce a least-common-denominator rule like "in order to execute any action under the url, you need to have at least the Member role"19:39
* knikolla lurks 19:40
ayounglbragstad, because that fails one of the requirements of this proposal:19:40
lbragstadwhich is?19:40
ayoungnamely, to tell a user what roles they need to have in order to perform an operation19:40
ayoungthe operation names are not discoverable19:40
ayoungonly the URLs are discoverable19:40
ayoungand are actually documented fairly standardly19:40
lbragstadthat sounds like a capabilities API19:41
ayounglbragstad, be carfgul throwing that term around.  It means different things to different people19:41
ayoungin computing, a capability is a pre-authorization to perform an actiomn./ I'm not going that far19:41
ayoungnor am I willing to19:41
lbragstadayoung several people i've talked to have a good understanding what that term means19:42
lbragstadspecific in nova and cinder19:42
lbragstadsince both of those projects have either proposed or merged specs for a capabilities API19:42
lbragstadin the openstack sense, i think the term means considering not only the policy for an operation but the state of the deployment19:44
ayounglbragstad, If either the cinder or Nova teams have a generally applicable Capabilites model that we should apply to OpenStack in general, we should get it written up as a Spec.  I somehow suspect that what they have is not generally applicable.19:45
ayoungAnd, so, no, I am not proposing a capabilies API.  I am proposing Scoped RBAC, with discoverability19:46
ayoungI am attempting to solve the long-existent shortcomings of our current model by applying the design decisions we've discussed for several years:19:46
lbragstadayoung  i never said you were opposed to a capabilities API, but what you're proposing sounds like a keystone specific one19:46
ayounglbragstad, nope.  It is not Keystone specific.  It isimlemented in the Middleware layer that is managed by keystone, but it is a general URL based security scheme, pretty common in the Web world,  very similar to the one in Kubernetes for excample19:47
ravelarknikolla can you tell me how/where the test framework runs this method? just so I can understand for future reference?19:47
ayoungravelar, anything in a test_*.py file is treated as a potentiakl test Suite.  The unit test framework does some matching, and if the function name starte with test_ it gets exectued19:49
knikollaravelar: anything starting with test in a file that starts with test19:49
lbragstadayoung you're proposing we have an API in keystone that returns all operations a user can do based on a token19:49
ayounglbragstad, only because we messed up our service catalog, but yes19:50
* ravelar smacks forehead19:50
ayoungideally, you would be able to ask that on reference19:50
ravelarknikolla but the test it self will no longer be needed once we do away with add_event remove_event lists right?19:51
* ayoung applies bacitracin to ravelar 's wounded forehead19:51
lbragstadideally that something that you should be asking the service you're curious about19:51
ravelarayoung lol19:51
*** chlong has joined #openstack-keystone19:51
ayounglbragstad, So, there is no standard way to do that in REST19:51
ayounglbragstad, and asking every service to respond in a consistent manner is...well, just look how successful we've been at that kind of thing in the past19:52
lbragstadat the same time, it makes absolutely no sense for keystone to be responsible for project specific information19:52
knikollaravelar: yes. if you remove the thing which it tests, you can remove the test. but the commit message was wrong saying that the test was unused.19:53
ayounglbragstad, you have two choices.  Do it in keystone. Leave it broken.  I really wish there was an alternative, but when you have a family of related services like we do, delegating security like this  to the remote services does not work.19:53
ayounglbragstad, its not.19:53
openstackgerritMerged openstack/keystone master: Updated from global requirements
ayounglbragstad, a URL is a random string.19:53
ravelarknikolla ah of course, just checking since I planned to remove it but got caught ahead of myself. Thanks!19:53
ayoungKeystone does not care what is in that string.  It just says "that string matches this role"19:53
lbragstadif a user has a role that allows them to live migrate all day long, it still doesn't matter at all if nova isn't deployed with a virt driver that doesn't support live migrate19:54
knikollaravelar: :)19:54
ayounglbragstad, its no different than having many different buildings in a compound call in to the central registry to see if a VIP is on the guest list19:54
lbragstadayoung why should keystone have to care about that mapping for every project when the project has to maintain it already?19:54
ayounglbragstad, strawman19:54
ayoungkeystone cares about nothing except what the Sys admin tells it to care about in these cases19:55
ayoungby default:  make sure the user has a token, like it does now19:55
ayoungallow the sys admin to crank down the security for a specific URL19:55
* ayoung feels like he's had this discussion before.19:56
ayounglbragstad, so, take it from day 1.19:57
ayoungLets assume that the mechanism I've proposed is implemented and deployed as part of an upgrade19:57
ayoungthere are no rules in the Database, config says ignore RBAC-in-middleware...nothing changes from how policy is done today19:58
ayoungthen and admin wants to take advantage of it.19:58
ayoungThey enable it, and the only rule in place is that for all APIs for, say, Nova, the user has to have token wuith the Member rule in it. An admin token is valid everywhere still19:59
ayoungall other services are left alone.  They don't bother even fetching RBAC at middleware19:59
ayoungSys admin rectifies this by enabling it, one by one, for services.19:59
lbragstadyeah - makes sense20:02
lbragstadwhat happens when an admin wants to change the policy of an operation?20:03
lbragstador what's the upgrade case look like when a deployer has this enabled and they upgrade a service that registers new policies in code?20:04
ayounglbragstad, so, if it is an operation they have not touched before, they add a new rule:  PUT /url/thing/20:04
ayoungand add a ROLE20:05
ayoungso, to start, probably make it, Member20:05
*** jamielennox|away is now known as jamielennox20:05
ayoungor, they could create a new Role first,  then add an implied roles rule20:05
ayoungso, say they add "Reader"20:05
ayoungmake "Member" imply  "Reader"20:05
ayoungthen add an explcit rule that says "GET /this/url/thing" requires Reader20:06
ayoungeveryone with member still works the same20:06
ayoungbut now you could create a new user and add the REader role to that person, and they could execute only that URL20:06
lbragstadyeah - that makes sense.. i get that flow20:06
ayoungof course, any other system that did not enforce RBAC would also be accessable to the user20:06
lbragstadmy question was more about what order the admin has to take if they want to change an operation20:07
ayoungwhich is why you would want a default rule defined for each of the service that use tokens before make more speficif API rules20:07
lbragstadwhich would require a change to keystone and a change to a policy file somewhere20:07
ayoungso, no changes to policy files20:08
*** adrian_otto has joined #openstack-keystone20:08
ayoungthe default rule would be in the config for the services auth_token section20:08
lbragstadif I wanted to change the default boot instance policy to something more strict20:08
ayoungthat is wrong20:08
ayoungthe default rule is in keystoone20:08
ayoungthe trigger to lookup the rules is in the auth_token secion20:08
ayounglbragstad, right, you would want to make sure that all existing services that assumed "Member" was the default role made that check explicit first20:09
ayoungthen create a new role "Bootme"20:09
ayoungMember implied Bootme20:09
ayoungthen add the rule for PUT /url/to/boot20:09
ayoungor whatever it is20:09
ayoungas you can see, it won't work by default for the /actions urls because there is not enough to go onm20:10
ayoungif people really wanted, we could do an extension that says "check this in the payload" using jq type syntax or something, in the future20:10
ayoungI don't want to commit to that today, but the potential is there20:10
lbragstadwhat happens when a service releases a new API and registers the default in code?20:12
lbragstadhow is that default propagated into keystone?20:13
lbragstadduring the upgrade?20:13
ayounglbragstad, and now you know why I don't want any defaults in code20:14
ayoungand they can't20:14
ayoungwe make no promises about the set of roles20:14
ayoungthere is admin and that is it20:14
ayoungall they can do is screw the operators on that one...20:14
notmorganand i have long since conceeded the "do everything with any role in any configuration" is not going to work20:15
ayoungnotmorgan, I can't tell if that is a supporting statement or not.20:17
notmorganit is saying I'm certain RBAC is going into "Defaults in Code" in OpenStack20:18
lbragstadseveral projects have already started doing it20:18
notmorganthis is similar to microversions, like it or not.. it's a thing and the direction taken by the community20:19
* notmorgan goes back to the thing he was working on unrelated to rbac things now.20:19
ayoungnotmorgan, lbragstad links?20:21
notmorganNova is well on that path20:21
lbragstadnova implemented defaults in code after austin20:21
ayounglbragstad, for Roles?20:22
notmorganand not sure which other projects are working on it. but i know some have considered it20:22
notmorganayoung: for all policy checks.20:22
ayoungpretty sure they are just checking scope20:22
ayoungI looked at their code20:22
*** lucasxu has quit IRC20:22
ayoungsome admin checks, but they already had that20:22
notmorganit was scope *and* base role stuff iirc20:22
notmorganor intending more in depth role stuff20:22
lbragstadit's the same thing the policy files did, just in code20:22
notmorganthey've move the policy file 100% into code20:23
ayoungnot that I've seen20:23
notmorganwhat lbragstad said20:23
ayoungthey are only checking scope20:23
ayoungpolicy files never checked role, except for Admin20:23
ayoungbase rule ADMIN_OR_OWNDER20:24
ayoungOWNER defined as scope match20:24
ayoungSo...unless you have another example, notmorgan I think we are OK20:28
lbragstadso... the upgrade case?20:28
ayounglbragstad, what about it?  new apis fall; under the default rules20:29
lbragstadso a new api gets rolled out and it fails because the admin hasn't added it to keystone yet?20:30
ayounglbragstad, the default rule catches any API for a service that does not get covered by an\y specific rule20:32
lbragstadoh - but that's not exactly a fix20:32
ayoungin general, assume the default rule will be "all vers" "url" "Role"20:32
lbragstadbecause the default in code could be different than some arbitrary default rule20:32
ayoungAnd the Role will likely be "Member"20:32
ayounglbragstad, if they make it an "admin only" api then it gets enforceb by policy anyway20:33
lbragstadayoung those are two assumption we're actively trying to move away from20:33
ayoungit is no different than how things work today20:33
ayoungthen make the default rule something more stringent20:33
ayoungbut then you need an explicit rule for every other API20:33
ayoungno magic bullet there20:33
lbragstadwhich sounds messy20:33
ayounglbragstad, you can edge case anyhting to make it messy20:34
ayoungbut the default, which is what is supported today, is pretty simple:20:35
lbragstadayoung an upgrade isn't an edge case20:35
ayoungif it is a new API expected to be used by end users, it gets the member role20:35
ayoungif you need it to be admin only, make it admin only20:35
lbragstadsure - that's done by the project when they determine what that default should be in code20:35
lbragstadwhich they own20:35
ayounglbragstad, you want to build *more* on top of my API, be my guest20:35
ayoungthe "Perfect" is the enemy of the "A hell of a lot better than what we have now"20:36
lbragstadayoung i'm certainly not saying your proposal needs to be perfect, like i've already stated several times in this conversation20:36
lbragstadbut upgrades are a thing we should care about20:37
lbragstadand one of the main goals for moving policy into code was to make upgrades easier for operators20:37
ayounglbragstad, of course they are, and I've covered that in the normal case, to the same degree that it is covered today20:37
ayoungwe can, if necessary, do additional work beyond what I've proposed.20:37
lbragstadbut it degrades the upgrade case20:37
lbragstadbecause by default, as things are today, if a new api is added to a service, the default rule for that policy is honored20:38
ayoungI'm not certain how we would support "we have a new API, but we don't want anyone to execute it until we give it an explicit role" without making it an explicit match20:38
lbragstadwhen the service is upgrade20:38
ayoungcould do something in the policy level to support that, I supposed, though20:38
ayounglike, in the scope check, enforce that there has to be some role other than the default role?20:38
knikollacould have some sort of migrations mechanism20:39
ayounganyway, we don't have ANY of those right now.20:39
knikollawhere new apis are defined and you run a script to prepopulate.20:39
ayoungEverything is either member or admin...or a one off like the service roles in Keystone, but those are Keystone specific20:39
ayoungknikolla, yep.20:39
lbragstadknikolla that could work20:40
ayoungknikolla, we can also use the existing documentation generation code to generate the defaults20:40
ayoungor the known set of rules for a given service20:40
ayoungI see all that is a hallmark of success.  If people start asking us for that kind of stuff, then RBAC in Middleware is working20:40
lbragstadso that's a similar experience when an admin wants to supply and override20:40
*** stradling has quit IRC20:43
ayounglbragstad, so, you see where I am headed with this, right?  The goal is to stay out of people's ways unless they want it, but then to provide the right tooling, based on the common patterns20:44
ayoungit is not going to be all things to all people, but it gives a reasonable approach for the most demanded use cases20:45
lbragstadayoung what is the most demanding case?20:45
*** david-lyle has quit IRC20:51
*** david-lyle has joined #openstack-keystone20:51
*** mvk has joined #openstack-keystone20:52
*** harlowja has joined #openstack-keystone20:53
ayounglbragstad, "Read only role"20:54
ayounglbragstad, followed by "roles that can do a subset of what the user needs to do"20:54
lbragstadayoung have you reviewed ?20:55
*** thorst has quit IRC20:59
*** ayoung is now known as ayoung_dadmode21:00
*** thorst has joined #openstack-keystone21:00
ayoung_dadmodelbragstad, not yet, but without a way to implement, we can't add new roles anyway21:00
ayoung_dadmodethat is what shut jamielennox and dolphm down when they proposed21:00
*** d0ugal has joined #openstack-keystone21:00
ayoung_dadmodebut I'll review it shortly21:00
*** rderose has joined #openstack-keystone21:00
*** swatson has joined #openstack-keystone21:02
*** thorst has quit IRC21:04
*** edmondsw has quit IRC21:12
*** edmondsw has joined #openstack-keystone21:14
*** sjain has joined #openstack-keystone21:17
*** edmondsw has quit IRC21:19
*** spilla has quit IRC21:20
*** aojea has quit IRC21:20
*** aojea has joined #openstack-keystone21:20
*** darrenc has quit IRC21:24
*** darrenc has joined #openstack-keystone21:24
*** aojea has quit IRC21:25
*** thorst has joined #openstack-keystone21:26
*** thorst has quit IRC21:30
*** thorst has joined #openstack-keystone21:47
*** lamt has joined #openstack-keystone21:51
*** bjornar_ has quit IRC21:52
*** rderose has quit IRC22:00
*** rcernin has quit IRC22:12
*** rderose has joined #openstack-keystone22:24
*** stradling has joined #openstack-keystone22:25
*** stradling has quit IRC22:27
*** chlong has quit IRC22:38
*** catintheroof has quit IRC22:44
*** edmondsw has joined #openstack-keystone22:45
*** sjain has quit IRC22:47
*** edmondsw has quit IRC22:49
*** lbragstad changes topic to "Pike release schedule: | Meeting agenda: | Bugs that need triaging:"22:51
openstackgerritRichard Avelar proposed openstack/keystone master: Move and refactor project_and_user_and_role
*** lamt has quit IRC23:01
*** adriant has joined #openstack-keystone23:01
*** adrian_otto has quit IRC23:38
*** bjornar_ has joined #openstack-keystone23:56

Generated by 2.14.0 by Marius Gedminas - find it at!