Security Groups sind die cloud-native Firewall von OpenStack. Es sind zustandsbehaftete Paketfilter, die am virtuellen Port jeder Instanz greifen – Sie steuern also exakt, welcher Verkehr eine VM erreicht, ohne Host-iptables. Keypairs sind die andere Hälfte des Zugriffs: Sie injizieren Ihren öffentlichen SSH-Schlüssel beim Start, sodass Sie sich mit Schlüssel statt Passwort anmelden. Zusammen bilden sie die Basis einer Least-Privilege-Cloud.

Dieses Tutorial zeigt, wie Sie Keypairs erstellen, Security Groups von Grund auf aufbauen, präzise Ein- und Ausgangsregeln schreiben und sie auf Instanzen anwenden. Wenn Sie schon einmal eine Host-Firewall konfiguriert haben, betrachten Sie dies als das Cloud-Pendant zu UFW – dieselben Prinzipien, angewandt über die API.

Voraussetzungen

• Eine laufende OpenStack-2025.2-Cloud mit openstack-Client und projektbezogenen Zugangsdaten.
• Die Rolle member auf Ihrem Projekt.
• Optional eine laufende Instanz, auf die Sie Regeln anwenden – siehe erste Instanz starten.

Schritt 1: Keypairs erstellen und verwalten

Ein Keypair dient der Authentifizierung an Linux-Instanzen. Erzeugen Sie eines in OpenStack oder – sicherheitstechnisch besser – laden Sie nur den öffentlichen Teil eines lokal erzeugten Schlüssels hoch, sodass der private Schlüssel Ihre Maschine nie verlässt:

# Vorhandenen lokalen Public Key hochladen (empfohlen)
openstack keypair create --public-key ~/.ssh/id_ed25519.pub mykey
Oder OpenStack eines erzeugen lassen und den privaten Schlüssel speichern
openstack keypair create devkey > ~/.ssh/devkey.pem
chmod 600 ~/.ssh/devkey.pem
openstack keypair list

Schritt 2: Die Default-Security-Group verstehen

Jedes Projekt hat eine default-Security-Group. Standardmäßig verweigert sie allen eingehenden Verkehr und erlaubt allen ausgehenden; zudem lässt sie Verkehr zwischen Mitgliedern derselben Gruppe zu. Prüfen Sie sie, bevor Sie etwas ändern:

openstack security group list
openstack security group rule list default

Schritt 3: Eine zweckgebundene Security Group erstellen

Statt default aufzuweichen, erstellen Sie dedizierte Gruppen je Rolle. Hier eine Webserver-Gruppe, die wir mit präzisen Regeln füllen:

openstack security group create web-sg 

--description 'Webserver: SSH vom Admin, HTTP/HTTPS von überall'

Schritt 4: Eingangsregeln schreiben

Fügen Sie Regeln nach dem Least-Privilege-Prinzip hinzu. Öffnen Sie SSH nur für Ihr Admin-Netz, erlauben Sie aber HTTP und HTTPS von überall. Das Flag --remote-ip begrenzt eine Regel auf eine CIDR:

# SSH nur aus dem Büronetz
openstack security group rule create web-sg 

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

HTTP und HTTPS aus dem 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
Ping für Diagnose erlauben
openstack security group rule create web-sg --proto icmp

Eine andere Gruppe statt einer CIDR referenzieren

Für Verkehr zwischen Tiers – etwa App-Server, die eine Datenbank-Gruppe erreichen – referenzieren Sie die Quellgruppe statt IPs. So bleiben Regeln gültig, während Instanzen kommen und gehen:

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

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

Schritt 5: Ausgang einschränken (optional, aber empfohlen)

Standardmäßig ist aller ausgehende Verkehr erlaubt. Für sensible Workloads ersetzen Sie das durch explizite Ausgangsregeln. Entfernen Sie zuerst die freizügige Default-Egress-Regel und fügen Sie dann nur das Notwendige hinzu:

# ID der breiten Egress-Regel finden und löschen
openstack security group rule list web-sg
openstack security group rule delete <egress-rule-id>

Nur DNS und HTTPS ausgehend erlauben
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

Schritt 6: Gruppen auf Instanzen anwenden

Hängen Sie die Security Group beim Start an oder fügen Sie sie einer laufenden Instanz hinzu. Sie können mehrere Gruppen stapeln; ihre Regeln sind additiv:

# Beim Start
openstack server create --flavor m1.small --image ubuntu-24.04 

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

Oder zu laufendem Server hinzufügen
openstack server add security group web-01 web-sg
openstack server remove security group web-01 default

Verifizierung

Bestätigen Sie, dass die Regeln angehängt sind und wie gewünscht wirken. Von einem erlaubten Host sollten SSH und curl funktionieren; von einem nicht erlaubten Host sollte SSH in einen Timeout laufen:

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

aus dem Büronetz
ssh -i ~/.ssh/id_ed25519 ubuntu@203.0.113.50
curl -I http://203.0.113.50

Häufige Fehler und Fehlersuche

SSH läuft nach dem Hinzufügen von Regeln in einen Timeout

Security Groups sind additiv, aber die Instanz muss eine Gruppe tragen, die Port 22 von Ihrer IP erlaubt. Prüfen Sie mit openstack server show -c security_groups, dass Ihre öffentliche IP in der --remote-ip-CIDR liegt.

Regel hat keine Wirkung

Zustandsbehaftetes Filtern bedeutet, dass Sie nur eine Eingangsregel benötigen; die Antwort wird automatisch erlaubt. Wirkt eine Regel ignoriert, prüfen Sie, dass Sie sie der richtigen Gruppe zugewiesen haben und die Instanz diese Gruppe tatsächlich nutzt, nicht default.

Security Group lässt sich nicht löschen

Eine von einem Port genutzte Gruppe lässt sich nicht löschen. Lösen Sie sie zuerst mit openstack server remove security group von allen Instanzen und löschen Sie sie dann.

Fazit

Sie haben nun schlüsselbasierte Anmeldung und eine Least-Privilege-Firewall, die am virtuellen Port jeder Instanz greift – SSH auf vertrauenswürdige Netze beschränkt, Dienste bewusst freigegeben und der Ausgang optional gesperrt. Dieser cloud-native Ansatz skaliert weit besser als iptables pro Host und ist über die API auditierbar. Kombinieren Sie ihn mit Neutron-Networking und einer gehärteten Instanz für einen verteidigungsfähigen Workload.

Konsistente Least-Privilege-Sicherheitsrichtlinien über viele Mandanten und hunderte Instanzen durchzusetzen, gehört zur BSI-C5- und ISO-27001-Aufstellung, die clouditiv auf seiner digital souveränen Managed Cloud betreibt – damit Sicherheit der Standard ist und kein nachträglicher Gedanke.