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.