17:07:10 #startmeeting keystone-office-hours 17:07:11 Meeting started Tue Jul 31 17:07:10 2018 UTC and is due to finish in 60 minutes. The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:07:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:07:14 The meeting name has been set to 'keystone_office_hours' 17:09:55 lbragstad: no, there is no default policy set 17:16:02 abhi89: so - you don't have that policy listed in your policy.json but you can still access it? 17:17:12 lbragstad: is there a policy rule for GET /v3/OS-FEDERATION/projects.. i didnot find any.. https://docs.openstack.org/keystone/queens/configuration/policy.html 17:17:29 lbragstad: yes, no policy set for that api, but still i can access it 17:19:09 Morgan Fainberg proposed openstack/keystone master: Break dependencies on auth.controllers https://review.openstack.org/585519 17:19:53 lbragstad: we are also not using federation at all 17:20:11 Morgan Fainberg proposed openstack/keystone master: Move unenforced_api decorator to module function https://review.openstack.org/585869 17:20:17 Morgan Fainberg proposed openstack/keystone master: Address FIXMEs for listing revoked tokens https://review.openstack.org/545009 17:20:22 Morgan Fainberg proposed openstack/keystone master: Cleanup last of tests leaning on auth controllers https://review.openstack.org/586306 17:21:24 abhi89: ah - yeah.. sorry 17:21:28 i think it's protected by https://github.com/openstack/keystone/blob/master/keystone/common/policies/user.py#L54 17:22:35 lbragstad: yes 17:22:42 i see what you're saying now 17:23:07 you're correct - the description was misleading 17:23:29 lbragstad: yep, that is what i guessed was the issue 17:25:13 checking with prometheanfire to see if there is a way to update those descriptions after disclosure 17:25:30 lbragstad: ok.. 17:25:39 hello all, I know the policy.json is now not showing in the /etc/keystone/policy.json file.. what's the best way to get that extracted so I can create a new role. Thanks 17:26:05 itlinux: oslo.policy exposes some tooling to generate sample policy files 17:26:55 itlinux: https://docs.openstack.org/oslo.policy/latest/cli/index.html#oslopolicy-sample-generator 17:27:41 thanks lbragstad 17:28:00 yep 17:30:05 so if I oslopolicy-sample-generator --namespace keystone it extracts what's in use now and I can then add/modify it and place it in the /etc/keystone and it will automatically be used.. That's my understanding correct me if I am wrong. @lbragstad 17:34:43 haven't tried it with keystone, but with nova (at least), you can define new policies in an otherwise-empty policy.json, and they get merged with the defaults 17:39:48 itlinux: you can use it to generate a sample based on the defaults in code 17:40:03 or your can use it to generate a policy file including the overrides you have already on disk 17:40:26 the use case for the later is for horizon or supplying an auditor with a copy of your policy.json 17:41:58 oslopolicy-policy-generator generates a complete policy file that includes any overrides you supply via an existing policy file and default policies 17:42:47 oslopolicy-sample-generator just gives you a sample policy file with the default we maintain in keystone's source (it doesn't take any of your overrides into consideration, if you have any) 17:57:10 ok.. so basically I could just create a new policy role and does not affect the others.. and save it in /etc/keystone/policy.json and /etc/openstack-dashbaord .. 17:57:19 lbargstad: 17:57:39 bragstad: 17:57:41 thanks for your tips.. 18:01:44 the file I gen.. does not show the ResellerAdmin stuff.. can you let me know what's the best to show what's actually the policy now lbagstad: thanks 21:48:37 #endmeeting