Security groups are OpenStack's cloud-native firewall. They are stateful packet filters applied at each instance's virtual port, so you control exactly which traffic reaches a VM — no host iptables required. Keypairs are the other half of the access story: they inject your SSH public key at boot so you log in with a key rather than a password. Together they are the baseline of a least-privilege cloud.

This tutorial shows how to create keypairs, build security groups from scratch, write precise ingress and egress rules, and apply them to instances. If you have configured a host firewall before, think of this as the cloud-layer equivalent of UFW — same principles, applied through the API.

Prerequisites

• A running OpenStack 2025.2 cloud with the openstack client and project-scoped credentials.
• The member role on your project.
• Optionally, a running instance to apply rules to — see launch your first instance.

Step 1: Create and manage keypairs

A keypair is how you authenticate to Linux instances. Generate one in OpenStack, or — better for security — upload only the public half of a key you generated locally so the private key never leaves your machine:

# Upload an existing local public key (recommended)
openstack keypair create --public-key ~/.ssh/id_ed25519.pub mykey
Or have OpenStack generate one and save the private key
openstack keypair create devkey > ~/.ssh/devkey.pem
chmod 600 ~/.ssh/devkey.pem
openstack keypair list

Step 2: Understand the default security group

Every project has a default security group. Out of the box it denies all inbound traffic and allows all outbound, plus it permits traffic between members of the same group. Inspect it before changing anything:

openstack security group list
openstack security group rule list default

Step 3: Create a purpose-built security group

Rather than loosening default, create dedicated groups per role. Here is a web-server group that we will fill with precise rules:

openstack security group create web-sg 

--description 'Web server: SSH from admin, HTTP/HTTPS from anywhere'

Step 4: Write ingress rules

Add rules that follow least privilege. Open SSH only to your admin network, but allow HTTP and HTTPS from anywhere. The --remote-ip flag scopes a rule to a CIDR:

# SSH only from the office network
openstack security group rule create web-sg 

--proto tcp --dst-port 22 --remote-ip 198.51.100.0/24

HTTP and HTTPS from the internet
openstack security group rule create web-sg --proto tcp --dst-port 80
openstack security group rule create web-sg --proto tcp --dst-port 443
Allow ping for diagnostics
openstack security group rule create web-sg --proto icmp

Referencing another group instead of a CIDR

For tier-to-tier traffic — say, app servers reaching a database group — reference the source group rather than IPs. This keeps rules valid as instances come and go:

openstack security group create db-sg
openstack security group rule create db-sg 

--proto tcp --dst-port 5432 --remote-group app-sg

Step 5: Tighten egress (optional but recommended)

The default allows all outbound traffic. For sensitive workloads, replace it with explicit egress rules. First remove the permissive default egress rule, then add only what the workload needs:

# Find and delete the broad egress rule ID
openstack security group rule list web-sg
openstack security group rule delete <egress-rule-id>

Allow only DNS and HTTPS outbound
openstack security group rule create web-sg --egress --proto udp --dst-port 53
openstack security group rule create web-sg --egress --proto tcp --dst-port 443

Step 6: Apply groups to instances

Attach the security group at boot, or add it to a running instance. You can stack multiple groups; their rules are additive:

# At launch
openstack server create --flavor m1.small --image ubuntu-24.04 

--network acme-net --key-name mykey --security-group web-sg web-01

Or add to a running server
openstack server add security group web-01 web-sg
openstack server remove security group web-01 default

Verification

Confirm the rules are attached and behave as intended. From an allowed host, SSH and curl should work; from a disallowed host, SSH should time out:

openstack server show web-01 -c security_groups
openstack security group rule list web-sg

from the office network
ssh -i ~/.ssh/id_ed25519 ubuntu@203.0.113.50
curl -I http://203.0.113.50

Common errors and troubleshooting

SSH times out after adding rules

Security groups are additive but the instance must carry a group that allows port 22 from your IP. Confirm with openstack server show -c security_groups and that your public IP falls inside the --remote-ip CIDR.

Rule has no effect

Stateful filtering means you only need an ingress rule; the reply is allowed automatically. If a rule seems ignored, check you applied it to the right group and that the instance actually uses that group, not default.

Cannot delete a security group

A group in use by a port cannot be deleted. Detach it from all instances first with openstack server remove security group, then delete it.

Conclusion

You now have key-based login and a least-privilege firewall enforced at the virtual port of every instance — SSH scoped to trusted networks, services exposed deliberately, and egress optionally locked down. This cloud-native approach scales far better than per-host iptables and is auditable through the API. Combine it with Neutron networking and a hardened instance for a defensible workload.

Enforcing consistent, least-privilege security policy across many tenants and hundreds of instances is part of the BSI C5 and ISO 27001 posture clouditiv operates on its digitally sovereign managed cloud, so security is the default rather than an afterthought.