Nova instances on Neutron networks: can the default security group be trusted to block accidental public access?

Direct Answers

1. Do not rely solely on the auto-created default security group. While it blocks unsolicited ingress by default (allowing only traffic from other ports in the same group), it is mutable. Any project member can add 0.0.0.0/0 ingress rules, and remote-group references change effective access as membership shifts. Enforce an explicit deny-by-default security group per project and attach it to every instance.
2. Audit at the project level using CLI or API. List permissive ingress rules and ports with port_security_enabled=false across all projects. Automate with a script that iterates projects (requires admin credentials).
3. Yes — treat broad allowed_address_pairs as anti-spoofing bypass. An entry covering 0.0.0.0/0 or a large CIDR (e.g., /8, /16) effectively disables source-IP validation for that port. Flag these during the same audit.

Why the Default Group Is Not a Safe Baseline

The auto-created default group is stateful and allow-only. Its initial rules permit all egress and ingress only from peers in the same group. This blocks public traffic until someone adds a permissive rule — which any project user with the member role can do. There is no built-in cross-project guardrail; Neutron evaluates rules per port, not per cloud.

Operator customizations and OpenStack release differences can alter the default group's initial rules or the default value of port_security_enabled. Some ML2 drivers or plugins (e.g., certain SR-IOV or hardware offload configurations) may ignore security-group rules for specific port types. Verify your deployment's behavior.

Practical Audit Steps (Admin Credentials Required)

1. Enumerate projects:

   openstack project list -f value -c ID

2. For each project, find 0.0.0.0/0 ingress rules:

   openstack security group rule list --project <proj-id> \
     -f value -c remote_ip_prefix | grep '^0\.0\.0\.0/0$'

3. Check port security status on every port:

   openstack port list --project <proj-id> \
     -f value -c id -c port_security_enabled

   Flag any line where the second column is False.
4. Inspect allowed_address_pairs on each port:

   openstack port show <port-id> -f value -c allowed_address_pairs

   Flag entries containing 0.0.0.0/0 or CIDRs larger than /24 (adjust threshold to your policy).

Recommended Baseline Configuration

• Create a project-scoped security group (e.g., deny-all-baseline) with no ingress rules and the default egress rule (allow all).
• Attach this group to every instance/port at boot (via Heat, Terraform, or a default-security-groups Neutron extension if available).
• Enforce port_security_enabled=true on all ports via policy or CI gate.
• Restrict who can create/modify security-group rules (RBAC: limit to a dedicated security-admin role).

Assumptions and Uncertainty

• Assumes a recent OpenStack release (2023.1 "Antelope" or later) with the standard Neutron OVS firewall driver.
• Operator customizations (e.g., firewall_driver set to noop, custom ML2 mechanism drivers) can change enforcement behavior — verify in your environment.
• Floating IPs do not bypass security-group filtering; the SG rules on the instance port remain the enforcement point.

One Diagnostic Detail Needed

What Neutron firewall_driver and ML2 mechanism drivers are configured in your deployment? If you use a non-standard driver (e.g., OVN, SR-IOV with hardware offload, or a vendor plugin), the audit commands above may not reflect actual dataplane behavior.