Security groups

The Network service (OpenStack Neutron) implements security groups as stateful packet filters attached to instance ports. Each rule describes allowed traffic by direction (ingress or egress), IP protocol, optional port range, and remote address range in CIDR form (or by reference to another security group). They are the first place you express "who may SSH here" or "this tier may talk to the database on 5432."

Security groups attach rules to each port, so they track the network boundary closest to the workload without requiring a separate hardware firewall per VM.

What security groups do#

They combine into a virtual firewall around NICs. Ingress rules gate inbound connections; egress rules gate outbound. Stateful behavior means that when you allow a flow in one direction, return packets for established connections match the state table and are permitted without mirror micro-rules for ephemeral client ports.

ICMP "echo" for ping, traceroute-related types, and application protocols all use the same rule machinery; if you need ping for debugging, expose it explicitly instead of assuming defaults include it.

New instances typically land in a default security group whose baseline allows inbound from other members of that same group and outbound toward broad destinations. That default supports bootstrapping and traffic between instances in the same group; production systems add explicit ingress from reverse proxies or bastions only, and sometimes constrain egress to required endpoints for compliance.

You can attach multiple groups to one instance so web, admin, and compliance rules compose. One group can also span many instances when you treat a tier as a role.

How rules are evaluated#

Rules are allow lists: traffic must match an explicit permit. OpenStack evaluates security group rules as a set of permits (there is no separate "deny rule" row in the classic model; absence of allow means drop). Direction, protocol, ports, and remote prefixes must align for a packet to pass.

Because evaluation is stateful, short-lived responses to permitted client sessions return even if egress rules are narrower than you might expect for arbitrary UDP or TCP; still validate your egress policy against compliance needs.

Changing policy safely#

Updates apply immediately to every port using that security group, so a broad change can open or close many instances at once. Immediate propagation helps incident response and amplifies mistakes; prefer narrow ranges, change windows, and infrastructure-as-code review for shared groups.

Interaction with ports and floating IPs#

Security groups bind to ports on each NIC. If an instance has multiple NICs, each port can carry a different combination of groups; your database NIC might be far more restricted than a management NIC. Floating IP NAT resolves to the private address first; security groups then evaluate the permitted flows on that instance port.

Practices that keep environments defensible#

Apply least privilege: allow only the protocols and sources you need; default-deny is implicit where no rule matches. Segment by role (web, application, data) so a compromise in one group does not imply carte blanche elsewhere. Audit rules periodically as applications evolve. Pair filters with logging and monitoring (where the platform exposes them) to spot unexpected connection attempts.

Prefer referencing another security group as a source when tiers scale: "application servers may reach the database security group on 5432" stays correct when you add instances without editing CIDRs.

Further reading#

On this platform:

• Create a security group: step-by-step setup via Console, CLI, and API
• Create security group rules: add ingress and egress rules
• Security groups console: console reference for security group management
• Security groups CLI reference: all openstack security group commands

External resources:

• OpenStack Neutron security group documentation: upstream implementation details and admin configuration
• CIS Benchmarks: industry-standard hardening baselines for Linux instances
• NIST SP 800-123: Guide to General Server Security: vendor-neutral firewall and access control principles