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

Question

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?

Muntasir · Answer

Direct Answer
Yes—if the goal is to eliminate accidental public exposure, restrict floating IP creation and association to administrators. Yes—oslo.policy can block non-admin floating IP actions while leaving tenant internal networking untouched.

Why Default Security Groups Alone Are Insufficient
Neutron security groups default to deny-ingress, but that firewall is enforced at the port level and remains under tenant control. A project member can create a permissive rule such as 0.0.0.0/0 and attach it to an instance. The floating IP is the actual public entry point; without it, an instance on a tenant network is unreachable from the internet regardless of security group contents.

Implementing Admin-Controlled Floating IPs
Authorization in Neutron is driven by oslo.policy. On the neutron-server, edit policy.yaml (or policy.json on older releases) to scope the floating IP API calls:
"floatingip:create": "role:admin",
"floatingip:associate": "role:admin"
Tenants retain the ability to create networks, ports, routers, and security groups for internal use. Only the north-south bridge is gated behind administrative approval.

Verification and Version Considerations
This guidance assumes a standard OpenStack deployment with Neutron ML2 and policy defined in policy.yaml. After changing the policy file, restart neutron-server so the rules are reloaded. To verify, attempt openstack floating ip create as a non-admin tenant user; the API should return 403 Forbidden. Then confirm that East-West traffic between instances on the same tenant network still succeeds.

One Diagnostic Detail That Changes the Recommendation
Floating IP restrictions do not prevent exposure when a tenant port is attached directly to a provider network that supplies a routable public IP. If your environment uses shared or provider external networks for direct attachment, the policy above is necessary but not sufficient. Are any tenant ports attached directly to provider networks that receive public IPs without floating IPs?

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

1 answer

Direct Answer

Why Default Security Groups Alone Are Insufficient

Implementing Admin-Controlled Floating IPs

Verification and Version Considerations

One Diagnostic Detail That Changes the Recommendation

Your perspective belongs here.

0 question comments