Neutron Security Group Rule Precedence and Default Group Isolation

OpenStack Neutron utilizes security groups as stateful virtual firewalls to manage ingress and egress traffic at the port level. While these groups are designed to block all incoming traffic by default, the behavior of the 'default' security group can vary significantly based on the deployment method and the specific OpenStack release.

A critical design constraint is that security group rules are additive, meaning there is no native mechanism to define a specific 'Deny' rule to override a broader 'Allow' rule within the same group. This creates a challenge when attempting to implement a restrictive baseline while allowing specific internal exceptions without risking accidental public exposure if a Floating IP is later attached.

Technical Uncertainties

• How does Neutron resolve conflicts when an instance is associated with multiple security groups that have overlapping but contradictory intent?
• Is there a documented method to enforce a global deny-all override that supersedes the additive nature of individual group rules?