| openstackgerrit | guang-yee proposed openstack/keystone master: update documentation for X.509 tokenless auth https://review.opendev.org/669790 | 01:00 |
|---|---|---|
| *** gyee has quit IRC | 01:14 | |
| *** imacdonn has quit IRC | 01:15 | |
| *** imacdonn has joined #openstack-keystone | 01:16 | |
| *** tkajinam has quit IRC | 02:23 | |
| *** tkajinam has joined #openstack-keystone | 02:24 | |
| *** whoami-rajat has joined #openstack-keystone | 02:42 | |
| *** jamesmcarthur has quit IRC | 04:50 | |
| *** akovi has joined #openstack-keystone | 05:03 | |
| *** pcaruana has joined #openstack-keystone | 05:08 | |
| *** shyamb has joined #openstack-keystone | 05:13 | |
| *** shyamb has quit IRC | 05:28 | |
| *** jamesmcarthur has joined #openstack-keystone | 05:29 | |
| *** jamesmcarthur has quit IRC | 05:37 | |
| *** shyamb has joined #openstack-keystone | 05:47 | |
| *** vishalmanchanda has joined #openstack-keystone | 05:55 | |
| *** jmlowe has quit IRC | 06:07 | |
| *** jmlowe has joined #openstack-keystone | 06:10 | |
| *** new_student1411 has joined #openstack-keystone | 06:10 | |
| *** new_student1411 has quit IRC | 06:29 | |
| *** shyamb has quit IRC | 06:46 | |
| *** shyamb has joined #openstack-keystone | 06:51 | |
| *** rcernin has quit IRC | 07:00 | |
| *** xek has joined #openstack-keystone | 07:09 | |
| *** dancn has joined #openstack-keystone | 07:16 | |
| openstackgerrit | guang-yee proposed openstack/keystone master: implement system scope for application credential https://review.opendev.org/670926 | 07:31 |
| *** jamesmcarthur has joined #openstack-keystone | 07:33 | |
| *** jamesmcarthur has quit IRC | 07:38 | |
| openstackgerrit | wangxiyuan proposed openstack/keystone master: Remove useless parameter https://review.opendev.org/670970 | 07:45 |
| *** shyamb has quit IRC | 07:58 | |
| *** vishakha has quit IRC | 08:03 | |
| *** dancn has quit IRC | 08:12 | |
| *** dancn has joined #openstack-keystone | 08:17 | |
| *** tkajinam has quit IRC | 08:25 | |
| *** akovi has left #openstack-keystone | 08:28 | |
| *** akovi has joined #openstack-keystone | 08:33 | |
| *** akovi has left #openstack-keystone | 08:33 | |
| *** dancn has quit IRC | 08:46 | |
| *** dancn has joined #openstack-keystone | 08:51 | |
| *** jamesmcarthur has joined #openstack-keystone | 08:56 | |
| *** jamesmcarthur has quit IRC | 09:00 | |
| *** shyamb has joined #openstack-keystone | 09:00 | |
| *** jamesmcarthur has joined #openstack-keystone | 09:28 | |
| *** jamesmcarthur has quit IRC | 09:32 | |
| *** shyamb has quit IRC | 09:53 | |
| *** shyamb has joined #openstack-keystone | 10:06 | |
| *** dancn has quit IRC | 10:13 | |
| *** shyamb has quit IRC | 10:18 | |
| *** dancn has joined #openstack-keystone | 10:19 | |
| *** jojoda has joined #openstack-keystone | 10:22 | |
| *** jojoda has quit IRC | 10:48 | |
| *** shyamb has joined #openstack-keystone | 10:48 | |
| *** jojoda has joined #openstack-keystone | 10:58 | |
| *** dancn has quit IRC | 11:18 | |
| *** jamesmcarthur has joined #openstack-keystone | 11:29 | |
| *** tesseract has joined #openstack-keystone | 11:30 | |
| *** jamesmcarthur has quit IRC | 11:33 | |
| gmann | cmurphy: is username case sensitive in keystone ? - https://review.opendev.org/#/c/670610/4 | 11:48 |
| *** raildo has joined #openstack-keystone | 11:55 | |
| *** shyamb has quit IRC | 11:59 | |
| *** shyamb has joined #openstack-keystone | 11:59 | |
| *** jamesmcarthur has joined #openstack-keystone | 12:03 | |
| *** jamesmcarthur has quit IRC | 12:08 | |
| *** jamesmcarthur has joined #openstack-keystone | 12:15 | |
| *** mchlumsky has joined #openstack-keystone | 12:48 | |
| *** tesseract has quit IRC | 12:53 | |
| *** tesseract has joined #openstack-keystone | 12:55 | |
| *** mchlumsky has quit IRC | 12:58 | |
| *** kplant has joined #openstack-keystone | 12:58 | |
| *** mchlumsky has joined #openstack-keystone | 12:59 | |
| *** dancn has joined #openstack-keystone | 13:03 | |
| *** jamesmcarthur has quit IRC | 13:19 | |
| *** shyamb has quit IRC | 13:29 | |
| *** vishalmanchanda has quit IRC | 13:32 | |
| *** trident has quit IRC | 13:38 | |
| *** trident has joined #openstack-keystone | 13:39 | |
| cmurphy | gmann: it depends https://docs.openstack.org/keystone/latest/admin/case-insensitive.html | 14:14 |
| cmurphy | gmann: most of the time keystone is case-insensitive case-preserving | 14:15 |
| kplant | could anyone recommend a good article on setting up k2k federation? | 14:18 |
| gmann | cmurphy: i see. Tempest is asserting on case sensitive user name which we should fix then. thanks. | 14:19 |
| cmurphy | kplant: 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-idp | 14:21 |
| kplant | cmurphy: ty, i did find these before but was not anywhere near successful | 14:25 |
| kplant | i'll give it another try | 14:25 |
| kmalloc | gmann: odd that tempest is asserting case-sensitivity | 14:28 |
| kmalloc | gmann: can you point us at the test? | 14:29 |
| gmann | kmalloc: 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.py | 14:31 |
| kmalloc | gmann: so, that should be correct in it's assertion, the case should be preserved | 14:32 |
| kmalloc | according to our API contract and what cmurphy linked | 14:32 |
| kmalloc | it's not so much that it's case sensitive, just that we should be preserving in all cases | 14:33 |
| kmalloc | gmann: depending on the reference that was used to create it | 14:34 |
| gmann | kmalloc: 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 |
| gmann | kmalloc: https://bugs.launchpad.net/tempest/+bug/1836618 | 14:36 |
| openstack | Launchpad 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 |
| gmann | we 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 |
| gmann | if both comparison value is from keystone then yes we can keep asserting as keystone will preserve the case | 14:38 |
| gmann | if 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 |
| knikolla | o/ | 14:58 |
| *** jamesmcarthur has joined #openstack-keystone | 15:03 | |
| openstackgerrit | Colleen Murphy proposed openstack/keystone master: Add new attribute to the federation protocol API https://review.opendev.org/637305 | 15:22 |
| gagehugo | o/ | 15:30 |
| *** dancn has quit IRC | 15:36 | |
| *** gyee has joined #openstack-keystone | 15:39 | |
| cmurphy | meeting in 20 minutes in #openstack-meeting-alt | 15:40 |
| openstackgerrit | Kristi Nikolla proposed openstack/keystone master: Deprecate [federation] federated_domain_name https://review.opendev.org/651614 | 15:44 |
| openstackgerrit | Kristi Nikolla proposed openstack/keystone master: Deprecate [federation] federated_domain_name https://review.opendev.org/651614 | 15:47 |
| *** vishakha has joined #openstack-keystone | 15:52 | |
| openstackgerrit | Kristi Nikolla proposed openstack/keystone-specs master: Expiring Group Membership Through Mapping Rules https://review.opendev.org/604201 | 15:56 |
| cmurphy | meeting now in #openstack-meeting-alt | 16:01 |
| *** vishalmanchanda has joined #openstack-keystone | 16:06 | |
| *** jamesmcarthur has quit IRC | 16:29 | |
| *** jamesmcarthur has joined #openstack-keystone | 16:31 | |
| *** tesseract has quit IRC | 16:33 | |
| *** ayoung has joined #openstack-keystone | 16:37 | |
| *** atahardjebbar has joined #openstack-keystone | 16:40 | |
| gyee | cmurphy, 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-keystone | 17:05 | |
| cmurphy | gyee: i think i would take keystone/common/policies/credential.py as a reference, it only implements it for system scope and owner | 17:06 |
| cmurphy | but i could see an argument for domain admins to see app creds for users in their domain | 17:06 |
| cmurphy | not sure where lbragstad is today but that's something i'd want to bounce off him | 17:07 |
| gyee | maybe similar to trusts as well | 17:12 |
| openstackgerrit | Hervé Beraud proposed openstack/oslo.policy master: Add unit tests on cache handler https://review.opendev.org/671113 | 17:13 |
| cmurphy | trusts and app creds will be the same but we haven't done trusts yet | 17:13 |
| *** atahardjebbar has quit IRC | 17:13 | |
| cmurphy | so whatever we decide for app creds we'll copy for trusts :) | 17:13 |
| gyee | yeah | 17:15 |
| kmalloc | the 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 |
| kmalloc | i think app creds are very much a user-thing | 17:18 |
| kmalloc | i'm inclined to say no, domain admins cannot poke at the app creds, but they can see users. | 17:18 |
| cmurphy | my thinking was since domain admins can see users in their own domain then maybe they should also see those users' app creds | 17:19 |
| cmurphy | otoh app creds are basically passwords and so maybe nobody should see that | 17:19 |
| gyee | kmalloc, yeah make sense | 17:19 |
| gyee | supporting argument would be can domain admin reset user passwords? | 17:20 |
| cmurphy | identity:update_user has system and domain scope types so yes they could change user passwords | 17:21 |
| gyee | so from that perspective, domain admin *can* access anything that the user own anyway | 17:22 |
| gyee | transitive property in math, or something like that :-) | 17:22 |
| cmurphy | lol | 17:22 |
| kmalloc | right | 17:25 |
| kmalloc | but you might (probably) would lock the user out to gain that access | 17:25 |
| kmalloc | the app cred explicitly grants that access without the user knowing. | 17:25 |
| gyee | so app cred continue to work even user is disabled? | 17:26 |
| kmalloc | no. | 17:27 |
| kmalloc | they should not continue to work | 17:27 |
| cmurphy | they don't | 17:27 |
| cmurphy | they get deleted actually | 17:27 |
| kmalloc | *shrug* | 17:28 |
| kmalloc | really it doesn't matter too much either way | 17:28 |
| gyee | kmalloc, I see your point, but currently only user (owner) can create the app creds | 17:28 |
| gyee | but the "without the user knowing" part is a gray area | 17:30 |
| gyee | maybe 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 |
| gyee | sound good? | 17:34 |
| cmurphy | you can't change the scope type in policy.json | 17:34 |
| gyee | seriously?! | 17:35 |
| cmurphy | yes, 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 already | 17:37 |
| gyee | right, the target match has to be created in the code, the complex ones anyway | 17:41 |
| kmalloc | gyee: 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 |
| kmalloc | these are large target types, e.g. "system" for managing things that are explicitly not project/domain, and likewise if something should be domain-only scope | 17:41 |
| kmalloc | we're trying to set direction to eliminate the "Admin-ness" bleedover problem | 17:42 |
| kmalloc | it's just a very slow process. | 17:42 |
| gyee | then policy.json is not much effective | 17:43 |
| kmalloc | policy.json controls what roles can be used | 17:43 |
| kmalloc | but not the scope-type | 17:43 |
| kmalloc | it is still useful. | 17:43 |
| *** jamesmcarthur has quit IRC | 17:43 | |
| kmalloc | personally i dislike policy.json | 17:44 |
| kmalloc | but i can see the need to customize role-specific stuff, you might need mroe fine grained controls than default | 17:44 |
| kmalloc | but the larger scope type is something we can and must design for. | 17:44 |
| gyee | to me, find grained includes scope and everything :-) | 17:44 |
| kmalloc | but as an API designer i must write code to deal with domain vs system vs project | 17:45 |
| gyee | but I understand to need to prevent users from shooting themselves in the foot | 17:45 |
| kmalloc | if the API is not intended to work with project scope, it wont be coded to do so | 17:45 |
| kmalloc | therefore the API should not allow project scope | 17:45 |
| kmalloc | this isn't just kevlar shoes. | 17:46 |
| gyee | the reason we have to write code to build up the target was because of oslo.policy limitation | 17:46 |
| *** ag-47 has quit IRC | 17:46 | |
| kmalloc | not exactly just an oslo.policy limit, fundamentally domains are different | 17:47 |
| kmalloc | or were | 17:47 |
| kmalloc | and there are things that shouldn't be granted to a domain or project admin ever | 17:47 |
| kmalloc | having a wedged in "well it looks like X but it's totally different" e.g. "is_admin_project" is not a very good design | 17:48 |
| gyee | right, but we should be able to express those entirely in terms of rules, not half rules and half code | 17:48 |
| gyee | at least in theory anyway | 17:48 |
| kmalloc | no. | 17:48 |
| kmalloc | the API must account for those differences in general. | 17:48 |
| kmalloc | code wise, internal structure wise | 17:48 |
| kmalloc | if 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 scoped | 17:49 |
| kmalloc | we had no fidelity in saying "this isn't project scoped" before, now we do | 17:49 |
| kmalloc | creating a domain, for example, should never have been project scoped | 17:49 |
| kmalloc | it's not owned by a project | 17:50 |
| gyee | right, 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 |
| gyee | that's all I am saying | 17:52 |
| kmalloc | as long as the scope type, a requirement of the API is conveyed by the external control, that is fine | 17:52 |
| kmalloc | we support the HTTP check in policy | 17:52 |
| kmalloc | but the scope type is still going to be a requirement. | 17:53 |
| kmalloc | the application has to have some level of understanding of what someone is allowed to do | 17:53 |
| kmalloc | all applications do | 17:53 |
| kmalloc | we've drawn the lines very broadly with scope types. | 17:53 |
| kmalloc | and allow for the fidelity within those scopes to be uncoupled / managed as needed | 17:54 |
| gyee | but HTTP check is still limited to what can express in policy.json right? | 17:54 |
| kmalloc | i think it allows a yes/no as long as you consume the info passed to the normal enforcer | 17:55 |
| kmalloc | so not explicitly what can be expressed in policy.json | 17:55 |
| kmalloc | but you're stuck with the information the application passes to the enforcer | 17:55 |
| gyee | yep, that includes scope type | 17:59 |
| gyee | so ... just system-scoped and owner for app creds then? :-) | 18:00 |
| kmalloc | i am inclined to again say app creds are owned by the user | 18:01 |
| kmalloc | so no, system (system admin) or user ownly | 18:01 |
| kmalloc | only* | 18:01 |
| kmalloc | the only exception might be domain scope, for users in the domain, not app creds that grant access to the domain | 18:01 |
| kmalloc | but frankly, i'd make it a separate API | 18:02 |
| kmalloc | system / user, separate API for introspecting app creds that give access to a given domain | 18:02 |
| gyee | you mean we limit the scope of the app cred to the domain in which the owner belongs? | 18:04 |
| kmalloc | no. | 18:04 |
| kmalloc | the separate API would be if we need it | 18:05 |
| kmalloc | but honestly, if you have a user granted a role on a domain, it is 100% fine to assume they might use an app cred | 18:05 |
| kmalloc | why do you care if they do? | 18:05 |
| *** jamesmcarthur has joined #openstack-keystone | 18:07 | |
| gyee | app cred is basically a delegation mechanism, just like trust, from what I can understand | 18:07 |
| kmalloc | trust is more akin to granting a role to a user | 18:07 |
| kmalloc | app cred is more like an alternate password with a reduced footprint to access | 18:08 |
| kmalloc | trusts can actively delegate to another user within the system, impersonation as an option | 18:08 |
| kmalloc | app cred is still your user, no ability to impersonate | 18:08 |
| kmalloc | so, external delegation ... if you look sideways at it | 18:08 |
| gyee | right, without the extra user overhead | 18:09 |
| kmalloc | but it is still acting as *your* user. | 18:10 |
| gyee | correct | 18:10 |
| kmalloc | trusts only act as your user with impersonation | 18:10 |
| kmalloc | app creds are not explicitly a delegation mechanism | 18:10 |
| kmalloc | if you're looking at within keystone, trusts are explicitly only within keystone | 18:10 |
| gyee | I am just trying to understand what we went to limit. That part is a bit fuzzy to me. | 18:11 |
| kmalloc | things owned by users are owned by users | 18:11 |
| kmalloc | system administrators (cloud level admins) have extra insight to all facets of the system | 18:11 |
| kmalloc | if a secret or resource is user-owned, it is not a domain admin thing | 18:11 |
| kmalloc | same thing with credentials (mfa, etc) | 18:11 |
| gyee | the concept of ownership is a bit cloudy in openstack, no pun intended :-) | 18:12 |
| kmalloc | there are three ownerships | 18:12 |
| kmalloc | user (some things in keystone), project (most things in openstack), domain (some things in keystone) | 18:12 |
| *** efried has quit IRC | 18:12 | |
| kmalloc | and some limited cases of "not owned" | 18:13 |
| kmalloc | ideally a system scope would be used to create the public images | 18:13 |
| kmalloc | and the public networks (long term) | 18:13 |
| kmalloc | if it's owned by a user it should be limited to being manipulated/looked at by the user or the system-level (root) type admin | 18:14 |
| gyee | take nova for example, who *owns* a given VM/server? project isn't it? | 18:16 |
| kmalloc | right | 18:18 |
| kmalloc | that is a project ownership | 18:18 |
| *** efried has joined #openstack-keystone | 18:21 | |
| gyee | and who owns projects? | 18:24 |
| *** jamesmcarthur has quit IRC | 18:24 | |
| cmurphy | system and domain users can do things with projects | 18:28 |
| gyee | users or admins? | 18:33 |
| cmurphy | both, domain readers for example can list projects in their domain | 18:33 |
| gyee | cmurphy, would be nice to have a session on openstack resource ownership if we haven't done one already :-) | 18:35 |
| cmurphy | gyee: 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/547850 | 18:41 |
| *** jamesmcarthur has joined #openstack-keystone | 18:42 | |
| *** jamesmcarthur has quit IRC | 18:51 | |
| *** jamesmcarthur has joined #openstack-keystone | 18:52 | |
| *** jamesmcarthur_ has joined #openstack-keystone | 18:53 | |
| *** jamesmcarthur_ has quit IRC | 18:54 | |
| *** jamesmcarthur has quit IRC | 18:57 | |
| *** jamesmcarthur has joined #openstack-keystone | 18:58 | |
| *** jamesmcarthur_ has joined #openstack-keystone | 18:59 | |
| *** jamesmcarthur has quit IRC | 19:03 | |
| *** jamesmcarthur_ has quit IRC | 19:04 | |
| *** jamesmcarthur has joined #openstack-keystone | 19:05 | |
| *** jamesmcarthur_ has joined #openstack-keystone | 19:06 | |
| *** jamesmcarthur has quit IRC | 19:10 | |
| *** jamesmcarthur_ has quit IRC | 19:25 | |
| *** jamesmcarthur has joined #openstack-keystone | 19:28 | |
| *** jamesmcarthur_ has joined #openstack-keystone | 19:29 | |
| *** vishakha has quit IRC | 19:30 | |
| openstackgerrit | Kristi Nikolla proposed openstack/keystone master: Deprecate [federation] federated_domain_name https://review.opendev.org/651614 | 19:31 |
| *** jamesmcarthur_ has quit IRC | 19:32 | |
| *** jamesmcarthur_ has joined #openstack-keystone | 19:33 | |
| *** jamesmcarthur has quit IRC | 19:33 | |
| *** jamesmcarthur has joined #openstack-keystone | 19:34 | |
| *** jamesmcarthur_ has quit IRC | 19:37 | |
| *** jamesmcarthur has quit IRC | 19:53 | |
| *** jamesmcarthur has joined #openstack-keystone | 19:53 | |
| *** jamesmcarthur_ has joined #openstack-keystone | 19:54 | |
| *** jamesmcarthur has quit IRC | 19:58 | |
| *** kplant has quit IRC | 19:59 | |
| *** dasp has quit IRC | 20:45 | |
| *** jamesmcarthur_ has quit IRC | 20:45 | |
| *** dasp has joined #openstack-keystone | 20:47 | |
| *** pcaruana has quit IRC | 21:01 | |
| *** raildo has quit IRC | 21:04 | |
| openstackgerrit | Hervé Beraud proposed openstack/oslo.policy master: Add unit tests on cache handler https://review.opendev.org/671113 | 21:14 |
| openstackgerrit | Hervé Beraud proposed openstack/oslo.policy master: Correctly handle IO errors at policy file load https://review.opendev.org/670571 | 21:16 |
| *** xek has quit IRC | 22:02 | |
| *** whoami-rajat has quit IRC | 22:31 | |
| *** rcernin has joined #openstack-keystone | 22:36 | |
| openstackgerrit | Merged openstack/oslo.limit master: Add Python 3 Train unit tests https://review.opendev.org/669461 | 22:38 |
| *** tkajinam has joined #openstack-keystone | 22:53 | |
| *** vishalmanchanda has quit IRC | 23:05 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!