API-Endpunkt-Konfigurationsempfehlungen¶
Interne API-Kommunikation¶
OpenStack bietet sowohl öffentliche als auch private API-Endpunkte. Standardmäßig verwenden OpenStack-Komponenten die öffentlich definierten Endpunkte. Die Empfehlung besteht darin, diese Komponenten so zu konfigurieren, dass sie den API-Endpunkt innerhalb der entsprechenden Sicherheitsdomäne verwenden.
Services wählen ihre jeweiligen API-Endpunkte auf Basis des OpenStack-Servicekatalogs aus. Diese Dienste können nicht den aufgeführten öffentlichen oder internen API-Endpunktwerten gehorchen. Dies kann dazu führen, dass interner Verwaltungsverkehr zu externen API-Endpunkten geleitet wird.
Konfigurieren Sie interne URLs im Identity Service Katalog¶
Der Identitätsdienstkatalog sollte sich Ihrer internen URLs bewusst sein. Während dieses Merkmal nicht standardmäßig verwendet wird, kann es durch die Konfiguration genutzt werden. Darüber hinaus sollte es vorwärtskompatibel mit zu erwartenden Änderungen sein, sobald dieses Verhalten zum Standard wird.
Um eine interne URL für einen Endpunkt zu registrieren:
$ openstack endpoint create identity \
--region RegionOne internal \
https://MANAGEMENT_IP:5000/v3
Ersetzen Sie MANAGEMENT_IP mit der Management-IP Adresse Ihres Controller Knotens.
Konfigurieren von Anwendungen für interne URLs¶
Sie können einige Dienste zwingen, bestimmte API-Endpunkte zu verwenden. Daher empfiehlt es sich, dass jeder OpenStack-Dienst, der mit der API eines anderen Dienstes kommuniziert, explizit konfiguriert werden muss, um auf den richtigen internen API-Endpunkt zuzugreifen.
Jedes Projekt kann eine inkonsistente Möglichkeit zur Definition von Ziel-API-Endpunkten darstellen. Zukünftige Releases von OpenStack versuchen, diese Inkonsistenzen durch konsequente Nutzung des Identity Service Katalogs zu lösen.
Konfigurationsbeispiel #1: nova¶
cinder_catalog_info='volume:cinder:internalURL'
glance_protocol='https'
neutron_url='https://neutron-host:9696'
neutron_admin_auth_url='https://neutron-host:9696'
s3_host='s3-host'
s3_use_ssl=True
Konfigurationsbeispiel #2: cinder¶
glance_host = 'https://glance-server'
Paste und Middleware¶
Die meisten API-Endpunkte und andere HTTP-Dienste in OpenStack verwenden die Python-Paste-Bereitstellungsbibliothek. Aus Sicherheitsgründen ermöglicht diese Bibliothek die Manipulation der Anforderungsfilterpipeline durch die Konfiguration der Applikation. Jedes Element in dieser Kette wird als Middleware bezeichnet. Das Ändern der Reihenfolge der Filter in der Pipeline oder das Hinzufügen zusätzlicher Middleware kann unvorhersehbare Sicherheitsauswirkungen haben.
Häufig fügen Implementierer Middleware hinzu, um die Basisfunktionalität von OpenStack zu erweitern. Wir empfehlen, dass die Implementierer die potenzielle Exposition sorgfältig berücksichtigen, die durch die Hinzufügung von Nicht-Standard-Softwarekomponenten in ihre HTTP-Anforderungspipeline eingeführt wird.
Weitere Informationen über Paste Deploy finden Sie unter Python Paste Deployment-Dokumentation.
API Endpunkt Prozess Isolation und Policy¶
Sie sollten API-Endpunktprozesse isolieren. Insbesondere diejenigen, die sich innerhalb der öffentlichen Sicherheitsdomäne befinden, sollten so weit wie möglich isoliert sein. Wo Deployments erlaubt sind, sollten API-Endpunkte auf separaten Hosts für eine erhöhte Isolation eingesetzt werden.
Namensräume¶
Viele Betriebssysteme bieten jetzt Kompartimentierungsunterstützung. Linux unterstützt Namespaces, um Prozesse in unabhängige Domänen zu vergeben. Andere Teile dieser Anleitung decken die Systemabteilung genauer ab.
Netzwerkpolicy¶
Da API-Endpunkte typischerweise mehrere Sicherheitsdomänen überbrücken, müssen Sie der Kompartimentierung der API-Prozesse besondere Aufmerksamkeit widmen. Siehe Überbrückung von Sicherheitsdomänen für weitere Informationen in diesem Bereich.
Mit sorgfältiger Modellierung können Sie Netzwerk-ACLs und IDS-Technologien nutzen, um explizite Punkt-zu-Punkt-Kommunikation zwischen Netzwerkdiensten zu erzwingen. Als kritischer Cross-Domain-Service funktioniert diese Art der expliziten Durchsetzung gut für den Message-Warteschlangen-Dienst von OpenStack.
Um Richtlinien zu erzwingen, können Sie Dienste, Host-basierte Firewalls (wie iptables), lokale Richtlinien (SELinux oder AppArmor) und optional globale Netzwerkrichtlinien konfigurieren.
Obligatorische Zugriffskontrollen¶
Sie sollten API-Endpunktprozesse voneinander und andere Prozesse auf einer Maschine isolieren. Die Konfiguration für diese Prozesse sollte auf diese Prozesse nicht nur durch diskretionäre Zugriffskontrollen beschränkt werden, sondern durch obligatorische Zugriffskontrollen. Das Ziel dieser erweiterten Zugangskontrollen ist es, die Eindämmung und Eskalation von API-Endpunktsicherheitsverletzungen zu unterstützen. Mit obligatorischen Zugangskontrollen beschränken diese Verstöße den Zugang zu Ressourcen erheblich und bieten eine frühere Alarmierung bei solchen Ereignissen.
API-Endpunkt-Ratenbegrenzung¶
Rate Limiting ist ein Mittel, um die Häufigkeit der Ereignisse zu kontrollieren, die von einer netzwerkbasierten Anwendung empfangen werden. Wenn eine robuste Ratenbegrenzung nicht vorhanden ist, kann dies dazu führen, dass eine Anwendung anfällig für verschiedene Denial-of-Service-Angriffe ist. Dies gilt insbesondere für APIs, die ihrer Natur nach eine hohe Frequenz ähnlicher Anforderungsarten und Operationen annehmen sollen.
Innerhalb von OpenStack empfiehlt es sich, dass alle Endpunkte, insbesondere die Öffentlichkeit, mit einer zusätzlichen Schutzschicht versehen sind, und zwar entweder durch eine ratenbegrenzende Proxy- oder Web-Applikations-Firewall.
Es ist entscheidend, dass der Betreiber die individuellen Leistungsbedürfnisse von Nutzern und Diensten innerhalb ihrer OpenStack-Cloud sorgfältig plant und berücksichtigt, wenn er eine Geschwindigkeitsbegrenzungsfunktionalität konfiguriert und implementiert.
Gemeinsame Lösungen für die Bereitstellung von Ratenbegrenzungen sind Nginx, HAProxy, OpenRepose oder Apache Module wie mod_ratelimit, mod_qos oder mod_security.
