Neutron Default Deny Security Groups vs Admin-Controlled Floating IP Delegation

The objective is to prevent accidental public internet exposure of tenant instances in an OpenStack environment.

One strategy relies on Neutron's default deny-ingress security groups. While this provides a stateful safety net, it does not prevent a user from associating a floating IP or creating a permissive 0.0.0.0/0 rule, which would override the default posture.

An alternative strategy involves strict administrative control over external networks and floating IP policies. By limiting the access_as_external RBAC permission and restricting create_floatingip via oslo.policy, the cloud provider can structurally prevent tenants from exposing ports without manual approval.

The trade-off lies between tenant self-service flexibility and the risk of accidental exposure through delegated RBAC permissions.

• Should the deployment enforce admin-only floating IP creation to eliminate the risk of accidental exposure?
• Is it possible to define a policy that blocks non-admin users from associating floating IPs while still allowing them to manage internal networking?