Friday, 2023-05-05

ozzzo_workI got the policy generator working. My policy file looks like this: https://paste.openstack.org/show/bEqkfG4NVjt9QgJvi5Sd/15:04
ozzzo_workWhen I run the policy generator in the designate_worker container I get this, which appears to indicate that my new policies are active: https://paste.openstack.org/show/ba771pGfjIPq6g7dtdeJ/15:05
ozzzo_workbut, when I run DNS commands as a user with the "dnsread" role, I don't get anything: https://paste.openstack.org/show/bEhYfbI8Nvr3Ls3XOFKt/15:05
ozzzo_workDo I need to change policies anywhere else? Keystone?15:06
johnsomozzzo_work A few comments:15:56
johnsomAlmost all policy validation happens in the designate-central process, so I would focus there as opposed to worker.15:57
johnsomI see a alias of role dnsread to dns, but this doesn't include a snippet of the endpoint rule that will need to be updated as well.15:58
johnsomhttps://github.com/openstack/designate/blob/master/designate/common/policies/recordset.py#L16016:00
johnsomAlso, I don't fully remember what you are trying to accomplish, but you may need to take into account the project ID modifiers, i.e. all-projects or sudo-project-id to veiw cross project information.16:00
ozzzo_workI'm trying to allow a user to view DNS records for networks owned by admin16:13
ozzzo_workIn my policy output I don't see anything for find_recordset. I only find get_recordsets, get_recordset, create_recordset, update_recordset, delete_recordset and count_recordset16:15
ozzzo_workDo I need to add a line for find_recordset?16:15
johnsomIt's called: find_recordsets16:16
ozzzo_workok I'll try adding that16:17
johnsomIt should already be there16:17
johnsomWhat version are you one?16:18
johnsomon16:18
ozzzo_workTrain16:19
ozzzo_workneither default nor active policies include find_recordset nor find_recordsets16:19
johnsomUgh, so older than my experience on the project. Give me a minute to dig into what was there back at train16:20
johnsomhttps://github.com/openstack/designate/blob/train-eol/designate/common/policies/recordset.py#L3616:20
johnsomSo there is the default rule16:20
johnsomI guess the changed the policy names somewhere along the way16:20
johnsomOye, yeah, train is a mess. Give me a few more16:23
johnsomSure enough, no train that is an undefined rule, so will fall back to the default16:25
johnsomWhich is owner-admin, which is fine. Ok, let's see.16:26
ozzzo_workI think I need it to be "admin_or_owner_or_dns"16:31
johnsomI'm not sure you are going to be able to accomplish this without giving users in that role pretty wide access to the admin account resources16:31
johnsomThe thing is, even with that type of rule, the project_id it will search with will be the users project ID16:32
johnsomfrom the context object16:32
johnsomDo you have a dev setup or lab you can experiment with? I don't have a setup I can run train on right now.16:33
ozzzo_workyes I'm working on this in the lab16:33
ozzzo_workDo I need to allow "all_tenants"?16:34
johnsomThat would give access to every projects resources across all of the objects. You may want something to do with the sudo header16:35
johnsomIs it ok if the user is required to add a special flag/header?16:35
ozzzo_workyes I think that can work16:36
johnsomOk, one minute16:37
johnsomSo, you are going to override this rule in your policy.yaml:16:39
johnsomhttps://github.com/openstack/designate/blob/train-eol/designate/common/policies/context.py#L3616:39
johnsomIt's currently defined as role:admin or is_admin:True16:39
johnsomObviously copy the "admin" rule to a new name you will use with the use_sudo policy16:40
johnsomyou will add an or clause here, something like "role:admin or is_admin:True or (role:dnsreader and tenant:<admin tenant ID here>"16:41
johnsomThat will allow users in that role to do ANY action as the admin project ID.16:42
johnsomI am wondering if we can restrict it down farther using the resource_uuid in the context. Not sure on this though16:43
johnsomhttps://github.com/openstack/oslo.context/blob/master/oslo_context/context.py#L20216:43
johnsomTo see if that field is useful or not, I would add debug log above here:16:43
johnsomhttps://github.com/openstack/designate/blob/train-eol/designate/central/service.py#L137916:43
johnsomThat prints the context.to_dict() out, restart central, then make the find recordsets call16:44
johnsomSee if it has a resource uuid that would limit it to a specific zone or endpoint.16:44
johnsomOtherwise, you would need to modify every other endpoint (maybe by modifying the owner-admin rule) to explicitly not all dnsreader on them when use_sudo is true16:45
johnsomendpoint->endpoint rule16:45
johnsomall->allow 16:46
johnsomugh, sorry, I have a head cold16:46
johnsomDoes that make sense?16:46
ozzzo_workok I'll experiment with that. Do I need to add a special flag when I call get_records after making the change?16:47
johnsomYes, it will be x-auth-sudo-project-id header or command line flag16:48
johnsomspecifying the admin project ID you want to list in16:48
ozzzo_workok16:49
ozzzo_workjohnsom: That seems to work. After adding that rule I can list project IDs with my "dns" user. How can I find a list of commands that allow --sudo-project-id?18:33
johnsomozzzo_work Pretty much all of them do. The API reference will call that out: https://docs.openstack.org/api-ref/dns/dns-api-v2-index.html19:07
ozzzo_workIt looks like the perms only apply to the ones that I explicitly allow. If I try one that I didn't allow, for example: os recordset delete <zone> <record> --sudo-project-id <ID> --edit-managed, I get "Forbidden"22:43

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!