Re: Network would be shown to a member but IP allocation would be denied?

27 Mar 2024

      Hi,

  Tested the NET_OWNER_MEMBER with the syntax below in my
neutron/policy.conf. "Create Port" disappears for public network but
unfortunately also for networks which my test account has created.

  create_port: "(role: admin) or (rule:network_owner)"

  With rule below I managed to restrict the public network port creation
(The create port button is still shown in Horizon, but port create is not
allowed) and allow the port creation to networks the user has created, but
still the "Launch instance" can reserve IP from the public network. I
assume Launch instance is not using create_port from neutron but something
else? I do not know how to restrict Nova not to create new instance like in
neutron.

  create_port: "rule:admin_or_owner or
rule:project_id:%(network:project_id)s"

  Thanks for help.

On Mon, 25 Mar 2024 at 10:47, Sławek Kapłoński <skaplons@redhat.com> wrote:
...
Hi,
Dnia środa, 20 marca 2024 20:32:07 CET Mika Saari pisze:
...
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.
Please check rule NET_OWNER_MEMBER which is defined in
https://github.com/openstack/neutron/blob/master/neutron/conf/policies/base....
IIUC this should be used by you in the 'create_port' policy.
...
...
Thanks a lot!
...
...
On Tue, 12 Mar 2024 at 10:58, Sławek Kapłoński <skaplons@redhat.com>
wrote:
...
...
...
Hi,
...
...
...
...
Dnia sobota, 9 marca 2024 10:05:03 CET Mika Saari pisze:
...
...
...
Hi,
...
...
...
...
...
...
I am currently testing kolla-ansible using the latest release.
During
...
...
the
...
...
...
creation of an external/provider network ("public"), I have observed
...
...
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
...
--
Slawek Kaplonski
Principal Software Engineer
Red Hat