Tuesday, 2019-07-16

openstackgerritguang-yee proposed openstack/keystone master: update documentation for X.509 tokenless auth  https://review.opendev.org/66979001:00
*** gyee has quit IRC01:14
*** imacdonn has quit IRC01:15
*** imacdonn has joined #openstack-keystone01:16
*** tkajinam has quit IRC02:23
*** tkajinam has joined #openstack-keystone02:24
*** whoami-rajat has joined #openstack-keystone02:42
*** jamesmcarthur has quit IRC04:50
*** akovi has joined #openstack-keystone05:03
*** pcaruana has joined #openstack-keystone05:08
*** shyamb has joined #openstack-keystone05:13
*** shyamb has quit IRC05:28
*** jamesmcarthur has joined #openstack-keystone05:29
*** jamesmcarthur has quit IRC05:37
*** shyamb has joined #openstack-keystone05:47
*** vishalmanchanda has joined #openstack-keystone05:55
*** jmlowe has quit IRC06:07
*** jmlowe has joined #openstack-keystone06:10
*** new_student1411 has joined #openstack-keystone06:10
*** new_student1411 has quit IRC06:29
*** shyamb has quit IRC06:46
*** shyamb has joined #openstack-keystone06:51
*** rcernin has quit IRC07:00
*** xek has joined #openstack-keystone07:09
*** dancn has joined #openstack-keystone07:16
openstackgerritguang-yee proposed openstack/keystone master: implement system scope for application credential  https://review.opendev.org/67092607:31
*** jamesmcarthur has joined #openstack-keystone07:33
*** jamesmcarthur has quit IRC07:38
openstackgerritwangxiyuan proposed openstack/keystone master: Remove useless parameter  https://review.opendev.org/67097007:45
*** shyamb has quit IRC07:58
*** vishakha has quit IRC08:03
*** dancn has quit IRC08:12
*** dancn has joined #openstack-keystone08:17
*** tkajinam has quit IRC08:25
*** akovi has left #openstack-keystone08:28
*** akovi has joined #openstack-keystone08:33
*** akovi has left #openstack-keystone08:33
*** dancn has quit IRC08:46
*** dancn has joined #openstack-keystone08:51
*** jamesmcarthur has joined #openstack-keystone08:56
*** jamesmcarthur has quit IRC09:00
*** shyamb has joined #openstack-keystone09:00
*** jamesmcarthur has joined #openstack-keystone09:28
*** jamesmcarthur has quit IRC09:32
*** shyamb has quit IRC09:53
*** shyamb has joined #openstack-keystone10:06
*** dancn has quit IRC10:13
*** shyamb has quit IRC10:18
*** dancn has joined #openstack-keystone10:19
*** jojoda has joined #openstack-keystone10:22
*** jojoda has quit IRC10:48
*** shyamb has joined #openstack-keystone10:48
*** jojoda has joined #openstack-keystone10:58
*** dancn has quit IRC11:18
*** jamesmcarthur has joined #openstack-keystone11:29
*** tesseract has joined #openstack-keystone11:30
*** jamesmcarthur has quit IRC11:33
gmanncmurphy: is username case sensitive in keystone ? - https://review.opendev.org/#/c/670610/411:48
*** raildo has joined #openstack-keystone11:55
*** shyamb has quit IRC11:59
*** shyamb has joined #openstack-keystone11:59
*** jamesmcarthur has joined #openstack-keystone12:03
*** jamesmcarthur has quit IRC12:08
*** jamesmcarthur has joined #openstack-keystone12:15
*** mchlumsky has joined #openstack-keystone12:48
*** tesseract has quit IRC12:53
*** tesseract has joined #openstack-keystone12:55
*** mchlumsky has quit IRC12:58
*** kplant has joined #openstack-keystone12:58
*** mchlumsky has joined #openstack-keystone12:59
*** dancn has joined #openstack-keystone13:03
*** jamesmcarthur has quit IRC13:19
*** shyamb has quit IRC13:29
*** vishalmanchanda has quit IRC13:32
*** trident has quit IRC13:38
*** trident has joined #openstack-keystone13:39
cmurphygmann: it depends https://docs.openstack.org/keystone/latest/admin/case-insensitive.html14:14
cmurphygmann: most of the time keystone is case-insensitive case-preserving14:15
kplantcould anyone recommend a good article on setting up k2k federation?14:18
gmanncmurphy: i see. Tempest is asserting on case sensitive user name which we should fix then. thanks.14:19
cmurphykplant: we have documentation on it https://docs.openstack.org/keystone/latest/admin/federation/introduction.html https://docs.openstack.org/keystone/latest/admin/federation/configure_federation.html#keystone-as-an-identity-provider-idp14:21
kplantcmurphy: ty, i did find these before but was not anywhere near successful14:25
kplanti'll give it another try14:25
kmallocgmann: odd that tempest is asserting case-sensitivity14:28
kmallocgmann: can you point us at the test?14:29
gmannkmalloc: that is assertEqual we use for comparison. no explicit assert for case-sensitivity  - https://review.opendev.org/#/c/670610/4/tempest/api/identity/v3/test_tokens.py14:31
kmallocgmann: so, that should be correct in it's assertion, the case should be preserved14:32
kmallocaccording to our API contract and what cmurphy linked14:32
kmallocit's not so much that it's case sensitive, just that we should be preserving in all cases14:33
kmallocgmann: depending on the reference that was used to create it14:34
gmannkmalloc: true. Tempest compare the return value with username present in conf value which was with upper case letter (in keystone it was all lower) and so failed.14:36
gmannkmalloc: https://bugs.launchpad.net/tempest/+bug/183661814:36
openstackLaunchpad bug 1836618 in tempest "Due to case sensitivity of a user name compare in a keystone test, the test might fail" [Medium,Triaged]14:36
gmannwe can say it is configuration issue also but if keystone will 409 on user creation with case-sensitive name (as mentioned in doc) then it is not worth for tempest to assert on case-sensitive of user name.14:37
gmannif both comparison value is from keystone then yes we can keep asserting as keystone will preserve the case14:38
gmannif anyone configure tempest with username 'KellyTest' where keystone user name is 'kellyTest' then Tempest can assume it is same user because 'KellyTest' and 'kellyTest' cannot co-exist in keystone.14:41
*** jamesmcarthur has joined #openstack-keystone15:03
openstackgerritColleen Murphy proposed openstack/keystone master: Add new attribute to the federation protocol API  https://review.opendev.org/63730515:22
*** dancn has quit IRC15:36
*** gyee has joined #openstack-keystone15:39
cmurphymeeting in 20 minutes in #openstack-meeting-alt15:40
openstackgerritKristi Nikolla proposed openstack/keystone master: Deprecate [federation] federated_domain_name  https://review.opendev.org/65161415:44
openstackgerritKristi Nikolla proposed openstack/keystone master: Deprecate [federation] federated_domain_name  https://review.opendev.org/65161415:47
*** vishakha has joined #openstack-keystone15:52
openstackgerritKristi Nikolla proposed openstack/keystone-specs master: Expiring Group Membership Through Mapping Rules  https://review.opendev.org/60420115:56
cmurphymeeting now in #openstack-meeting-alt16:01
*** vishalmanchanda has joined #openstack-keystone16:06
*** jamesmcarthur has quit IRC16:29
*** jamesmcarthur has joined #openstack-keystone16:31
*** tesseract has quit IRC16:33
*** ayoung has joined #openstack-keystone16:37
*** atahardjebbar has joined #openstack-keystone16:40
gyeecmurphy, for application credentials, do we want domain admin and project admin to have access to those? Or just system-scoped and owner only?17:01
*** ag-47 has joined #openstack-keystone17:05
cmurphygyee: i think i would take keystone/common/policies/credential.py as a reference, it only implements it for system scope and owner17:06
cmurphybut i could see an argument for domain admins to see app creds for users in their domain17:06
cmurphynot sure where lbragstad is today but that's something i'd want to bounce off him17:07
gyeemaybe similar to trusts as well17:12
openstackgerritHervé Beraud proposed openstack/oslo.policy master: Add unit tests on cache handler  https://review.opendev.org/67111317:13
cmurphytrusts and app creds will be the same but we haven't done trusts yet17:13
*** atahardjebbar has quit IRC17:13
cmurphyso whatever we decide for app creds we'll copy for trusts :)17:13
kmallocthe question is that the domain admin can see app creds for users owned by the domain? or the domain admin can see app creds granting access to projects within their domain? or both?17:17
kmalloci think app creds are very much a user-thing17:18
kmalloci'm inclined to say no, domain admins cannot poke at the app creds, but they can see users.17:18
cmurphymy thinking was since domain admins can see users in their own domain then maybe they should also see those users' app creds17:19
cmurphyotoh app creds are basically passwords and so maybe nobody should see that17:19
gyeekmalloc, yeah make sense17:19
gyeesupporting argument would be can domain admin reset user passwords?17:20
cmurphyidentity:update_user has system and domain scope types so yes they could change user passwords17:21
gyeeso from that perspective, domain admin *can* access anything that the user own anyway17:22
gyeetransitive property in math, or something like that :-)17:22
kmallocbut you might (probably) would lock the user out to gain that access17:25
kmallocthe app cred explicitly grants that access without the user knowing.17:25
gyeeso app cred continue to work even user is disabled?17:26
kmallocthey should not continue to work17:27
cmurphythey don't17:27
cmurphythey get deleted actually17:27
kmallocreally it doesn't matter too much either way17:28
gyeekmalloc, I see your point, but currently only user (owner) can create the app creds17:28
gyeebut the "without the user knowing" part is a gray area17:30
gyeemaybe we can implement the capability and let deployers decide whether they want to enable it? And if the don't, simply remove the rule from policy.json.17:34
gyeesound good?17:34
cmurphyyou can't change the scope type in policy.json17:34
cmurphyyes, it was designed that way, because the scope type usually needs a target created for it and that's usually done in code in the controller, so APIs have inherent scopes already17:37
gyeeright, the target match has to be created in the code, the complex ones anyway17:41
kmallocgyee: it also ensures that, for example, system scope is consistent across cloud deployments. if it's infinitely configurable it is also infinitely impossible to really support.17:41
kmallocthese are large target types, e.g. "system" for managing things that are explicitly not project/domain, and likewise if something should be domain-only scope17:41
kmallocwe're trying to set direction to eliminate the "Admin-ness" bleedover problem17:42
kmallocit's just a very slow process.17:42
gyeethen policy.json is not much effective17:43
kmallocpolicy.json controls what roles can be used17:43
kmallocbut not the scope-type17:43
kmallocit is still useful.17:43
*** jamesmcarthur has quit IRC17:43
kmallocpersonally i dislike policy.json17:44
kmallocbut i can see the need to customize role-specific stuff, you might need mroe fine grained controls than default17:44
kmallocbut the larger scope type is something we can and must design for.17:44
gyeeto me, find grained includes scope and everything :-)17:44
kmallocbut as an API designer i must write code to deal with domain vs system vs project17:45
gyeebut I understand to need to prevent users from shooting themselves in the foot17:45
kmallocif the API is not intended to work with project scope, it wont be coded to do so17:45
kmalloctherefore the API should not allow project scope17:45
kmallocthis isn't just kevlar shoes.17:46
gyeethe reason we have to write code to build up the target was because of oslo.policy limitation17:46
*** ag-47 has quit IRC17:46
kmallocnot exactly just an oslo.policy limit, fundamentally domains are different17:47
kmallocor were17:47
kmallocand there are things that shouldn't be granted to a domain or project admin ever17:47
kmallochaving a wedged in "well it looks like X but it's totally different" e.g. "is_admin_project" is not a very good design17:48
gyeeright, but we should be able to express those entirely in terms of rules, not half rules and half code17:48
gyeeat least in theory anyway17:48
kmallocthe API must account for those differences in general.17:48
kmalloccode wise, internal structure wise17:48
kmallocif it's not an action that is specifically a project thing, working on resources owned by a project, it shouldn't ever have been project scoped17:49
kmallocwe had no fidelity in saying "this isn't project scoped" before, now we do17:49
kmalloccreating a domain, for example, should never have been project scoped17:49
kmallocit's not owned by a project17:50
gyeeright, but does API implementation have to be tightly coupled with access control? or can we ever delegate access to a third party component (i.e. API proxy)17:52
gyeethat's all I am saying17:52
kmallocas long as the scope type, a requirement of the API is conveyed by the external control, that is fine17:52
kmallocwe support the HTTP check in policy17:52
kmallocbut the scope type is still going to be a requirement.17:53
kmallocthe application has to have some level of understanding of what someone is allowed to do17:53
kmallocall applications do17:53
kmallocwe've drawn the lines very broadly with scope types.17:53
kmallocand allow for the fidelity within those scopes to be uncoupled / managed as needed17:54
gyeebut HTTP check is still limited to what can express in policy.json right?17:54
kmalloci think it allows a yes/no as  long as you consume the info passed to the normal enforcer17:55
kmallocso not explicitly what can be expressed in policy.json17:55
kmallocbut you're stuck with the information the application passes to the enforcer17:55
gyeeyep, that includes scope type17:59
gyeeso ... just system-scoped and owner for app creds then? :-)18:00
kmalloci am inclined to again say app creds are owned by the user18:01
kmallocso no, system (system admin) or user ownly18:01
kmallocthe only exception might be domain scope, for users in the domain, not app creds that grant access to the domain18:01
kmallocbut frankly, i'd make it a separate API18:02
kmallocsystem / user, separate API for introspecting app creds that give access to a given domain18:02
gyeeyou mean we limit the scope of the app cred to the domain in which the owner belongs?18:04
kmallocthe separate API would be if we need it18:05
kmallocbut honestly, if you have a user granted a role on a domain, it is 100% fine to assume they might use an app cred18:05
kmallocwhy do you care if they do?18:05
*** jamesmcarthur has joined #openstack-keystone18:07
gyeeapp cred is basically a delegation mechanism, just like trust, from what I can understand18:07
kmalloctrust is more akin to granting a role to a user18:07
kmallocapp cred is more like an alternate password with a reduced footprint to access18:08
kmalloctrusts can actively delegate to another user within the system, impersonation as an option18:08
kmallocapp cred is still your user, no ability to impersonate18:08
kmallocso, external delegation ... if you look sideways at it18:08
gyeeright, without the extra user overhead18:09
kmallocbut it is still acting as *your* user.18:10
kmalloctrusts only act as your user with impersonation18:10
kmallocapp creds are not explicitly a delegation mechanism18:10
kmallocif you're looking at within keystone, trusts are explicitly only within keystone18:10
gyeeI am just trying to understand what we went to limit. That part is a bit fuzzy to me.18:11
kmallocthings owned by users are owned by users18:11
kmallocsystem administrators (cloud level admins) have extra insight to all facets of the system18:11
kmallocif a secret or resource is user-owned, it is not a domain admin thing18:11
kmallocsame thing with credentials (mfa, etc)18:11
gyeethe concept of ownership is a bit cloudy in openstack, no pun intended :-)18:12
kmallocthere are three ownerships18:12
kmallocuser (some things in keystone), project (most things in openstack), domain (some things in keystone)18:12
*** efried has quit IRC18:12
kmallocand some limited cases of "not owned"18:13
kmallocideally a system scope would be used to create the public images18:13
kmallocand the public networks (long term)18:13
kmallocif it's owned by a user it should be limited to being manipulated/looked at by the user or the system-level (root) type admin18:14
gyeetake nova for example, who *owns* a given VM/server? project isn't it?18:16
kmallocthat is a project ownership18:18
*** efried has joined #openstack-keystone18:21
gyeeand who owns projects?18:24
*** jamesmcarthur has quit IRC18:24
cmurphysystem and domain users can do things with projects18:28
gyeeusers or admins?18:33
cmurphyboth, domain readers for example can list projects in their domain18:33
gyeecmurphy, would be nice to have a session on openstack resource ownership if we haven't done one already :-)18:35
cmurphygyee: yeah it's confusing, we're kind of working through keystone before we try to figure out how it's going to work in the rest of openstack, though the nova team has started working it out too https://review.opendev.org/54785018:41
*** jamesmcarthur has joined #openstack-keystone18:42
*** jamesmcarthur has quit IRC18:51
*** jamesmcarthur has joined #openstack-keystone18:52
*** jamesmcarthur_ has joined #openstack-keystone18:53
*** jamesmcarthur_ has quit IRC18:54
*** jamesmcarthur has quit IRC18:57
*** jamesmcarthur has joined #openstack-keystone18:58
*** jamesmcarthur_ has joined #openstack-keystone18:59
*** jamesmcarthur has quit IRC19:03
*** jamesmcarthur_ has quit IRC19:04
*** jamesmcarthur has joined #openstack-keystone19:05
*** jamesmcarthur_ has joined #openstack-keystone19:06
*** jamesmcarthur has quit IRC19:10
*** jamesmcarthur_ has quit IRC19:25
*** jamesmcarthur has joined #openstack-keystone19:28
*** jamesmcarthur_ has joined #openstack-keystone19:29
*** vishakha has quit IRC19:30
openstackgerritKristi Nikolla proposed openstack/keystone master: Deprecate [federation] federated_domain_name  https://review.opendev.org/65161419:31
*** jamesmcarthur_ has quit IRC19:32
*** jamesmcarthur_ has joined #openstack-keystone19:33
*** jamesmcarthur has quit IRC19:33
*** jamesmcarthur has joined #openstack-keystone19:34
*** jamesmcarthur_ has quit IRC19:37
*** jamesmcarthur has quit IRC19:53
*** jamesmcarthur has joined #openstack-keystone19:53
*** jamesmcarthur_ has joined #openstack-keystone19:54
*** jamesmcarthur has quit IRC19:58
*** kplant has quit IRC19:59
*** dasp has quit IRC20:45
*** jamesmcarthur_ has quit IRC20:45
*** dasp has joined #openstack-keystone20:47
*** pcaruana has quit IRC21:01
*** raildo has quit IRC21:04
openstackgerritHervé Beraud proposed openstack/oslo.policy master: Add unit tests on cache handler  https://review.opendev.org/67111321:14
openstackgerritHervé Beraud proposed openstack/oslo.policy master: Correctly handle IO errors at policy file load  https://review.opendev.org/67057121:16
*** xek has quit IRC22:02
*** whoami-rajat has quit IRC22:31
*** rcernin has joined #openstack-keystone22:36
openstackgerritMerged openstack/oslo.limit master: Add Python 3 Train unit tests  https://review.opendev.org/66946122:38
*** tkajinam has joined #openstack-keystone22:53
*** vishalmanchanda has quit IRC23:05

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