| *** dviroel|rover|afk is now known as dviroel|out | 00:16 | |
| *** dviroel|out is now known as dviroel|rover | 11:09 | |
| *** dasm|off is now known as dasm | 12:04 | |
| nitesh1 | Hi All, I've a query on Openstack keyston LDAP intergration. Can some one help me on this ? | 12:44 |
|---|---|---|
| nitesh1 | I've a installed Openstack and LDAP1 on server1. I've LDAP2 on server2. Can i integrate both LDAP1 and LDAP2 for the Openstack keystone backend | 12:45 |
| nitesh1 | Hi All, I've a query on Openstack LDAP intergration. Can some one help me on this ? I've a installed Openstack and LDAP1 on server1. I've LDAP2 on server2. Can i integrate both LDAP1 and LDAP2 for the Openstack keystone backend ? | 13:18 |
| admiyo | key | 14:57 |
| admiyo | key | 14:57 |
| admiyo | key | 14:57 |
| admiyo | KEYSTONE! | 14:57 |
| dmendiza[m] | #startmeeting keystone | 15:02 |
| opendevmeet | Meeting started Tue Apr 26 15:02:15 2022 UTC and is due to finish in 60 minutes. The chair is dmendiza[m]. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:02 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:02 |
| opendevmeet | The meeting name has been set to 'keystone' | 15:02 |
| knikolla | o/ | 15:02 |
| admiyo | O/ | 15:02 |
| h-asahina | o/ | 15:02 |
| dmendiza[m] | #topic Roll Call | 15:02 |
| dmendiza[m] | Hi everyone! | 15:03 |
| knikolla | long time no see admiyo :) | 15:03 |
| dmendiza[m] | Doing double duty right now, as I am listening in on the poicy popup meeting | 15:03 |
| admiyo | poicy! | 15:03 |
| admiyo | Heyo. Just popped in to see whazzup | 15:03 |
| knikolla | there's a policy popup meeting? | 15:04 |
| dmendiza[m] | yeah | 15:04 |
| dmendiza[m] | #link https://meetpad.opendev.org/secure-rbac | 15:04 |
| dmendiza[m] | started at 1430 UTC | 15:04 |
| dmendiza[m] | Courtesy ping for https://meetpad.opendev.org/secure-rbac | 15:04 |
| dmendiza[m] | oops | 15:04 |
| dmendiza[m] | Courtesy ping for admiyo, bbobrov, crisloma, d34dh0r53, dpar, dstanek, hrybacki, knikolla, lbragstad, lwanderley, kmalloc, rodrigods, samueldmq, ruan_he, wxy, sonuk, vishakha, Ajay, rafaelwe | 15:05 |
| admiyo | A topic near and dear to my heart | 15:05 |
| *** lbragstad8 is now known as lbragstad | 15:05 | |
| admiyo | would be better if I could hear in the secure RBAC meeting... | 15:05 |
| dmendiza[m] | We can listenin in and postpone this until the policy meeting wraps up. | 15:07 |
| admiyo | I can't hear anything there. | 15:09 |
| dmendiza[m] | admiyo: Firefox? | 15:09 |
| knikolla | i don't think there has been one time using meetpad/jitsi that everyone could hear everyone | 15:10 |
| dmendiza[m] | Yeah, I've had issues with Firefox and Jitsi quite a bit | 15:12 |
| alistarle | Hi, is there any Keystone meeting currently in progress ? | 15:15 |
| admiyo | derailed atm | 15:15 |
| dmendiza[m] | yeah, we're listening in on the Policy meeting in Meetpad | 15:16 |
| dmendiza[m] | We'll resume the keystone meeting shortly | 15:17 |
| dmendiza[m] | OK, resuming | 15:21 |
| admiyo | All done there | 15:21 |
| dmendiza[m] | #topic Review Past Meeting Action Items | 15:21 |
| dmendiza[m] | > dmendiza[m] to look into updating the keystone-stable-maint group | 15:21 |
| dmendiza[m] | I did not do this yet, but I will do it this week for sure | 15:21 |
| dmendiza[m] | I'll remove anyone who has not reviewed anything in the last 90 days. | 15:21 |
| dmendiza[m] | Then notify the ML | 15:21 |
| dmendiza[m] | oh oops | 15:22 |
| dmendiza[m] | I meant that for this: | 15:22 |
| dmendiza[m] | > dmendiza[m] to clean up core reviewers group, notify ML | 15:22 |
| dmendiza[m] | but I also am not on the maintenance team yet | 15:22 |
| dmendiza[m] | so I need to sort that hout | 15:22 |
| dmendiza[m] | *that out | 15:22 |
| dmendiza[m] | > dmendiza[m] to set up a doodle poll to review OAuth 2.0 patches | 15:22 |
| dmendiza[m] | and lastly, h_asahina helped out with this | 15:23 |
| *** xek_ is now known as xek | 15:23 | |
| admiyo | so...I have not, and it is because the only things I've been notified about are already broken. Is there really so little activity these days? | 15:23 |
| knikolla | pretty much | 15:23 |
| dmendiza[m] | Yeah, pretty low activity so far | 15:23 |
| admiyo | ok | 15:23 |
| dmendiza[m] | We definitely need help with bugsquashing though | 15:23 |
| admiyo | I mean, I'm not a core reviewer anymore, so no risk to me | 15:24 |
| dmendiza[m] | We definitely want your input on reviews | 15:25 |
| admiyo | would help if you could build keystone...but we'll get to that in the agenda | 15:25 |
| dmendiza[m] | #link https://doodle.com/meeting/participate/id/b68Yl49e/vote | 15:26 |
| dmendiza[m] | ^^^ this is the doodle that h_asahina set up for us | 15:26 |
| dmendiza[m] | looking like Thursday might be the best day for me | 15:26 |
| dmendiza[m] | knikolla you probably haven't had a chance to find it in your email | 15:27 |
| dmendiza[m] | but it would be good if we could get together on Thursday... if not we may need to kick to next week | 15:27 |
| h-asahina | Yes. If you all not are not avalable this week, I'll create the doodle pool again. | 15:28 |
| knikolla | filled out the doodle, thanks! | 15:28 |
| dmendiza[m] | admiyo: how's your OAuth chops? | 15:28 |
| h-asahina | thanks! knikolla: | 15:28 |
| admiyo | Not bad | 15:28 |
| admiyo | Are we looking to replace Keystone tokens with OAuth2? | 15:29 |
| knikolla | we sort of already have, keystone supports jwt tokens | 15:29 |
| knikolla | but not the oauth 2.0 api to emit and validate them | 15:29 |
| admiyo | So we can get reid of keystone altogether | 15:29 |
| admiyo | :) | 15:30 |
| dmendiza[m] | Doodle is for reviewing https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext | 15:30 |
| knikolla | get rid of keystone???? i want it to be the center of the world and support all oauth 2.0 and openid connect clients, mwhahahaha | 15:30 |
| admiyo | keystonemiddleware suports jwt? | 15:30 |
| knikolla | https://specs.openstack.org/openstack/keystone-specs/specs/keystone/stein/json-web-tokens.html | 15:31 |
| admiyo | If keystonemiddleware can handle JWT, can we have it talk to a source otherthan keystone? | 15:33 |
| admiyo | I realize there is all the service catalog implied in the token validation call, ignore that for a moment | 15:33 |
| admiyo | if a company already has oauth2.0 set up, could they use that to validate when talking to openstack services? | 15:34 |
| knikolla | the latter, the nfv clients depend on oauth 2.0 | 15:34 |
| knikolla | so we're enabling that, and allowing oauth 2.0 clients to talk to openstack services. | 15:35 |
| knikolla | getting openstack services to use a different authorization servers is a very far stretch goal that isn't an immediate priority. | 15:36 |
| dmendiza[m] | OK, I've responded to the doodle as well | 15:37 |
| dmendiza[m] | OK, let's keep it moving since we're on a crunch today | 15:38 |
| h-asahina | thanks, dmendiza: looks Thu 9:00 am would be better. | 15:38 |
| dmendiza[m] | #topic Security RBAC | 15:38 |
| admiyo | I am trying to understand what the actual priority is here; I assume keystonemiddleware based servers still need to call to Keystone for JWT validation | 15:38 |
| h-asahina | BTW, we submitted BP for keystonemidleware to communicate with an external authorization server: https://blueprints.launchpad.net/keystone/+spec/enhance-oauth2-interoperability | 15:39 |
| knikolla | admiyo: https://specs.openstack.org/openstack/keystone-specs/specs/keystone/yoga/oauth2-client-credentials-ext.html | 15:39 |
| h-asahina | for admiyo: | 15:39 |
| admiyo | Cool. I'll read up | 15:39 |
| dmendiza[m] | Awesome ... hopefully you can join on Thursday admiyo | 15:40 |
| dmendiza[m] | OK, moving on | 15:40 |
| dmendiza[m] | For SRBAC we did just meet for the Policy Pop-up | 15:40 |
| dmendiza[m] | looks like the next one will be next week | 15:40 |
| dmendiza[m] | at 1400 UTC, so hopefully it won't bleed into our meeting again. | 15:40 |
| dmendiza[m] | Hopefully we'll get to a decision re: Heat, but also about the "service" role | 15:41 |
| admiyo | dmendiza[m], did my little speech there at the end make any sense? I can try to summarize | 15:41 |
| dmendiza[m] | Sure, go ahead | 15:41 |
| admiyo | OK....lets assume for a second that we have no clue about what goes on in our customer organizations | 15:41 |
| dmendiza[m] | that's not hard | 15:42 |
| admiyo | instead of trying to force roles on them, lets assume that, at a start, they already have something | 15:42 |
| admiyo | what we need to do it to map workflows to roles | 15:42 |
| admiyo | a workflow is a set of API calls | 15:42 |
| admiyo | and, possible more granular than that, but lets not quibble just yet | 15:42 |
| admiyo | so there is a 3 tier architecture: role->workflow->resource | 15:43 |
| admiyo | if you lock role->resource, you cannot let end users modify things properly | 15:43 |
| admiyo | so, we take every API and give it its own role...(stick with me here) | 15:43 |
| knikolla | https://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/capabilities-app-creds.html | 15:43 |
| admiyo | and use the role assignement inference rules | 15:44 |
| knikolla | we already support restricting access to a set of api calls for a client | 15:44 |
| admiyo | yeah, but not of breaking the API apart | 15:44 |
| admiyo | thats only for app creds, not for end users | 15:45 |
| admiyo | can app creds be re-delegated? | 15:46 |
| admiyo | and re-broken down into finer grained things? | 15:46 |
| knikolla | no | 15:46 |
| admiyo | ok, so that capaiblity should move up the stack | 15:46 |
| admiyo | we had a spec long ago about unified delegation, uising the sdame mechnism for role assignm,ents, trusts, an app-creds | 15:46 |
| admiyo | if each "access-rule" in app creds are treated like a role, we can build them up to workflows, etc | 15:47 |
| admiyo | we have most of the pieces we need already | 15:47 |
| admiyo | do app-creds have wildcards? | 15:47 |
| admiyo | they do, right? | 15:48 |
| knikolla | yeah | 15:48 |
| admiyo | so an app cred is kinda the abstraction we need. Trust do this, too, but app-creds gets down to the URL, which is really what we need | 15:48 |
| admiyo | so...if we can unify the concept of access rule and role, we have a very flexible RBAC structure | 15:49 |
| admiyo | so, then we use inference rules (already implemented) to go admin->reader->{ | 15:49 |
| admiyo | "path": "/v2.0/metrics", | 15:49 |
| admiyo | "method": "GET" | 15:49 |
| admiyo | }, | 15:49 |
| admiyo | where -> means "implies" | 15:50 |
| admiyo | the issue, of course, is that RBAC is enforced at the end service side. | 15:50 |
| admiyo | So they check "role == admin" as opposed to "token allows GET '/v2.0/metrics' " | 15:51 |
| admiyo | knikolla, am I giving you PTSD flashbacks yet? We presented on this together, right? | 15:51 |
| admiyo | https://www.openstack.org/videos/summits/boston-2017/per-api-role-based-access-control | 15:52 |
| dmendiza[m] | Running low on time, y'all (and I gotta run at the top of the hour) | 15:52 |
| admiyo | OK, one last issue, not related | 15:52 |
| admiyo | I tired to build and run Keystone last night | 15:52 |
| admiyo | ERROR: could not install deps [.[bandit], -chttps://releases.openstack.org/constraints/upper/master, -r/opt/openstack/keystone/test-requirements.txt, .[ldap,memcache,mongodb]]; v = InvocationError("/opt/openstack/keystone/.tox/pep8/bin/python -m pip install '.[bandit]' -chttps://releases.openstack.org/constraints/upper/master -r/opt/openstack/keystone/test-requirements.txt '.[ldap,memcache,mongodb]'", 1) | 15:52 |
| admiyo | brand new clone, Ubuntu 21 and Fedora 35. Same issue | 15:53 |
| dmendiza[m] | via tox or ? | 15:53 |
| admiyo | that was tox pep8 run | 15:53 |
| admiyo | same thing for tox -e py... | 15:53 |
| knikolla | admiyo: yeah, i was looking for the spec | 15:53 |
| dmendiza[m] | gotcha... I can look into it but probably not until Friday | 15:53 |
| admiyo | I think it might be a upper constraint mechanism thing? | 15:54 |
| admiyo | no bandit in https://releases.openstack.org/constraints/upper/master | 15:54 |
| admiyo | Can anyone build/run? This seems like breakage across the board | 15:55 |
| dmendiza[m] | trying tox -e pep8 | 15:56 |
| dmendiza[m] | Well, deps installed for me, but I got an actual pep8 failure | 15:57 |
| dmendiza[m] | looks like it might be a python 3.10 issue on my end | 15:58 |
| dmendiza[m] | admiyo: maybe you're missing some bindeps? | 15:58 |
| dmendiza[m] | All out of time for today.... I'll pin the rest of the topics for next week. | 15:59 |
| dmendiza[m] | Thanks for joining, y'all. | 15:59 |
| dmendiza[m] | #endmeeting | 15:59 |
| opendevmeet | Meeting ended Tue Apr 26 15:59:55 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:59 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-04-26-15.02.html | 15:59 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-04-26-15.02.txt | 15:59 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2022/keystone.2022-04-26-15.02.log.html | 15:59 |
| alistarle | Hey folks, I waited the open discussion to ask a question, is it still possible ? | 16:00 |
| admiyo | fire away | 16:01 |
| admiyo | won't be on the log, but people can answer | 16:01 |
| alistarle | It appear that the mapping configuration in federation only setup project in the same domain as the user, but why not giving the ability to give role to project in another domain, like the default one (it is possible for group assignment by example), following this doc: https://docs.openstack.org/keystone/latest/admin/federation/mapping_combinations.html | 16:01 |
| admiyo | alistarle, 2 difference domains | 16:02 |
| alistarle | I can make a patch for that, but I just want to be sure there is no blocker anywhere :) | 16:02 |
| admiyo | user domain is the domain around the username | 16:02 |
| admiyo | project domain is the one you care about here | 16:02 |
| admiyo | use the mapping to put the user into a group | 16:02 |
| alistarle | Exactly | 16:02 |
| alistarle | Yep, in fact a user can be mapped to a group in the default domain, but not on a project in the default domain | 16:02 |
| admiyo | use a group based role assignment | 16:03 |
| alistarle | Yes but group need operator to handle the role assignment by itself, not by the mapping engine | 16:03 |
| admiyo | ? | 16:03 |
| alistarle | Operator will need to give role to the group outside of the federation process | 16:04 |
| admiyo | true | 16:04 |
| alistarle | As if I map a user to a project, I can, directly in the mapping, assign a role to the project | 16:04 |
| alistarle | It is very convenient, but only work if the project is in the same domain as the user | 16:04 |
| admiyo | should not be the case | 16:05 |
| admiyo | "local": [ | 16:05 |
| admiyo | { | 16:05 |
| admiyo | "user": {#first#} | 16:05 |
| admiyo | }, | 16:05 |
| admiyo | { | 16:05 |
| admiyo | "projects": [...] | 16:05 |
| admiyo | }, | 16:05 |
| alistarle | What about allowing to specify the domain of the project, like we do for the domain of the group, directly in the mapping ? | 16:05 |
| admiyo | so project can be by ide, or should accept the domain qualifier | 16:06 |
| alistarle | For group the json is { | 16:06 |
| alistarle | "group": { | 16:06 |
| alistarle | "name": "Finance", | 16:06 |
| alistarle | "domain": { | 16:06 |
| alistarle | "id": "6fe767" | 16:06 |
| alistarle | } | 16:06 |
| alistarle | } | 16:06 |
| alistarle | } | 16:06 |
| alistarle | Yep, I think project should allow the domain qualifer, like the group | 16:06 |
| alistarle | According to this doc at least : https://docs.openstack.org/keystone/latest/admin/federation/mapping_combinations.html | 16:08 |
| *** dviroel|rover is now known as dviroel|rover|lunch | 16:11 | |
| admiyo | alistarle, https://opendev.org/openstack/keystone/src/branch/master/keystone/federation/utils.py#L58 | 16:11 |
| admiyo | I think that is what we have to work with | 16:11 |
| admiyo | does not have a domain qualified on it, and I think I know why | 16:12 |
| admiyo | the mapping really should not be doing role assignments | 16:12 |
| admiyo | its really an adapter for identity providers, which know nothing about roles. Only users and groups of users. Of course, roles really are groups of users (see my earlies implementation LDAP for bugs) | 16:13 |
| admiyo | alistarle, sorry. I'm assuming you are not looking to implement project_domain_name qualifiers in the mapping engine | 16:14 |
| alistarle | Oh I see, but the doc is really oriented about role assignment, and I think it is still a cool feature, to map directly user attributes to roles in openstack | 16:14 |
| admiyo | how are you manaing the mapping files? | 16:15 |
| admiyo | managing | 16:15 |
| alistarle | It can be automated by the Keystone operator I think, and the IDP operator is able to automatically assign role in openstack | 16:16 |
| alistarle | With having to perform more API call | 16:16 |
| alistarle | *Without | 16:16 |
| alistarle | You think it will be a bad idea if a develop a patch to just allow specifying a project_domain_name in the mapping schema ? | 16:17 |
| alistarle | Its only look like an improvement of an already existing feature | 16:17 |
| admiyo | Do you have multiple Idps? "Projects will be created within the domain associated with the Identity Provider." | 16:18 |
| admiyo | you could make the IdP domain the default domain | 16:18 |
| admiyo | do you use multiple domains inside Keystone? | 16:18 |
| alistarle | Yes we provide IDP as a service as a public cloud provider | 16:20 |
| admiyo | So you might not want to make it possible for an IdP provider to map their useres into any an all projects in the Keystone server.... | 16:21 |
| admiyo | hence the limitation to the domain of the IdP | 16:22 |
| admiyo | dmendiza[m], sudo apt install `awk '/dpkg/ {print $1}' bindep.txt ` | 16:22 |
| alistarle | Yes but it should work also in a transitionning state, when old project are still present in default domain | 16:23 |
| admiyo | use groups only for those | 16:23 |
| *** blarnath is now known as d34dh0r53 | 16:23 | |
| alistarle | that's why allowing mapping to give roles on project in default domain make the ability to keep existing local users and federated users to have access to same resources | 16:23 |
| admiyo | default domain should not really be used in multi-domain setups | 16:25 |
| alistarle | Hmm, group is still a lot of orchestration to develop by the operator | 16:25 |
| alistarle | But I see your point | 16:25 |
| admiyo | crossing domain boundaries needs to be managed by RBAC. THere is no RBAC enforcement on the mapping API. So it would be very dangerous | 16:26 |
| alistarle | Maybe I can check what is the size of the patch to support that, and in a worth case support it locally | 16:26 |
| admiyo | I mean, there is at the top level, "can you update the mapping?" but not on the product of the rules | 16:26 |
| alistarle | Yes I agree mapping can be very powerful and dangerous, but it is already the case by giving the admin role even in the same domain | 16:26 |
| admiyo | our goal is to make things less dangerous, not more so | 16:27 |
| admiyo | knikolla, how do I do basic things again? Ubuntu 21 defautls to pytho3.9, but tox does 3.7 and I get ERROR: InterpreterNotFound: python3.7 | 16:28 |
| admiyo | alistarle, I would focus on migrating the projects out of the Default domain. That is something you can do without code changes | 16:29 |
| alistarle | Yeah indeed we achieve that by update the field in the database | 16:29 |
| alistarle | Let's do that then, thank you for your help :) | 16:30 |
| admiyo | Or, conversely, automate the creation of the groups and group role assignments | 16:30 |
| admiyo | that last one would be the least impact for your end users. If you want to say IdP X can always assign to default domain projects, create one group per project (or 2 if you want to distinguish admin from owner) and then mapping goes to those groups | 16:31 |
| admiyo | tox -epy39 "what's the worst that can happen..." | 16:38 |
| admiyo | tox -epy39 ran fine | 17:01 |
| *** dviroel|rover|lunch is now known as dviroel|rover | 17:02 | |
| gmann | dmendiza[m]: need your +1 on this governance patch, https://review.opendev.org/c/openstack/governance/+/838940 | 17:26 |
| dmendiza[m] | gmann: ack, looking | 17:27 |
| gmann | thanks | 17:30 |
| gmann | Added details about next RBAC call on tuesday 3rd May: https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popup_Team#Meeting | 19:01 |
| *** dasm is now known as dasm|off | 21:40 | |
| *** dviroel|rover is now known as dviroel|rover|out | 22:56 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!