OpenStack Flex Security Groups Guide

Security Groups in OpenStack Flex are essential tools for managing network access to your virtual machines. Acting as virtual firewalls, they control both inbound and outbound traffic based on defined rules. This guide provides a clear overview of how security groups work, the difference between ingress and egress rules, and how to apply best practices when configuring them. Whether you're new to OpenStack or just need a refresher, this guide will help you understand how to securely manage traffic to and from your instances.

---

How Security Groups Work

• Security Groups are collections of rules.
• Those rules will define:
  • Direction: Ingress (incoming) or Egress (outgoing)
  • Protocol: TCP, UDP, ICMP, etc.
  • Ports: Single port or range
  • Remote: CIDR block or another security group

---

Allow vs Deny

• OpenStack only supports ALLOW rules.
• DENY is implicit — any traffic not explicitly allowed is blocked.
• You cannot write a DENY rule; just don’t include an ALLOW.

---

Ingress vs Egress

• If no egress rules are defined, all outbound traffic is denied.
• Most environments add a default “allow all egress” rule to avoid breaking connectivity.

---

Rule Precedence and Conflicts

• Rules are cumulative, not prioritized.
• There is no precedence or superseding.
• Multiple security groups can be attached to a single port — all rules are combined.
• You cannot create conflicting rules because only ALLOW rules are valid.

---

Example Rule Set

---

Can I Deny a Specific IP?

No. OpenStack Flex security groups do not support explicit DENY rules. To block a specific IP, your options are:

• Restrict the scope of your ALLOW rules.
• Implement more advanced filtering with iptables inside the instance.

---

Private IP Ranges for Internal Networks

Use these private ranges (per RFC 1918) in your OpenStack Flex networks:

Examples

• 10.0.1.0/24 — Dev or tenant network
• 172.16.10.0/24 — Internal API services
• 192.168.100.0/24 — Avoids conflict with common home routers

---

Best Practices

• Start with deny all, then explicitly allow only what’s needed.
• Always define egress rules, even if it’s just allow all.
• Use security group names and descriptions to document intent.
• Keep rules as specific as possible to reduce exposure.