ozzzo_work | I got the policy generator working. My policy file looks like this: https://paste.openstack.org/show/bEqkfG4NVjt9QgJvi5Sd/ | 15:04 |
---|---|---|
ozzzo_work | When 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_work | but, 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_work | Do I need to change policies anywhere else? Keystone? | 15:06 |
johnsom | ozzzo_work A few comments: | 15:56 |
johnsom | Almost all policy validation happens in the designate-central process, so I would focus there as opposed to worker. | 15:57 |
johnsom | I 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 |
johnsom | https://github.com/openstack/designate/blob/master/designate/common/policies/recordset.py#L160 | 16:00 |
johnsom | Also, 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_work | I'm trying to allow a user to view DNS records for networks owned by admin | 16:13 |
ozzzo_work | In 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_recordset | 16:15 |
ozzzo_work | Do I need to add a line for find_recordset? | 16:15 |
johnsom | It's called: find_recordsets | 16:16 |
ozzzo_work | ok I'll try adding that | 16:17 |
johnsom | It should already be there | 16:17 |
johnsom | What version are you one? | 16:18 |
johnsom | on | 16:18 |
ozzzo_work | Train | 16:19 |
ozzzo_work | neither default nor active policies include find_recordset nor find_recordsets | 16:19 |
johnsom | Ugh, so older than my experience on the project. Give me a minute to dig into what was there back at train | 16:20 |
johnsom | https://github.com/openstack/designate/blob/train-eol/designate/common/policies/recordset.py#L36 | 16:20 |
johnsom | So there is the default rule | 16:20 |
johnsom | I guess the changed the policy names somewhere along the way | 16:20 |
johnsom | Oye, yeah, train is a mess. Give me a few more | 16:23 |
johnsom | Sure enough, no train that is an undefined rule, so will fall back to the default | 16:25 |
johnsom | Which is owner-admin, which is fine. Ok, let's see. | 16:26 |
ozzzo_work | I think I need it to be "admin_or_owner_or_dns" | 16:31 |
johnsom | I'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 resources | 16:31 |
johnsom | The thing is, even with that type of rule, the project_id it will search with will be the users project ID | 16:32 |
johnsom | from the context object | 16:32 |
johnsom | Do 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_work | yes I'm working on this in the lab | 16:33 |
ozzzo_work | Do I need to allow "all_tenants"? | 16:34 |
johnsom | That would give access to every projects resources across all of the objects. You may want something to do with the sudo header | 16:35 |
johnsom | Is it ok if the user is required to add a special flag/header? | 16:35 |
ozzzo_work | yes I think that can work | 16:36 |
johnsom | Ok, one minute | 16:37 |
johnsom | So, you are going to override this rule in your policy.yaml: | 16:39 |
johnsom | https://github.com/openstack/designate/blob/train-eol/designate/common/policies/context.py#L36 | 16:39 |
johnsom | It's currently defined as role:admin or is_admin:True | 16:39 |
johnsom | Obviously copy the "admin" rule to a new name you will use with the use_sudo policy | 16:40 |
johnsom | you 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 |
johnsom | That will allow users in that role to do ANY action as the admin project ID. | 16:42 |
johnsom | I am wondering if we can restrict it down farther using the resource_uuid in the context. Not sure on this though | 16:43 |
johnsom | https://github.com/openstack/oslo.context/blob/master/oslo_context/context.py#L202 | 16:43 |
johnsom | To see if that field is useful or not, I would add debug log above here: | 16:43 |
johnsom | https://github.com/openstack/designate/blob/train-eol/designate/central/service.py#L1379 | 16:43 |
johnsom | That prints the context.to_dict() out, restart central, then make the find recordsets call | 16:44 |
johnsom | See if it has a resource uuid that would limit it to a specific zone or endpoint. | 16:44 |
johnsom | Otherwise, 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 true | 16:45 |
johnsom | endpoint->endpoint rule | 16:45 |
johnsom | all->allow | 16:46 |
johnsom | ugh, sorry, I have a head cold | 16:46 |
johnsom | Does that make sense? | 16:46 |
ozzzo_work | ok I'll experiment with that. Do I need to add a special flag when I call get_records after making the change? | 16:47 |
johnsom | Yes, it will be x-auth-sudo-project-id header or command line flag | 16:48 |
johnsom | specifying the admin project ID you want to list in | 16:48 |
ozzzo_work | ok | 16:49 |
ozzzo_work | johnsom: 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 |
johnsom | ozzzo_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.html | 19:07 |
ozzzo_work | It 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/!