[RFE] Specifying which floatingip to create should not be a restricted operation

[David Juran]

Hello

In my opinion, the --floating-ip-address option to "neutron floatingip-create" should by default not be restricted to the admin user.

I notice that we now have the option, when creating a floating ip, to specify which IP to create as opposed to only getting a (semi-)random IP from the pool.

netron floatingip-create --floating-ip-address xx.xx.xx.xx external

 Which is very nice. But I also noticed that this option, by default is limited to an admin user. So why is this? If a user really want an IP which is free, he can likely get it by creating and deleting addresses
until the one he wants comes up.

In my opinion, we should therefore relax the default policy, allowing ordinary users to specify which floating IP to use.

[Sreekumar S (sreesiv)]

Does this requirement have genuine scenarios where a normal (non-admin) user is impacted?

[David Juran (djuran)]

Sreekumar: Not sure what you mean. The entire idea here is that a normal (non-admin) user should be able to specify which floting-ip he would like to have from the pool.

[Durga Malleswari Varanasi (durga1)]

I am able to achieve this(creating floatingip as a non-admin user) by replacing the "rule:admin_only" the policy.json ( /etc/neutron/policy.json) file in line 152 by "regular_user".
So that we can change the policy if a non-admin user needs the access to create the floatingip. Could you please confirm if this is the outcome we are looking for in the bug?

[David Juran (djuran)]

Indeed, the outcome I'm looking for is that a normal user should be able to use a command like

netron floatingip-create --floating-ip-address xx.xx.xx.xx external

to specify the floating IP that he wants from the pool

[Durga Malleswari Varanasi (durga1)]

Hi David,

Couple of points which will be required to be highlighted:

1. With the Current Implementation we have the following understanding on the key features of the Floating IP's i.e.:

>> Floating IPs are grabbed by cloud users from the pool configured by the OpenStack "administrator" and then attached to their instances.
Once the user has grabbed a floating IP from the pool, becomes the “owner” of it . If an instance dies for some reason, the user does not lose the floating IP—it remains his own resource
>> Systems administrators can configure multiple floating IP pools. Each user can “grab” a floating IP from whichever floating IP pool he wants.
>> Users can grab floating IPs from different pools defined by the cloud administrator to ensure connectivity to instances from different ISPs or external networks.

Additionally as part of the below feature integration and code implementation we do not have any reason why "Regular users get the privileges to create the Floating-ip's"

https://blueprints.launchpad.net/neutron/+spec/allow-specific-floating-ip-address
https://review.openstack.org/#/c/84915/

2. As part of few of the Bug discussions highlighted below:
https://bugs.launchpad.net/horizon/+bug/1394034
https://bugs.launchpad.net/opencontrail/+bug/1338847

we still could not find any Use case scenario where regular users cannot create floating IPs in the public pool, which Admin can create.

3. Currently with our analysis we have not found or validated any Use case where the Customer is looking for creating the Floating ip's with non-admin specific user so at this point of time we would like to understand if you can help us to know whether changing the behavior of the Specification by giving the capabilities to "regular users" can benefit any specific use case ?

Although we can make the changes in Rules as part of policy.json to additionally handle for the "regular" users but still there is no clarity on the Real time scenario to handle the changes in agreement from the Specification understanding.
So let us know if we can Close the issue until there is any specific Requirement coming to handle this given behavior.

[David Juran (djuran)]

Durga:

I'm sorry, I don't understand your request. Could you please clarify?

[Durga Malleswari Varanasi (durga1)]

Hi David,

As part of the earlier reply : 'Posted 2017-01-31:'
We ave tried to highlight 3 key points ->
1. HoW floating-ip's are grabbed by the Cloud-users and why System Administrators or Openstack Administrators play crucial Role in creating and maintaining those borrowed IP's.

2. With reference to the mentioned bugs :
https://bugs.launchpad.net/horizon/+bug/1394034
https://bugs.launchpad.net/opencontrail/+bug/1338847

we also emphasized the fact that we couldn't identify any specific Use case where there is a requirement for creating / modifying Rules for "non-admin" or "regular-users" to create Floating-ip's.

3. Although we are not denying on making the changes to handle this new-use case specific to "non-admin or regular users" but we have not seen any Specified real-time Use case scenario which got tested with "regular" users (or there are any scenario described as part specs).

Additionally as part of the below feature implementation we do not have any reason why "Regular users get the privileges to create the Floating-ip's" : please go thorough the same

https://blueprints.launchpad.net/neutron/+spec/allow-specific-floating-ip-address
https://review.openstack.org/#/c/84915/

So according to detail analysis and internal discussion with the team we want this Bug to be moved to Wish-list until there comes a real requirement for this specific use-case to be deployed as a new feature.

Let us know if this clarifies your perspective on the above mail response.

[David Juran (djuran)]

The use-case I would like to solve is when a service is bound to an DNS name, in an external DNS over which the user has no control. In this scenario, when the external DNS has bound the DNS name to a specific IP-address, it is valuable to be able to create a floating IP with the specific IP which the service is bound to in the DNS

Further, I see no drawback of opening this capabilities up to regular, non-admin, users.

[Armando Migliaccio (armando-migliaccio)]

Any reason why changing your own policy.json file would not meet your need? The flexibility is there, there is no reason to relax the default behavior, which is more conservative by design.

[David Juran (djuran)]

Changing the policy.json files _would_ solve the problem, this entire RFE is about updating the default in the policy.json, as the current default makes no sense.

[Kevin Benton (kevinbenton)]

We can't adjust the default policy because allowing regular users to specify IP addresses for floating IPs allows them to choose addresses outside of the allocation pools that are set on the subnet.

In order to fulfill your request, we would need to change the way IP allocation works in Neutron to have port requests for a specific IP bounded by the allocation pools to prevent a security regression.

This is the same reason why users can't specify their own IP when attaching to shared networks.

[David Juran (djuran)]

Kevin: Thanks for the clarification, I didn't realize neutron didn't do any checking on whether the requested IP was inside the pool or not.