Wednesday, 2017-08-09

morganYou might be able to have exclusive groups within a non exclusive group.00:00
openstackgerritDavanum Srinivas (dims) proposed openstack/oslo.policy master: [WIP] Support for SSL based remote checks
*** ducttape_ has quit IRC00:12
*** dstepanenko has joined #openstack-keystone00:15
*** dstepanenko has quit IRC00:20
*** ducttape_ has joined #openstack-keystone00:22
*** hoonetorg has quit IRC00:23
*** sbezverk has quit IRC00:24
*** ducttape_ has quit IRC00:26
*** thorst has joined #openstack-keystone00:39
*** ducttape_ has joined #openstack-keystone00:42
*** ducttape_ has quit IRC00:42
*** thorst has quit IRC00:44
*** ducttape_ has joined #openstack-keystone00:46
*** Shunli has joined #openstack-keystone00:49
*** thorst has joined #openstack-keystone00:58
*** adriant has quit IRC00:59
*** ducttape_ has quit IRC01:06
*** markvoelker has joined #openstack-keystone01:07
*** zhurong has joined #openstack-keystone01:26
*** gongysh has joined #openstack-keystone01:44
*** ducttape_ has joined #openstack-keystone01:45
*** aselius has quit IRC01:47
*** mjax has quit IRC01:49
*** ducttap__ has joined #openstack-keystone01:51
*** ducttape_ has quit IRC01:55
*** otleimat has quit IRC01:56
*** dstepanenko has joined #openstack-keystone02:03
*** dstepanenko has quit IRC02:08
openstackgerritDavanum Srinivas (dims) proposed openstack/oslo.policy master: [WIP] Support for SSL based remote checks
*** otleimat has joined #openstack-keystone02:11
otleimatmorgan thanks02:11
*** thorst has quit IRC02:16
*** ducttape_ has joined #openstack-keystone02:25
*** ducttap__ has quit IRC02:28
*** markvoelker has quit IRC02:30
*** markvoelker has joined #openstack-keystone02:33
*** zhurong has quit IRC02:44
*** zhurong has joined #openstack-keystone03:01
*** sbezverk has joined #openstack-keystone03:06
*** markvoelker has quit IRC03:07
*** links has joined #openstack-keystone03:15
*** thorst has joined #openstack-keystone03:17
*** sbezverk has quit IRC03:18
*** ducttape_ has quit IRC03:20
*** thorst has quit IRC03:21
*** ducttape_ has joined #openstack-keystone03:27
*** dave-mccowan has quit IRC03:28
*** ducttape_ has quit IRC03:28
*** ducttape_ has joined #openstack-keystone03:34
*** ducttape_ has quit IRC03:36
*** markvoelker_ has joined #openstack-keystone03:49
*** dstepanenko has joined #openstack-keystone03:52
*** markvoelker_ has quit IRC03:54
*** dstepanenko has quit IRC03:56
*** nicolasbock has joined #openstack-keystone03:57
*** gongysh has quit IRC04:03
*** zhurong has quit IRC04:19
*** zhurong has joined #openstack-keystone04:20
*** prashkre has joined #openstack-keystone04:21
*** sbezverk has joined #openstack-keystone04:26
*** mjax has joined #openstack-keystone04:33
*** mjax has quit IRC04:34
*** otleimat has quit IRC04:36
*** ducttape_ has joined #openstack-keystone04:38
*** gongysh has joined #openstack-keystone04:39
*** ducttape_ has quit IRC04:41
*** sbezverk has quit IRC04:46
*** dstepanenko has joined #openstack-keystone04:46
*** dstepanenko has quit IRC04:51
*** rajalokan has joined #openstack-keystone04:59
*** rajalokan has quit IRC04:59
*** rajalokan has joined #openstack-keystone04:59
*** rajalokan has quit IRC05:01
*** prashkre has quit IRC05:02
*** rajalokan has joined #openstack-keystone05:02
*** mvpnitesh has joined #openstack-keystone05:03
*** markvoelker has joined #openstack-keystone05:06
*** gyee has quit IRC05:08
*** thorst has joined #openstack-keystone05:17
*** thorst has quit IRC05:22
*** rajalokan has quit IRC05:23
*** markvoelker has quit IRC05:32
*** markvoelker has joined #openstack-keystone05:32
*** prashkre has joined #openstack-keystone05:34
*** rajalokan has joined #openstack-keystone05:34
*** rajalokan has quit IRC05:37
*** rajalokan has joined #openstack-keystone05:38
*** rajalokan has quit IRC05:41
*** rajalokan has joined #openstack-keystone05:42
*** rajalokan has left #openstack-keystone05:49
*** rcernin has joined #openstack-keystone05:52
*** ducttape_ has joined #openstack-keystone05:53
*** ayoung has quit IRC05:53
*** dstepanenko has joined #openstack-keystone05:54
*** ducttap__ has joined #openstack-keystone05:57
*** tobberydberg has joined #openstack-keystone05:57
*** ducttape_ has quit IRC05:57
*** dstepanenko has quit IRC05:58
*** ducttap__ has quit IRC05:59
*** ducttape_ has joined #openstack-keystone05:59
*** ducttape_ has quit IRC06:03
*** ducttape_ has joined #openstack-keystone06:03
*** ayoung has joined #openstack-keystone06:04
*** hoonetorg has joined #openstack-keystone06:07
*** ducttape_ has quit IRC06:08
*** tesseract has joined #openstack-keystone06:35
*** edmondsw has joined #openstack-keystone06:35
*** edmondsw has quit IRC06:38
*** markvoelker has quit IRC07:03
*** mjax has joined #openstack-keystone07:06
*** markvoelker has joined #openstack-keystone07:06
*** ducttape_ has joined #openstack-keystone07:07
*** mjax has quit IRC07:07
*** ducttap__ has joined #openstack-keystone07:09
*** prashkre_ has joined #openstack-keystone07:09
*** markvoelker has quit IRC07:09
*** ducttape_ has quit IRC07:10
*** ducttap__ has quit IRC07:11
*** prashkre has quit IRC07:11
*** pcaruana has joined #openstack-keystone07:24
*** dstepanenko has joined #openstack-keystone07:37
*** thorst has joined #openstack-keystone07:42
*** thorst has quit IRC07:44
*** dstepanenko has quit IRC08:18
*** dstepanenko has joined #openstack-keystone08:20
*** ioggstream has joined #openstack-keystone08:22
*** aojea has joined #openstack-keystone08:22
*** dstepanenko has quit IRC08:33
*** aojea has quit IRC08:35
*** aojea has joined #openstack-keystone08:35
*** prashkre__ has joined #openstack-keystone08:35
*** prashkre_ has quit IRC08:41
*** zsli_ has joined #openstack-keystone08:44
*** odyssey4me has quit IRC08:47
*** Dinesh_Bhor has quit IRC08:47
*** cburgess has quit IRC08:47
*** tobberydberg has quit IRC08:47
*** dutsmoc has quit IRC08:47
*** asettle has quit IRC08:47
*** cloudnull has quit IRC08:47
*** dims has quit IRC08:47
*** BlackDex has quit IRC08:47
*** jamielennox has quit IRC08:47
*** dgonzalez has quit IRC08:47
*** lamt has quit IRC08:47
*** andymccr has quit IRC08:47
*** NikitaKonovalov has quit IRC08:47
*** peterstac has quit IRC08:47
*** dougshelley66 has quit IRC08:47
*** ppiela has quit IRC08:47
*** masber has quit IRC08:47
*** kaisers2 has quit IRC08:47
*** brad[] has quit IRC08:47
*** timothyb89 has quit IRC08:47
*** EmilienM has quit IRC08:47
*** zigo has quit IRC08:47
*** tesseract has quit IRC08:47
*** rha has quit IRC08:47
*** Dave has quit IRC08:47
*** dulek has quit IRC08:47
*** gongysh has quit IRC08:47
*** mfisch` has quit IRC08:47
*** htruta` has quit IRC08:47
*** rvba has quit IRC08:47
*** tristanC has quit IRC08:47
*** timburke has quit IRC08:47
*** Trident has quit IRC08:47
*** breton has quit IRC08:47
*** frickler has quit IRC08:47
*** freerunner has quit IRC08:47
*** johnthetubaguy has quit IRC08:47
*** bradjones has quit IRC08:47
*** eglute has quit IRC08:47
*** d34dh0r53 has quit IRC08:47
*** jmccrory has quit IRC08:47
*** obre has quit IRC08:47
*** SamYaple has quit IRC08:47
*** kairat has quit IRC08:47
*** akrzos has quit IRC08:47
*** kencjohnston_ has quit IRC08:47
*** aojea has quit IRC08:47
*** ioggstream has quit IRC08:47
*** rcernin has quit IRC08:47
*** links has quit IRC08:47
*** nkinder has quit IRC08:47
*** jaosorior has quit IRC08:47
*** bigjools has quit IRC08:47
*** jdennis has quit IRC08:47
*** baffle has quit IRC08:47
*** med_ has quit IRC08:47
*** alex_xu has quit IRC08:47
*** Tahvok has quit IRC08:47
*** matteus has quit IRC08:47
*** vaishali has quit IRC08:47
*** basilAB has quit IRC08:47
*** pcaruana has quit IRC08:47
*** junbo has quit IRC08:47
*** d0ugal has quit IRC08:47
*** oomichi has quit IRC08:47
*** robcresswell has quit IRC08:47
*** samueldmq has quit IRC08:47
*** hrybacki has quit IRC08:47
*** mgagne has quit IRC08:47
*** rarora has quit IRC08:47
*** gus has quit IRC08:47
*** fungi has quit IRC08:47
*** dstanek has quit IRC08:47
*** wolsen has quit IRC08:47
*** portdirect has quit IRC08:47
*** chris_hultin|AWA has quit IRC08:47
*** ayoung has quit IRC08:47
*** rodrigods has quit IRC08:47
*** Nakato has quit IRC08:47
*** efried has quit IRC08:47
*** zeus has quit IRC08:47
*** clarkb has quit IRC08:47
*** andreaf has quit IRC08:47
*** knikolla has quit IRC08:47
*** rm_work has quit IRC08:47
*** evrardjp has quit IRC08:47
*** mrhillsman has quit IRC08:47
*** jhesketh has quit IRC08:47
*** prashkre__ has quit IRC08:47
*** spotz has quit IRC08:47
*** gagehugo has quit IRC08:47
*** amrith has quit IRC08:47
*** jlvillal has quit IRC08:47
*** kevinbenton has quit IRC08:47
*** admcleod has quit IRC08:47
*** chrome0 has quit IRC08:47
*** Daviey has quit IRC08:47
*** dansmith has quit IRC08:47
*** jamiec has quit IRC08:47
*** Krenair has quit IRC08:47
*** hugokuo has quit IRC08:47
*** mvpnitesh has quit IRC08:47
*** jmlowe has quit IRC08:47
*** kornicameister has quit IRC08:47
*** stevemar has quit IRC08:47
*** wasmum has quit IRC08:47
*** dtroyer has quit IRC08:47
*** hyakuhei has quit IRC08:47
*** mordred has quit IRC08:47
*** afazekas has quit IRC08:47
*** flwang has quit IRC08:47
*** ebbex has quit IRC08:47
*** hemna has quit IRC08:47
*** morgan has quit IRC08:47
*** john5223 has quit IRC08:47
*** zsli_ has quit IRC08:47
*** zhurong has quit IRC08:47
*** nicolasbock has quit IRC08:47
*** Shunli has quit IRC08:47
*** clayton has quit IRC08:47
*** david-lyle has quit IRC08:47
*** lifeless has quit IRC08:47
*** jistr has quit IRC08:47
*** openstackgerrit has quit IRC08:47
*** aloga has quit IRC08:47
*** mtreinish has quit IRC08:47
*** lbragstad has quit IRC08:47
*** flaper87 has quit IRC08:47
*** jidar has quit IRC08:47
*** charz has quit IRC08:47
*** szaher has quit IRC08:47
*** slunkad has quit IRC08:47
*** timss has quit IRC08:47
*** andreykurilin has quit IRC08:47
*** ChanServ has quit IRC08:47
*** Adri2000 has quit IRC08:47
*** Adobeman has quit IRC08:47
*** diablo_rojo_phon has quit IRC08:47
*** mancdaz has quit IRC08:47
*** cmurphy has quit IRC08:47
*** toddnni has quit IRC08:47
*** melwitt has quit IRC08:47
*** openstack has joined #openstack-keystone13:52
*** openstack has joined #openstack-keystone13:53
*** tobberydberg has joined #openstack-keystone13:54
*** tobberydberg has quit IRC13:59
lbragstadknikolla: o/14:00
lbragstadcmurphy: so - apparently hints does does independently of the driver or backend implementation14:00
lbragstadugh.. does stuff*14:01
cmurphylbragstad: stuff that conflicts with caching?14:02
lbragstadcmurphy: i don't think so?14:02
lbragstadstill unwinding it14:02
cmurphythat sounds fun14:02
lbragstadso the controller builds the hints object from filters and the request14:02
lbragstadthen is attempts to pass it to the manager so that it can pass it through to the backend - in case it supports using a hints object14:03
lbragstadwhich makes sense14:03
lbragstadbut then you have this -
lbragstadwhich is called on the way out of the controller method14:04
*** Adri2000 has joined #openstack-keystone14:05
*** tobberydberg has joined #openstack-keystone14:06
*** ducttape_ has joined #openstack-keystone14:09
cmurphylbragstad: in this specific case though the manager didn't need it and so it was unaltered by the time it got back to the controller14:10
*** tobberydberg has quit IRC14:11
lbragstadcmurphy: yep - which means we should be able to remove the hints object from being passed to the manager14:11
lbragstadcache the response from the manager14:11
lbragstadbut let the hints logic still run in the controller parts14:11
openstackgerritLance Bragstad proposed openstack/keystone master: Remove unused hints from assignment APIs
openstackgerritMerged openstack/keystone master: Consolidate certificate docs to admin-guide
knikollacmurphy: have any experience setting up shibboleth-sp with multiple identity providers?14:15
TahvokI was under impression that having a global admin, would grant me access to all domains and projects. Is it not the case? Because not only I cannot see any projects, I also can't change between the domains in horizon14:21
lbragstadTahvok: global admin should allow you to do anything within the deployment, unless the policies protecting the services have changed in your deployment14:23
*** kukacz has quit IRC14:26
cmurphyknikolla: not particularly no14:27
*** ioggstream has quit IRC14:27
cmurphyknikolla: are weird things happening?14:27
*** ioggstream has joined #openstack-keystone14:27
*** sjain has joined #openstack-keystone14:27
knikollacmurphy: nah, i'm just having issues making the devstack plugin work with both testshib and k2k at the same time as i have no prior experience with that specific setup.14:27
knikollaguess i delayed enough reading through the shibboleth documentation.14:31
cmurphyknikolla: ha :)14:32
*** zhurong has quit IRC14:32
lbragstadgagehugo: looks pretty good - just a couple suggestions inline14:33
gagehugolbragstad cool14:43
openstackgerritLance Bragstad proposed openstack/keystone master: Cache list projects and domains for user
lbragstadcmurphy: samueldmq that passes for me locally ^14:44
openstackgerritLance Bragstad proposed openstack/keystone master: Cache list projects and domains for user
*** sjain has quit IRC14:48
openstackgerritSami Makki proposed openstack/oslo.policy master: Add JSON output option to sample generator
openstackgerritSami Makki proposed openstack/oslo.policy master: Add JSON output option to sample generator
openstackgerritLance Bragstad proposed openstack/keystone master: Reduce revoke events for disabled domains and projects
*** otleimat has joined #openstack-keystone15:05
*** dstepanenko has quit IRC15:07
*** dstepanenko has joined #openstack-keystone15:07
*** dstepanenko has quit IRC15:10
*** dstepanenko has joined #openstack-keystone15:10
*** tesseract has quit IRC15:14
*** lucasxu has quit IRC15:14
*** links has quit IRC15:16
*** prashkre__ has joined #openstack-keystone15:25
*** prashkre_ has quit IRC15:25
*** markvoelker has quit IRC15:28
*** dstepanenko has quit IRC15:29
*** dstepanenko has joined #openstack-keystone15:29
*** aselius has joined #openstack-keystone15:29
openstackgerritLance Bragstad proposed openstack/keystone master: Ensure domains and projects are validated online
*** dstepanenko has quit IRC15:33
Tahvoklbragstad: I didn't touch the policies, but checked them anyway to make sure...15:37
TahvokThe user in the second domain is an ldap user - maybe that's the problem?15:37
lbragstadTahvok: possibly15:37
TahvokAlso, I'm assigning the group, not a specific user15:38
*** markvoelker has joined #openstack-keystone15:39
*** dstepanenko has joined #openstack-keystone15:40
*** markvoelker has quit IRC15:56
*** lucasxu has joined #openstack-keystone15:57
*** dstepanenko has quit IRC15:58
*** lucasxu has quit IRC16:03
*** markvoelker has joined #openstack-keystone16:03
openstackgerritGage Hugo proposed openstack/keystone master: Add description for relationship links in api-ref
gagehugolbragstad ^ if those links on all of the relationships are too much, then we can just remove them and have the main section if that works16:20
*** markvoelker has quit IRC16:23
otleimatFor purging mappings, what are the allowed permutations from 'public-id, domain-name, local-id, and type'?16:25
lbragstadhenrynash would be the person to ask for that16:29
otleimatThanks, ill reach out to him16:30
lbragstadotleimat: he pops into the channel from time to time16:31
*** jmlowe has quit IRC16:31
otleimatlbragstad: any other way I can contact him?16:32
*** markvoelker has joined #openstack-keystone16:32
*** kornicameister has quit IRC16:40
*** rcernin has quit IRC16:41
openstackgerritLance Bragstad proposed openstack/keystone master: Ensure domains and projects are validated online
*** kornicameister has joined #openstack-keystone16:45
*** dstepanenko has joined #openstack-keystone16:45
*** tobberydberg has joined #openstack-keystone16:46
lbragstadotleimat: you could start a thread on the ML tagged with [keystone]?16:46
*** markvoelker has quit IRC16:46
lbragstadotleimat: that might help generated a discussion and he usually watches the mailing list16:46
lbragstadgagehugo: yeah - i'd be fine with a single blanket statement for now16:49
*** dstepanenko has quit IRC16:50
*** sbezverk has joined #openstack-keystone16:52
lbragstadstepping away for lunch quick16:53
*** dstepanenko has joined #openstack-keystone16:54
*** markvoelker has joined #openstack-keystone16:55
*** tobberydberg has quit IRC16:55
*** mjax has joined #openstack-keystone17:03
*** dstepanenko has quit IRC17:05
*** david-lyle has quit IRC17:08
*** david-lyle has joined #openstack-keystone17:08
*** sjain has joined #openstack-keystone17:12
*** sjain_ has joined #openstack-keystone17:14
*** sjain has quit IRC17:16
bretonjust had in interesting conversation with security folks who were unhappy with fernet tokens being symmetrically encrypted (and not rotated)17:25
*** mjax has quit IRC17:25
*** sjain_ has quit IRC17:25
bretonone of their arguments was that yahoo had similar symmetric crypto and russian hackers could craft cookies externally, after obtaining the keys: (page 9)17:26
gagehugolbragstad ack17:31
*** markvoelker has quit IRC17:31
openstackgerritGage Hugo proposed openstack/keystone master: Add description for relationship links in api-ref
*** ducttap__ has joined #openstack-keystone17:34
*** jmlowe has joined #openstack-keystone17:35
*** jmlowe has quit IRC17:35
*** jmlowe has joined #openstack-keystone17:35
*** jmlowe has quit IRC17:36
*** ducttape_ has quit IRC17:37
*** jmlowe has joined #openstack-keystone17:38
*** dstepanenko has joined #openstack-keystone17:41
*** rcernin has joined #openstack-keystone17:42
*** kornicameister has quit IRC17:43
ayoung   breton lbragstad cmurphy can we kick this one into the approved queue?17:44
*** kornicameister has joined #openstack-keystone17:46
*** dstepanenko has quit IRC17:46
*** tobberydberg has joined #openstack-keystone17:47
*** tobberydberg has quit IRC17:51
lbragstadbreton: the whole point of fernet is to rotate your keys17:54
*** gyee has joined #openstack-keystone17:54
*** kbaegis has joined #openstack-keystone17:57
lbragstadbreton: wouldn't the same situation be possible if asymmetric encryption was used?18:00
*** lucasxu has joined #openstack-keystone18:00
*** kbaegis has quit IRC18:06
*** tobberydberg has joined #openstack-keystone18:06
*** kbaegis has joined #openstack-keystone18:07
*** ducttape_ has joined #openstack-keystone18:07
*** tobberydberg has quit IRC18:10
*** ducttap__ has quit IRC18:10
*** jrist has quit IRC18:11
morganbreton: fernet keys are supposed to be rotated18:14
morganit just is an operational concern on when to do it18:14
morgannot automated in keystone18:15
morganlbragstad: yes, if the keys are derived, but they are harder to derive without having control on significant input data sets (not impossible)18:15
openstackgerritLance Bragstad proposed openstack/keystone master: Make fetching all foreign keys in a join
lbragstadmorgan: so it asymmetric encryption would lead to the same concern?18:18
morganit depends on the ciphers used18:18
morganand the bits.18:19
morganalso asym is way way more CPU intensive and produces way more data18:19
lbragstadgagehugo: any update on this?
morganbasically the complaint with symmetric encryption in this case is it is symmentric AND not rotated18:19
morganit means someone wasn't reading any deployment docs18:19
morganor it wasn't communicated that rotation of keys was an expectation18:20
openstackgerritSamriddhi proposed openstack/keystone master: Updated URLs in docs
morgani could see that be an Info level message18:20
morganlbragstad, gagehugo ^18:20
gagehugolbragstad I have no idea, but I won't block it if we are wanting to make the change18:21
* morgan shrugs18:21
gagehugoI couldn't find any guidelines18:21
*** kbaegis1 has joined #openstack-keystone18:21
morganthere are guidelines somewhere.18:21
ayoungmorgan, please kick this one one18:23
ayoungits Jose...pretty much the major Kerberos user out there18:23
morganayoung: sec, reading it18:24
morganjust have ot make sure we aren't breaking current behavior18:24
morganotherwise i have zero issue with the change.18:24
morgan(aka default)18:24
ayoungoptional mutual authentication.  No change unless opt in18:24
*** kbaegis has quit IRC18:24
morganthat was what i was checking18:27
morganit looks good.18:28
morganthe thing is ksa has such a strict interface contract we have to be super careful.18:28
morganwe can't break it *ever* (short of a ksa2 package)18:28
morganwe don't want to break all of openstack :P18:28
ayoung*you* don't want to break all of openstack.  "Some people just want to see the world burn."18:29
openstackgerritKristi Nikolla proposed openstack/keystone master: WIP - Added keystone identity provider installation to Devstack plugin
*** markvoelker has joined #openstack-keystone18:32
morganayoung: no... we don't18:33
*** nicolasbock has quit IRC18:33
morganbecause if this breaks openstack,your name is on it too for +2 :P18:33
*** ducttape_ has quit IRC18:34
*** nicolasbock has joined #openstack-keystone18:34
ayoungdims, you still looking to talk Keystone/Kubernetes?18:44
*** morgan is now known as kmalloc18:46
dimsayoung : wrote a proof-of-concept webhook implementation for both authentication and authorization if you wanna take a peek -
ayoungdims, saw that. what are you trying to do?18:46
kmallocdims: yeah i was planning on taking a peak at that18:47
kmallocdims: shortly18:47
dimsfirst thing is to allow someone to specify a keystone token when using kubectl to access api server etc18:47
ayoungdims, please no18:47
ayoungno no no no no no no no no no no18:48
ayoungunh uh18:48
ayoungdear god make it stop18:48
kmallocin theory it should be able to OAuth instead of doing a keystone token18:48
ayoungjust send the userid and password to Kubernetes and make it work like god intended.  Sportsman like18:48
dimskmalloc : y that's already there18:48
ayoungdims why?18:49
kmallocso, keystone should support that -- and be a IDP then.18:49
*** ioggstream has quit IRC18:49
kmallockeystone tokens are bad news to proliferate... unless it REALLY has a good reason to18:49
*** ayoung is now known as kfree18:49
*** ioggstream has joined #openstack-keystone18:49
kmallocwhich, i am not sure what is the goal here.18:49
kfreeSo, 1 Keystone should not be an IdP18:49
kmallockfree: i want to name my next pet "malloc" so we can "free" him :P18:49
*** nicolasbock has quit IRC18:50
*** tobberydberg has joined #openstack-keystone18:50
kmalloc*if* you are using keystone as a source of identity... then it should be done via standard protocols (ideally)18:50
dimskfree : kmalloc : see, there's a client side auth provider that can key off any of the OS_ env variables, send that to keystone to get a token and then send that as bearer token to api server18:50
kmallocmy statement is predicated on the need to do so.18:50
kfreedims, just send that data direct to Kubernetes18:50
kfreeand hack kubernetes to understand the Keystone database format at the SQL level if you really must18:51
kmallocso, the goal is to have a single source of identity for IaaS for a deployment?18:51
kfreeanything but propegating the mistake that is Bearer tokens18:51
* kmalloc is looking for the reasoning for this before we dive too deep18:51
dimskfree : you should talk to jordan liggitt and eric chang in sig-auth18:51
*** kfree is now known as ayoung18:51
kmallocknowing the use-cases vs a "hey I want something lets do something"18:51
ayoungI want Keystone to die and us to do things the Kubernetes way on auth18:52
dimskmalloc : i know the use case i want18:52
ayoungthey front everything with a single API server18:52
ayoungand thus auth is centralized18:52
ayoungthe bearer token thing is a blight on the land18:52
dimskmalloc : which is to setup my OS_* variables and just use kubectl18:52
kmallocdims: ooh18:53
kmallocayoung: so... k8s is doing it right? ;)18:53
ayoungkmalloc, more right than Keystone is, and OpenStack, yes18:53
kmallocayoung: you know... i proposed much of this at one point with a nice migration for openstack18:53
ayoungkmalloc, if you are going to do distributed auth, you need cryptographic security, and that way leads to SAML, or PKI, or something that is "too hard"18:54
kmallocthough i think i could still make it all work w/ some massaging code for haproxy (have mostly working lua still)18:54
*** tobberydberg has quit IRC18:54
kmallocayoung: i agree.18:54
kmallocand have for a loooooong time18:54
ayoungso dims...tell them that the very thought about what you were proposing makes the Keystone team cry18:54
dimsayoung, it's a proof of concept in my own github, so it's not official by any means18:55
kmallocayoung: i'm collecting info before things go too far18:55
kmallocayoung: i 100% agree that if we can avoid replicating keystone's ick, it is a good thing18:56
*** ducttape_ has joined #openstack-keystone18:56
ayoungdims just think if you want your name associated with it18:56
dimsayoung : let's see what you come up with :)18:56
dimsayoung : it already is :)18:57
ayoungdims, why do you think that this would be a good idea?19:01
kmallocayoung: it feels like the same reason someone wants a PaaS with the same auth as IaaS19:01
kmallocso they can use the same settings for running where they want19:02
ayoungkmalloc, but they can.  They just don;'t need to get a token first19:02
ayoungKubernetes does not work that way19:02
kmalloc(it is... more "amazon"-ish where iaas and non-iaas and iaas-like-but-different all uses the same auth things)19:02
kmalloci'm not arguing for/against it, just what i'm seeing the convos/what is being asked for19:02
*** markvoelker has quit IRC19:06
*** markvoelker has joined #openstack-keystone19:08
dimsayoung : happy to be proven wrong and happier if you can show a better way19:08
dimsayoung : i am leaving notes on the sig-auth slack channel on what i know about how things work19:09
*** kbaegis1 has quit IRC19:16
*** kbaegis has joined #openstack-keystone19:16
*** ioggstream has quit IRC19:19
*** ioggstream has joined #openstack-keystone19:19
dimsayoung : invited you to the sig-auth channel there19:21
*** ducttap__ has joined #openstack-keystone19:26
*** ducttape_ has quit IRC19:28
*** sbezverk has quit IRC19:29
*** dstepanenko has joined #openstack-keystone19:30
bretonmorgan: lbragstad: the whole point of yahoo's system was to rorate keys. They didn't do it.19:30
bretonmorgan: lbragstad: it is hard to securely rotate keys across multiple nodes and this problem is not solved19:31
*** ioggstream has quit IRC19:33
*** ducttape_ has joined #openstack-keystone19:34
*** dstepanenko has quit IRC19:34
*** tobberydberg has joined #openstack-keystone19:36
*** ducttap__ has quit IRC19:37
bretonmorgan: lbragstad: tripleo added rotation yesterday-ish only19:37
lbragstadopenstack-ansible has has support for that since we implemented fernet19:38
lbragstadlibrary or kilo they had auto rotation19:38
*** tobberydberg has quit IRC19:40
bretonwhat i think we should do is force operators to rotate their keys. With `max_fernet_key_days=90` option, for example.19:41
kmallocwhat happens if they dont?19:41
kmallockeystone stops working?>19:41
kmallocthat is counter to most everything that works like that19:42
kmallocby default, apache doesn't stop working if your cert is out-dated or self-signed19:42
kmallocclients may balk19:43
*** rmcall has joined #openstack-keystone19:43
bretonmost sensible clients will stop working19:43
kmallocbut it isn't the server that stops working19:43
bretonmy browser will, `requests` will, curl will19:43
kmallockeystone is the server19:43
bretonyes. But we cannot control things from the client side. But maybe we should be able to.19:43
bretonmax_fernet_key_days might be too harsh, i agree.19:44
kmallocso, no the server shouldn't stop working19:44
*** rajalokan has joined #openstack-keystone19:44
kmalloci'd be open to some other mechanism to encourage rotation19:44
kmallocbut we can't just "stop" working.19:44
*** tobberydberg has joined #openstack-keystone19:44
bretonok. What mechanism, for example?19:44
kmallocwe could offer data in the token so the clients could handle it.19:45
kmallocit's about all we can do.19:46
kmallocwe could also work to dump bearer tokens in totality (again) and use client certs for service->keystone communication. but the "edge-only" authentication (similar to the single api, such as kube-api) is a tough sell in openstack19:47
bretonclient certs for service->keystone communication was implemeted by gyee19:48
breton(hi gyee)19:48
kmallocmove towards that as the recommended/reference/default deployment model19:49
samueldmqgagehugo: you on bug 1674676 ?19:49
openstackbug 1674676 in OpenStack Identity (keystone) "The URL listed against the details of identity resources returns 404 Not Found error" [Medium,In progress] - Assigned to Gage Hugo (gagehugo)19:49
*** kfox1111 has joined #openstack-keystone19:49
kmallockfox1111: hey there19:49
kmallockfox1111: so, how does tenancy from openstack impact your k8s deployment19:50
kmallocis it just for access control for X tenant into the k8s deploy?19:50
*** rajalokan has quit IRC19:50
* kmalloc is having lag in the slack window, so typing here is a little easier as well.19:50
bretonhow does a user authenticate for this new system? What does they get in return to username/password?19:50
kfox1111kidn of undefined at the moment.19:51
*** tobberydberg has quit IRC19:51
kfox1111we have an openstack cloud we are providing to our organization.19:51
kfox1111kind of a public cloud, just for the org.19:51
kfox1111I see two use cases for k8s.19:51
kmallocbreton: use an OAuth, Basic-Auth, etc type thing. so not bearer tokens. I had an implementation for it at one point.19:51
kmallockfox1111: cool, this info helps me understand what the goals are19:51
kfox1111one is letting the users launch their own inside the cloud.19:52
kfox1111having it be easy to bind to the cloud and restrict access to their own project means they don't have to deal with auth themselves.19:52
kfox1111so, single tenant k8s in that case.19:52
kmallocor re-impl an auth thing.19:52
kfox1111the second is, there are some use cases where they dont even need to stand up their own k8s. we could provide a k8s for everyone.19:52
kfox1111thats the more interestign one to me.19:53
kmalloclike hypercontainer things?19:53
kmalloc[as an example]19:53
kfox1111yeah, perhaps.19:53
bretonkmalloc: oauth for authentication? Eh. Basic auth is bad.19:53
kfox1111or we set rbac rules that are restrictivve enough that we call it good enough.19:53
kmallocbreton: you support many forms of auth, basic-auth may be one to support, not recommended.19:53
kmallockfox1111: hm. tenancy is weird in that last case.19:53
kmallocbut sure.19:53
kfox1111we already have keystone as our source of truth for tenancy.19:54
kfox1111we wouldn't want to have a second system to keep in sync with it.19:54
dimskmalloc : kfox1111 : any new implementation server-side cannot live in k8s main repo19:54
kmalloci just meant a "single large k8s"19:54
dimsso we are limited to what we can do with webhooks19:54
kmallocdims: wasn't thinking of that19:54
kfox1111dims: yeah. thats the problem i was facing.19:54
kfox1111sounds like they are a little more capable now though then it was before.19:54
kmallochypercontainer is a wrapper for pods/multi-tenancy to k8s deploy19:54
kmallocso i was looking to it as a kind of "working thought"19:55
kfox1111there is 'hyper' too, which is just a different pod driver.19:55
kmallocnot a "k8s main repo auth thing"19:55
kmallockfox1111: yeah.19:55
kfox1111the pod gets run in a vm, and all the containers in the pod are in it.19:55
kmallocand it already uses keystone.19:55
kfox1111so security is not so much a problem there.19:55
kmallocbut. that aside19:55
dimsstackube does that19:55
kfox1111its really just getting tenancy info from keystone and mapping it to namespaces somehow.19:55
kmalloci don't see how a large k8s deploy can leverage tenancy at all from keystone19:55
kmallocshort of pods in vm19:56
kfox1111I think  k8s really needs the notion of tenancy.19:56
kfox1111there are two ways of solving it.19:56
kfox11111 would make a namespace a tenant.19:56
kmallocwell that is a totally different arguemnt ;) and i am not in a position to accept/reject it19:56
kfox1111the k8s guys favor that. I really dislike it the more I think about it.19:56
kmalloci don't think that is *really* a good security model19:57
kfox1111the other is having tenant be a first class citizen and multiple namespaces get assigned to a tenant.19:57
kfox1111I think that one is a much better model.19:57
kmallocit's a light security model (namespaces) for logical separation19:57
kmallocit can't be leaned on to be actual tenancy isolation19:57
kfox1111one problem with namespace is it is exposed out via kubedns.19:57
kfox1111so it can't map very well to openstack's tenants.19:58
kmallocso, for the latter case it sounds like a wrapper is needed for k8s, and we're back to "deploy k8s for someone" or "let them deploy in a VM themselves"19:58
kfox1111unless you want your namespace to contain -2b246be8-98a6-41fa-afe1-c5e1de2950e1.cluster.local. :/19:58
kmalloclets set aside native tenancy/namespace in k8s mapped from openstack19:58
samueldmqlbragstad: you around? re:
kmallocthat seems like a weird case to consider in this model19:58
kmalloclets look at "single tenant" and "tenancy provided by openstack, k8s living in vms"19:59
dimskfox1111 : have you seen what's in stackube?19:59
kmallocwhich sounds like stackube's thing19:59
kfox1111dims: a while ago. not recently.19:59
kmallocand hyper19:59
kfox1111hyper provides isolation around containers.19:59
dimskfox1111 : they have re-written a whole lot19:59
kfox1111not mgmt of the rbac like thingies.19:59
openstackgerritMerged openstack/keystoneauth master: Parameter to tune mutual authentication in kerberos
dimskfox1111 : they do management of rbac like thingies too
kfox1111dims: this code looks weird. is it using k8s as the source of truth rather hten keystone?20:00
kfox1111"err = c.openstackClient.DeleteTenant(tenantName)"20:01
kfox1111or its using something else entirely and driving both k8s and openstack maybe.20:01
dimsthey have a CRD and they key off of that20:01
*** rajalokan has joined #openstack-keystone20:02
kfox1111I think they are doing something themselves and not using either as the source of truth.20:02
*** raildo has quit IRC20:03
kfox1111I guess you could do something like that though... make a Tenant first class citicen as a 3rd party resource,20:04
*** sbezverk has joined #openstack-keystone20:04
kfox1111and the web hook could populate it when first login to k8s happens with a token.20:04
kfox1111and keep the tenant-> namespace mapping inside.20:05
dimsfor example when the namespace is added they generate a bunch of rbac stuff for that namespace -
kfox1111k. I'm going to do a bit of reading on this. it does look very interesting. thanks for the link. :)20:07
lbragstadsamueldmq: sure - what's up?20:07
dimskfox1111 : yw20:07
samueldmqlbragstad: I don't think list_projects_for_user returns only enabled projects20:07
lbragstadsamueldmq: it doesnt'20:08
samueldmqlbragstad: the controller even has a filter that allows you to filter on enabled
lbragstadsamueldmq: yep20:08
samueldmqlbragstad: so why do you need to invalidate the cache when a project is disabled?20:08
lbragstadah - good point, didn't put that together when i read your comment20:09
lbragstadlet me pull down the change and try to recreate it20:09
samueldmqlbragstad: I saw your reply to my comment but I don't understand why it's really needed20:10
lbragstadsamueldmq: i did see a failure becuase of it in a previous patch set20:10
lbragstadlet me see if i can recreate20:10
samueldmqlbragstad: sure. I'm running the tests locally right now too (without that bit)20:10
kmallockfox1111: cool. yeah i don't wnat to implement things from scratch if we don't have to20:11
kmallocbut happy to consider things that make life better20:11
kmallocdims: ^ cc20:11
kmallocsamueldmq: you need to invalidate the cache because we use project enabled as a way of authz20:12
dimskmalloc : for sure. our options are limited as mentioned earlier20:12
kmallocsamueldmq: if you don't invalidate the cache, the project may still be "enabled" for some requests and things leak through, even with new auth20:12
kmallocso, change of project state (or values) explicitly needs a cache invalidation20:12
kmallocany update of data actually *should* invalidate the cache20:13
*** raildo has joined #openstack-keystone20:13
samueldmqkmalloc: well, but that is for the role assignment cache20:13
kfox1111kmalloc: definitely.20:13
samueldmqand the role assignments don't change when a project is disabled, they still exist and can be queried20:13
kmallocdoes the default include disabled projects?20:14
kmallocor do you need to explicitly do a filter?20:14
kfox1111not seeing if tehy are using keystone as a source of truth here, or if tehy are using it as a sync to ensure neutron/cinder/etc have a place to read data from.20:14
samueldmqkmalloc: you need a filter. there is one at the controller level
kmalloci mean... if i disable the project, does it's roles appear still in that API call?20:14
kmallocor when you add the filter it returns it all/filtered20:14
kfox1111but I can see how this can be addapted to fit in a, add stackube to your existing openstack rather then here's a whole standalone k8s using openstack bits.20:15
lbragstadsamueldmq: cmurphy breton we need to get gating today, too20:15
samueldmqkmalloc: yes, it still returns the role assingment in the disabled project. I don't see anywhere it filtering only the enabled projects by default20:15
kmallocsamueldmq: then we can avoid a cache pop. It seems odd that that api does that for disabled projects but... i'm not going to argue current behavior, we do weired thing20:17
*** ducttape_ has quit IRC20:17
openstackgerritOctave Orgeron proposed openstack/keystone master: Enables MySQL Cluster support for Keystone
samueldmqkmalloc: lbragstad: aha ... the point is that list_projects_for_user returns "self.resource_api.list_projects_from_ids(project_ids)"20:19
samueldmqeven if project_ids didn't change (the response from list_role_assignments will still be the same)20:19
samueldmqbut the project dict will change with {'enabled': False}....20:19
kmallocthat was what i was thinking20:19
kmallocwhich means we need to invalidate the cache20:20
samueldmqkmalloc: that's right, and maybe unfortunate since MEMOIZE_COMPUTED_ASSIGNMENTS is for role assignments20:20
samueldmqand those didnt change in reality20:20
samueldmqbut I guess we don't want to end up creating thousands of cache regions20:21
kmallocwe could dynamically create cache regions but it would get ugly fast.20:21
kmallocit is likely way better to take a cache invalidation on project disable (hopefully that doesn't happen a ton)20:21
samueldmqI agree20:22
kmallocbut even if it does, we still get some acceleration via caches.20:22
kmallocjamielennox: you alive?20:22
samueldmqlbragstad: approved. one bug less20:24
samueldmqkmalloc: thanks for helping on understanding that20:24
samueldmqkmalloc: nice new nick btw20:24
*** links has joined #openstack-keystone20:25
samueldmqkmalloc: fortunately you populate the real name field20:25
lbragstadkmalloc: i was wondering who you were20:25
samueldmqkmalloc: I mean, I also know it's you with those cache discussions ....20:25
kmallocsamueldmq: yes I make an effort to keep real name populated20:25
gagehugosamueldmq yes20:25
*** tobberydberg has joined #openstack-keystone20:26
kmallocsamueldmq: heh, it's not hard to guess based upoon context i guess.20:26
samueldmqgagehugo: cool, how are you planning to address that?20:26
gagehugowith a description of what the relationship links are20:26
lbragstaddoc fix20:26
openstackgerritGage Hugo proposed openstack/keystone master: Add description for relationship links in api-ref
*** sbezverk has quit IRC20:29
*** tobberydberg has quit IRC20:30
samueldmqgagehugo: see my comments in PS3, I was writing them when you submitted as new one20:33
gagehugoyeah I forgot to remove the part about the links in the commit message20:33
*** markvoelker has quit IRC20:35
openstackgerritGage Hugo proposed openstack/keystone master: Add description for relationship links in api-ref
gagehugosamueldmq let me know if that looks better20:41
*** markvoelker has joined #openstack-keystone20:41
openstackgerritGage Hugo proposed openstack/keystone master: Add description for relationship links in api-ref
*** jmlowe has quit IRC20:46
*** tobberydberg has joined #openstack-keystone20:48
samueldmqgagehugo: is that valid for any keystone api return?20:49
samueldmqI haven't seen relationships links in the returns we make20:49
samueldmqif not, we can just omit it. cc lbragstad20:50
lbragstadi think it's just an example of how it would work in an ideal scenario20:51
samueldmqmaybe that's we wanna do in the future, so that discovery is nice. but if we dont do today, let's not advertise what we dont do20:51
*** markvoelker has quit IRC20:52
*** tobberydberg has quit IRC20:53
gagehugosamueldmq yeah it's just an example of how it would work in that scenario20:55
gagehugoidc, we can omit it if it's too confusing20:55
samueldmqI'm fine either way, but let's expect people complaining about it20:55
samueldmqas someone reading the docs, I'd try that. and expect keystone to return relationships links20:55
samueldmqbut I am fine. why not work to put that in the responses if that's what we want?20:56
*** ducttape_ has joined #openstack-keystone20:56
samueldmqmaybe we can talk abotu this in the ptg too, lbragstad ?20:56
*** ducttape_ has quit IRC20:56
*** links has quit IRC20:56
gagehugoI wonder why we have them in the first place20:56
samueldmqgagehugo: the goal is to have APIs that are easy to be discovered iirc20:57
samueldmqbut we added those in docs, and dont use in reality20:57
samueldmqI'm fine with that doc as it is, with the example. at least we clarify what they'r for20:58
*** markvoelker has joined #openstack-keystone20:59
*** ducttape_ has joined #openstack-keystone20:59
openstackgerritGage Hugo proposed openstack/keystone master: Add description for relationship links in api-ref
gagehugowe can just remove the example for now21:00
gagehugosimpler that way21:00
*** lucasxu has quit IRC21:01
lbragstadthe idea is that the response from the service contains all the stuff for the client to make the next call21:01
*** prashkre__ has quit IRC21:04
openstackgerritLance Bragstad proposed openstack/keystone master: Unset project ids for all identity backends
*** ducttape_ has quit IRC21:06
*** tobberydberg has joined #openstack-keystone21:07
*** catintheroof has quit IRC21:09
*** tobberydberg has quit IRC21:12
*** tobberydberg has joined #openstack-keystone21:17
*** dstepanenko has joined #openstack-keystone21:18
*** jmlowe has joined #openstack-keystone21:20
*** mjax has joined #openstack-keystone21:21
*** dstepanenko has quit IRC21:22
samueldmqlbragstad: +++ agreed, but we can always make that doc better as we add support for that21:23
samueldmqgagehugo: thanks, approved21:25
*** kbaegis1 has joined #openstack-keystone21:26
samueldmqlbragstad:  for bug 1687616 looks like we're waiting on more info from the reporter?21:26
openstackbug 1687616 in OpenStack Identity (keystone) "KeyError 'options' while doing zero downtime upgrade from N to O" [Undecided,New]
*** kbaegis has quit IRC21:27
*** edmondsw has quit IRC21:28
*** edmondsw has joined #openstack-keystone21:29
*** tobberydberg has quit IRC21:29
*** thorst has quit IRC21:31
*** edmondsw has quit IRC21:34
kmalloclbragstad: that looks like something wasn't expanded in the schema21:37
kmalloclbragstad: you should mark that bug incomplete21:38
kmalloclbragstad: did it21:38
samueldmqtest_password_history_not_enforced_in_admin_reset is interesting21:39
samueldmqgagehugo: you were able to reproduce it, right? ^21:39
*** nkinder has quit IRC21:40
gagehugosamueldmq yeah, ran the test repeatedly and would hit that every so often21:40
kmalloclbragstad: this makes me sad. it should have been is_read_only or something ...21:41
kmalloclbragstad: anyway... your code looks good for the try/except21:41
samueldmqgagehugo: in a for loop or manually21:41
samueldmqlike, calling every second, couple of seconds, how was your test?21:41
gagehugoI wrote a script to run the test x times manually21:42
*** raildo has quit IRC21:43
*** rajalokan has quit IRC21:47
*** thorst has joined #openstack-keystone21:50
*** kbaegis1 has quit IRC21:50
*** kbaegis has joined #openstack-keystone21:52
samueldmqgagehugo: but you were running that test isolated, correct?21:52
kmalloclbragstad: +2, with a comment on how you could have made the try/except a single try/except instead of two21:53
*** thorst has quit IRC21:55
lbragstadack wrapping up an email and i can respin21:56
*** aojea has joined #openstack-keystone21:59
*** dklyle has joined #openstack-keystone22:06
*** david-lyle has quit IRC22:06
kmalloclbragstad: no need to respin.22:07
kmallocjust a comment on it22:07
kmalloclbragstad: triaged a bunch of bugs.22:07
*** aojea has quit IRC22:07
*** adriant has joined #openstack-keystone22:08
*** dstepanenko has joined #openstack-keystone22:12
*** aojea has joined #openstack-keystone22:13
*** dstepanenko has quit IRC22:17
*** rcernin has quit IRC22:20
*** sbezverk has joined #openstack-keystone22:20
*** ioggstream has joined #openstack-keystone22:23
gagehugosamueldmq yes22:27
otleimatlbragstad: is general code cleanup accepted?22:29
*** aojea has quit IRC22:31
lbragstadotleimat: during the rc period?22:34
*** aojea has joined #openstack-keystone22:34
*** tobberydberg has joined #openstack-keystone22:37
*** ducttape_ has joined #openstack-keystone22:39
*** aojea has quit IRC22:39
openstackgerritLance Bragstad proposed openstack/keystone master: Unset project ids for all identity backends
lbragstadkmalloc: nice - thanks for the review, addressed ^22:41
*** tobberydberg has quit IRC22:41
*** dave-mccowan has quit IRC22:44
*** kornicameister has quit IRC22:50
*** kornicameister has joined #openstack-keystone22:55
*** tobberydberg has joined #openstack-keystone23:07
*** tobberydberg has quit IRC23:12
*** ducttap__ has joined #openstack-keystone23:17
*** ducttape_ has quit IRC23:20
*** mjax has quit IRC23:23
openstackgerritGage Hugo proposed openstack/keystone master: Have project get domain_id from parent
*** mjax has joined #openstack-keystone23:25
jamielennoxkmalloc: yea, i was wondering who the nick was that would ping me like that23:32
jamielennoxkmalloc: what's up?23:32
*** ducttap__ has quit IRC23:34
*** markvoelker has quit IRC23:49
*** gyee has quit IRC23:50

Generated by 2.15.3 by Marius Gedminas - find it at!