Sicherung von OpenStack-Netzwerkdiensten

In diesem Abschnitt werden die Best Practices der OpenStack Networking-Konfiguration beschrieben, die für die Projektnetzwerksicherheit in Ihrer OpenStack-Bereitstellung gelten.

Projektnetzwerk-Workflow

OpenStack Networking bietet Benutzern selbst Dienste von Netzwerkressourcen und Konfigurationen. Es ist wichtig, dass Cloud-Architekten und Betreiber ihre Design-Use-Cases bewerten, indem sie den Nutzern die Möglichkeit bieten, verfügbare Netzwerkressourcen zu erstellen, zu aktualisieren und zu zerstören.

Networking Resource Policy Engine

Eine Policy Engine und ihre Konfigurationsdatei, policy.json, innerhalb von OpenStack Networking bietet eine Methode, um eine feinkörnige Autorisierung von Benutzern auf Projektnetzwerkmethoden und -objekten zu ermöglichen. Die OpenStack Networking-Richtliniendefinitionen beeinflussen die Netzwerkverfügbarkeit, die Netzwerksicherheit und die gesamte OpenStack-Sicherheit. Cloud-Architekten und Betreiber sollten ihre Politik gegenüber dem Nutzer- und Projektzugang auf die Verwaltung von Netzwerkressourcen sorgfältig auswerten. Eine ausführlichere Erläuterung der OpenStack Networking-Richtliniendefinition finden Sie im Abschnitt „Authentifizierung und Autorisierung“ <https://docs.openstack.org/admin-guide/networking_auth.html>`__ im OpenStack Administrator Guide.

Bemerkung

Es ist wichtig, die standardmäßige Netzwerkressourcenrichtlinie zu überprüfen, da diese Richtlinie für Ihre Sicherheitsanpassung geändert werden kann.

Wenn Ihre Installation von OpenStack mehrere externe Zugriffspunkte in verschiedene Sicherheitsdomänen bereitstellt, ist es wichtig, dass Sie die Fähigkeit des Projekts einschränken, mehrere vNICs an mehrere externe Zugriffspunkte anzuhängen - dies würde diese Sicherheitsdomänen überbrücken und zu unvorhergesehenen Sicherheitskompromissen führen. Es ist möglich, dieses Risiko durch die Nutzung der Host-Aggregate-Funktionalität von OpenStack Compute oder durch die Aufteilung der Projekt-VMs in mehrere Projekt-Projekte mit verschiedenen virtuellen Netzwerk-Konfigurationen zu mildern.

Sicherheitsgruppen

The OpenStack Networking service provides security group functionality using a mechanism that is more flexible and powerful than the security group capabilities built into OpenStack Compute. Thus, nova.conf should always disable built-in security groups and proxy all security group calls to the OpenStack Networking API when using OpenStack Networking. Failure to do so results in conflicting security policies being simultaneously applied by both services. To proxy security groups to OpenStack Networking, use the following configuration values:

  • firewall_driver``muss auf ``nova.virt.firewall.NoopFirewallDriver gesetzt sein, damit nova-compute keine iptables-basierte Filterung selbst durchführt.

  • ``security_group_api``muss auf ``neutron``gesetzt sein, damit alle Sicherheitsgruppenanforderungen mit dem OpenStack Networking Service in Verbindung stehen.

Eine Sicherheitsgruppe ist ein Container für Sicherheitsgruppenregeln. Sicherheitsgruppen und ihre Regeln erlauben Administratoren und Projekten die Möglichkeit, die Art des Verkehrs und der Richtung (Ingress/Egress) anzugeben, die durch einen virtuellen Schnittstellenport passieren darf. Wenn ein virtueller Schnittstellenanschluss in OpenStack Networking erstellt wird, ist er mit einer Sicherheitsgruppe verknüpft. Weitere Informationen zum Standardverhalten von Port-Sicherheitsgruppen finden Sie unter „Verhalten der Netzwerk-Sicherheitsgruppe“ <https://wiki.openstack.org/wiki/Neutron/SecurityGroups#Behavior>`__ Dokumentation. Regeln können der Standard-Sicherheitsgruppe hinzugefügt werden, um das Verhalten auf einer Bereitstellungsbasis zu ändern.

Wenn Sie die OpenStack Compute API verwenden, um Sicherheitsgruppen zu ändern, gilt die aktualisierte Sicherheitsgruppe für alle virtuellen Schnittstellenports auf einer Instanz. Dies ist darauf zurückzuführen, dass die OpenStack Compute-Sicherheitsgruppen-APIs auf Instanzbasierten und nicht auf Port-basierten Instanzen basieren, wie sie in OpenStack Networking gefunden wurden.

Kontingente

Kontingente bieten die Möglichkeit, die Anzahl der für die Projekte verfügbaren Netzwerkressourcen zu begrenzen. Sie können Standardkontingente für alle Projekte erzwingen. Die ``/etc/neutron/neutron.conf``enthält diese Optionen für Kontingent:

[QUOTAS]
# resource name(s) that are supported in quota features
quota_items = network,subnet,port

# default number of resource allowed per tenant, minus for unlimited
#default_quota = -1

# number of networks allowed per tenant, and minus means unlimited
quota_network = 10

# number of subnets allowed per tenant, and minus means unlimited
quota_subnet = 10

# number of ports allowed per tenant, and minus means unlimited
quota_port = 50

# number of security groups allowed per tenant, and minus means unlimited
quota_security_group = 10

# number of security group rules allowed per tenant, and minus means unlimited
quota_security_group_rule = 100

# default driver to use for quota checks
quota_driver = neutron.quota.ConfDriver

OpenStack Networking unterstützt auch pro-Projekt-Kontingente durch eine Quotaerweiterungs-API. Um pro Projektkontingente zu aktivieren, müssen Sie die ``quota_driver``Option in ``neutron.conf``setzen.

quota_driver = neutron.db.quota.driver.DbQuotaDriver

Mildern von ARP-Spoofing

Bei der Verwendung von flachen Netzwerken können Sie nicht davon ausgehen, dass Projekte, die das gleiche Layer 2 Netzwerk (oder Broadcast Domain) teilen, vollständig voneinander getrennt sind. Diese Projekte können anfällig für ARP-Spoofing sein und riskieren die Möglichkeit von Man-in-the-Middle-Attacken.

Wenn Sie eine Version von Open vSwitch verwenden, die ARP-Feld-Matching unterstützt, können Sie dieses Risiko reduzieren, indem Sie die `` prevent_arp_spoofing``Option für den Open vSwitch Agent aktivieren. Diese Option verhindert, dass Instanzen Spoof-Angriffe ausführen können. es schützt sie nicht vor Spoofangriffen. Beachten Sie, dass diese Einstellung in Ocata entfernt werden soll, wobei das Verhalten dauerhaft aktiv wird.

Zum Beispiel in /etc/neutron/plugins/ml2/openvswitch_agent.ini:

prevent_arp_spoofing = True

Plug-Ins außer Open vSwitch können auch ähnliche Maßnahmen zur Schadensbegrenzung enthalten. Es empfiehlt sich, diese Funktion gegebenenfalls zu aktivieren.

Bemerkung

Sogar mit ``prevent_arp_spoofing``aktiviert, bietet flache Vernetzung nicht ein vollständiges Niveau der Projektisolation, da alle Projektverkehr noch an das gleiche VLAN gesendet wird.