Hi, I have been trying to understand what I really want myself here. Basically currently I do have two goals. 1) Floating IP port forwarding can be created by project member 2) Only admin can create ports to network/subnet "public" which is external network. But the network still must be available for reading for different projects than "admin" project. My current policy,yaml create_floatingip_port_forwarding: (role:member) get_floatingip_port_forwarding: (role:member) update_floatingip_port_forwarding: (role:member) delete_floatingip_port_forwarding: (role:member) With this change I can fullfill the first goal. Now member can add port forwarding The second goal I haven't still been able to fullfill. Admin created the public network and subnet. When I login with different account to test project, the member can create a port to public (external) network. If I try next rule: (rule:admin_only) or (role:member and rule:network_owner) The port creation is now disabled but I can not add ports to networks which has been created by my test account to my test project. So basically I just would like to restrict create_port to the public network, but still the project member (test user) could create ports to networks which member has created him/herself. Thanks a lot! On Tue, 12 Mar 2024 at 10:58, Sławek Kapłoński <skaplons@redhat.com> wrote:
Hi,
Hi,
I am currently testing kolla-ansible using the latest release. During
creation of an external/provider network ("public"), I have observed
Dnia sobota, 9 marca 2024 10:05:03 CET Mika Saari pisze: the that a
non-admin project ("test") can view the network and allocate IP addresses for routers, for example. I would like to restrict this behavior so that the external network is listable (openstack network list), but IP allocation is denied.
I have experimented with RBAC rules, creating a new role ("view-only") and assigning it to a user ("user") in the "test" project. I modified the policy.yaml files in both Neutron and Horizon as outlined in the documentation (
https://docs.openstack.org/kolla-ansible/latest/admin/advanced-configuration...
).
Below are the snippets from my neutron/policy.yaml and horizon/neutron_policy.yaml files created following the sample
https://docs.openstack.org/neutron/2023.2/configuration/policy-sample.html
policy.yaml get_network: "(rule:admin_only) or (role:view_only)" get_subnet: "(rule:admin_only) or (role:view_only)" get_port: "(rule:admin_only) or (role:view_only)" get_router: "(rule:admin_only) or (role:view_only)"
neutron_policy.yaml get_network: "(rule:admin_only) or (role:view_only)" get_subnet: "(rule:admin_only) or (role:view_only)" get_port: "(rule:admin_only) or (role:view_only)" get_router: "(rule:admin_only) or (role:view_only)"
After deploying Neutron and Horizon, I adjusted the default RBAC policy
so
that the "External Network" action only affects the "admin" project, not "*". While the admin can still see the public network, the test project user with the "view_only" role cannot see the "public" network. Enabling the RBAC policy for the "test" project allows the network to be visible, but it also enables the member of the project ("user") to reserve IP addresses for network components.
I'm seeking guidance on where to find more information about policies to achieve the desired functionality. Should I redeploy all the services, or is depolying Neutron and Horizon sufficient? Am I on the right track with my policy tests, or is there a simpler way to achieve this functionality?
Thank you very much for your assistance!
I'm not 100% sure what You want to achieve but first of all there is "reader" role and policies for reader role implemented in neutron already. This role allows only to see things like networks but not create anything there. Would it be enough for You? If not, can You maybe share Your whole policy.yaml file from Neutron? I will try to apply it on my dev env and try to check it then.
Also, please not that if You will assign second role for same user, it doesn't mean that previous one will not work at all. Both roles will be assigned to that user so if he has e.g. "member" role still, he will be able to do everything what "member" can do.
-- Slawek Kaplonski Principal Software Engineer Red Hat