17:00:57 #startmeeting keystone 17:00:58 Meeting started Tue Apr 14 17:00:57 2020 UTC and is due to finish in 60 minutes. The chair is cmurphy. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:59 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:01 The meeting name has been set to 'keystone' 17:01:15 o/ 17:01:27 Deja vu. ;-) 17:01:29 #link https://etherpad.opendev.org/p/keystone-weekly-meeting agenda 17:01:47 someone else tried to start our meeting earlier? o.0 17:02:23 o/ 17:02:24 yes 17:05:12 #topic announcements 17:05:53 feature freeze was last week, we actually got everything in on time without having a ci crisis \o/ 17:06:28 RC1 will be next week, please help test current master and report/fix bugs asap 17:07:01 and please help monitor launchpad for incoming release-critical bugs 17:07:16 +1 17:08:56 #topic l1 duty rotation 17:09:22 o/ 17:09:30 I am on this week bug duty 17:09:58 thanks vishakha 17:10:14 gagehugo: was last week, there's a couple bugs linked on the agenda? 17:10:24 from today yeah 17:10:38 responded to one, might just be a install misconfiguration 17:10:56 other one haven't yet 17:11:07 seems like they need to check their keystone logs 17:11:55 https://bugs.launchpad.net/keystone/+bug/1872732 seems like a reasonable feature request, not release critical though 17:11:55 Launchpad bug 1872732 in OpenStack Identity (keystone) "no user limit of ec2 credentials" [Undecided,New] 17:12:12 i saw https://bugs.launchpad.net/keystone/+bug/1871784 come in this week, anyone looked into that? 17:12:13 Launchpad bug 1871784 in OpenStack Identity (keystone) "create a user use ignore_password_expiry but still has expires_at to db" [Undecided,New] 17:13:41 looking 17:14:15 i'm not entirely sure what they're asking tbh 17:14:42 Im guessing that the password expires at isn't updating when you apply the ignore user option? 17:15:48 but im not sure 17:16:15 someone want to get clarification? 17:17:14 I will update and clarify 17:17:26 thanks vishakha 17:17:58 i'll take next week 17:18:07 #topic review requests 17:18:16 There's one more bug https://bugs.launchpad.net/keystone/+bug/1872753 17:18:16 Launchpad bug 1872753 in OpenStack Identity (keystone) "Updating EC2 credential blob can lead to a ec2 credential id / credential id mismatch" [Undecided,New] 17:18:36 I will try to reproduc 17:18:58 great, thanks vishakha 17:19:36 some review requests from vishakha too 17:19:44 :) 17:20:48 looks like the k2k tempest case is ready https://review.opendev.org/#/c/704271/ 17:20:57 i will take a look at that as well as the doc updates 17:21:37 vishakha: that bug probably wasn't supposed to be public 17:21:53 looks security related 17:21:59 Thanks cmurphy 17:22:55 gagehugo: What is to be done in such case? 17:23:36 Is the keystone ongoing right now? Do i need to type anything to join it? 17:23:46 usually marked as security related, but this one might not be, its looking like it's more leaving orphaned credentials than anything vulnerability related 17:24:02 Nizars: you're in it right now 17:24:07 Thank you 17:24:44 Nizars: generally you don't need to type anything to join meetings, except be on the right channel at the right time 17:24:56 Let me know when I can bring up an issue me and my team are working on. 17:25:16 any other review requests before we move to open floor? 17:26:53 #topic open floor 17:27:00 Nizars: what can we help you with? 17:28:38 Thank you very much. Me and my team, students from Sweden, are working on a horizon plugin for managing role based access management. The blueprint for the project can be found here: https://blueprints.launchpad.net/horizon/+spec/policies-plugin 17:28:54 It is a horizon project but we use Oslo and Keystone. 17:30:06 On a second thought, I think my questions are more appropriate in the Oslo meeting. My apologies. I pass the floor. 17:30:09 Does it support yaml policies? 17:30:37 It's probably appropriate to discuss it here. There are likely more policy-savvy people here than in the Oslo meeting. 17:31:06 We are trying to implement a back end that retrieves effective policies both in the code and in file. reading from yaml files is to be implemented but it reads json files. 17:32:34 My initial reaction is that I wouldn't recommend writing a completely one-off tool for this. 17:32:45 There's quite a lot of subtle behaviors in oslo.policy that would be hard to keep in sync. 17:32:54 The problem is that the process of retrieving policies is heavy. It requests all the policies, writes them to a file, then our client loops through the file line by line to find the matching target, instantiates a model and compliments its document fields such as scopes and operations from a local dict and then sends it to the front end. 17:33:48 I feel that creating the whole operation ourselves would be better as long as we can create the checks to insure that the user provided rule is acceptable. 17:34:23 We are trying to look into what those checks are and what they do so that we ensure that they are correct. 17:35:25 Another thing that I noticed is that there are style inconsistencies in how the Operations values for policies are written. So we decided to just use our own. 17:35:25 This is probably where I should mention that I started on a policy validator tool: https://review.opendev.org/#/c/702757/ 17:35:40 Thank you so much. I will read up on it. 17:35:50 It would be nice if we could keep as much validation logic common as possible. 17:36:54 I agree, its just that oslo and keystone have been not very easy to work with especially from an api perspective. 17:37:30 here is an example of how some operation fields are provided: `['HEAD', 'GET'] /v3/system/groups/{group_id}/roles` 17:38:15 meanwhile others are provided like this: ```PUT /v3/projects/{project_id}/users/{user_id}/roles/{role_id} PUT /v3/projects/{project_id}/groups/{group_id}/roles/{role_id} PUT /v3/domains/{domain_id}/users/{user_id}/roles/{role_id}``` 17:38:52 I also have a question, some keystone policies don't have a project. what does that mean? are they global? 17:39:16 For example: `admin_required` 17:39:35 it doesn't have 'identity:` before it 17:40:13 compared to something like: `identity:check_endpoint_in_project` 17:40:37 I believe admin_required is internal to the policy. It's not referenced by code, just by other policies. 17:40:45 (but someone correct me if I'm wrong) 17:40:58 I see 17:41:06 This is how the plugin looks like: 17:41:07 https://i.imgur.com/TMxrv9d.gif 17:41:29 We just wrote global when project field is missing for now. 17:43:24 The biggest obstacle right now is just how much work is done by the plugin to retrieve a single policy. Which is the reason why we thought about skipping oslo and keystone and implementing the methods to get the policies ourselves. There is also no direct way for us to check when a new change to policies has been made so we have to keep running that generate method over and over. 17:44:47 I feel like this might be a complex enough discussion that it's going to be hard to resolve within the meeting. 17:44:47 Would you be open to writing up a spec against keystone and/or oslo that explains all of the design goals and the problems you're having? 17:44:59 Our next step is to modify policies, which involves checking for a successful modification. This will require a number of process to be carried out from checking with the enforced, file writing, and retreiving everything again. 17:46:11 * lbragstad is suffering off-by-one errors 17:46:20 Modifying policy through Horizon sounds very problematic to me. You're going to have to essentially build a config management system in the plugin. 17:46:32 And somehow make sure it plays nicely with the operator's existing config management system. 17:46:36 We are willing to do that. 17:46:39 I assume there will be a policy to modify policies in horizon? 17:47:10 @gagehugo I am not sure i follow 17:47:40 For our use case, we do not want users modifying policy, so we would disable this 17:48:01 but that's just my 2 cents, I think I can see where this can be useful 17:48:16 but also my horizon knowledge is quite shallow 17:48:42 Good point. I will check on that to make sure of who can make those changes in the plugin. 17:48:46 Thank you. 17:49:36 agreed with gagehugo, we typically only want cloud operators changing policies and they usually already have access to the files on disk to change them 17:49:53 but i can imagine having something to help visualizing them could be helpful in some cases 17:49:59 One thing the team has had an issue with was when the policy.json was deleted after creation (for testing) they got locked out of Horizon and had to roll back the server. 17:50:26 also we deploy with read-only fs in most cases, so writing files will not be possible for the most part 17:51:04 just one use case here though 17:51:17 yeah this wouldn't work with most containerized deployments 17:51:48 cmurphy: without some modification yeah 17:51:50 Yeah the project aims to simplify the process for those who would need to work on the policies. create back ups, restores, provide a json/yaml text editor with tools tips, auto complete, quick actions and so on. It isn't really made for everyone to work with but I will add those points and raise them in our next meeting. 17:52:16 I can see where this would be kinda useful for policy testing 17:52:25 which is lacking for us currently 17:53:15 The goal is to be done by 31st of may but we have june to working on it. I plan to stay active on it after that. 17:53:26 Nizars: thanks for sharing, it's a really interesting idea 17:53:47 I am finally glad I am getting some communication on the irc channels. 17:53:53 like bnemec said we'd recommend trying to reuse as much of oslo.policy as you can for validation rather than reimplement a new thing 17:53:54 THank you 17:54:11 Nizars: if you need any more help you can reach us in #openstack-keystone or #openstack-oslo you don't need to wait for a meeting 17:54:35 I will look into it and prepare a document describing the problems we have for the next time we meet. 17:55:12 sounds good 17:55:31 Cool, I know this sort of functionality is something that has been discussed quite a bit in the past too. 17:55:31 Final quick questions. How do we get the blueprint approved and how/when do we move the code to gerrit? it is currently on my private github. 17:55:46 https://github.com/nizos/horizon-policies-plugin 17:56:05 you'll have to talk to the horizon team about that 17:56:11 This is the wiki page for our project: 17:56:12 https://wiki.nordix.org/display/RE/OpenStack+Policies 17:56:19 Ok, thank you! 17:57:31 any other topics for open floor? 17:59:30 okay thanks everyone 17:59:33 #endmeeting