Management-Schnittstellen

Es ist notwendig für Administratoren, Befehl und Kontrolle über die Cloud für verschiedene operative Funktionen durchzuführen. Es ist wichtig, dass diese Befehls- und Kontrolleinrichtungen verstanden und gesichert sind.

OpenStack bietet mehrere Management-Schnittstellen für Betreiber und Tenants:

  • OpenStack Dashboard (Horizont)

  • OpenStack API

  • Secure shell (SSH)

  • OpenStack-Management-Dienstprogramme wie nova-manage und glance-manage

  • Out-of-Band-Management-Schnittstellen wie IPMI

Dashboard

Das OpenStack Dashboard (Horizont) bietet Administratoren und Tenants eine webbasierte grafische Oberfläche zur Bereitstellung und zum Zugriff auf Cloud-basierte Ressourcen. Das Dashboard kommuniziert mit den Back-End-Diensten über Anrufe an die OpenStack API.

Fähigkeiten

  • Als ein Cloud-Administratoren bietet das Dashboard eine Gesamtansicht der Größe und des Zustands Ihrer Cloud. Sie können Benutzer und Tenants/Projekte erstellen, den Nutzern die Tenants/Projekte zuordnen und die für sie zur Verfügung stehenden Ressourcen beschränken.

  • Das Dashboard stellt den Tenantnutzern ein Self-Service-Portal zur Verfügung, um ihre eigenen Ressourcen innerhalb der von Administratoren festgelegten Grenzen bereitzustellen.

  • Das Dashboard bietet GUI-Unterstützung für Router und Load-Balancer. Zum Beispiel implementiert das Dashboard jetzt alle wichtigen Netzwerkfunktionen.

  • Es ist eine erweiterbare Django Web-Anwendung, die einfaches Plug-in von Drittanbieter-Produkten und -Dienstleistungen wie Abrechnung, Überwachung und zusätzliche Management-Tools ermöglicht.

  • Das Dashboard kann auch für Dienstleister und andere kommerzielle Anbieter gebrandmarkt werden.

Sicherheitsüberlegungen

  • Das Dashboard benötigt Cookies und JavaScript, um im Webbrowser aktiviert zu werden.

  • Der Webserver, der das Dashboard hostet, sollte für TLS konfiguriert sein, um sicherzustellen, dass Daten verschlüsselt sind.

  • Sowohl der Horizon-Web-Service als auch die OpenStack-API, die es verwendet, um mit dem Back-End zu kommunizieren, sind anfällig für Web-Angriffsvektoren wie die Denial-of-Service und müssen überwacht werden.

  • Es ist jetzt möglich (obwohl es zahlreiche Implementierungs-/ Sicherheitsimplikationen gibt), um eine Abbilddatei direkt von der Festplatte eines Benutzers auf den OpenStack Image Service über das Dashboard hochzuladen. Für Multi-Gigabyte-Abbilder ist es immer noch dringend empfohlen,

  • Erstellen und Verwalten von Sicherheitsgruppen über Dashboard. Die Sicherheitsgruppen ermöglichen die L3-L4-Paketfilterung für Sicherheitsrichtlinien zum Schutz virtueller Maschinen.

Literaturverzeichnis

OpenStack.org, ReleaseNotes/Liberty. 2015. OpenStack Liberty Release Notes

OpenStack API

Die OpenStack API ist ein RESTful Web Service Endpunkt für den Zugriff, Bereitstellung und Automatisierung von Cloud-basierten Ressourcen. Operatoren und Benutzer greifen in der Regel über Befehlszeilenprogramme auf

Fähigkeiten

  • Für den Cloud-Administrator bietet die API einen Überblick über die Größe und den Zustand der Cloud-Bereitstellung und ermöglicht die Erstellung von Benutzern, Tenants/Projekten, die Zuordnung von Benutzern zu Tenants/Projekten und die Angabe von Ressourcenquoten pro Tenant/Projektbasis.

  • Die API bietet eine Tenantschnittstelle für die Bereitstellung, Verwaltung und den Zugriff auf ihre Ressourcen.

Sicherheitsüberlegungen

  • Der API-Dienst sollte für TLS konfiguriert werden, um sicherzustellen, dass Daten verschlüsselt sind.

  • Als Web-Service ist OpenStack API anfällig für vertraute Web-Angriffsvektoren wie Denial-of-Service-Angriffe.

Secure Shell (SSH)

Es ist Industrie geworden, den sicheren Shell (SSH) Zugang für das Management von Linux- und Unix-Systemen zu nutzen. SSH verwendet sichere kryptographische Primitive für die Kommunikation. Mit dem Umfang und der Bedeutung von SSH in typischen OpenStack-Implementierungen ist es wichtig, Best Practices für den Einsatz von SSH zu verstehen.

Host-Schlüssel Fingerabdrücke

Oft übersehen ist die Notwendigkeit für die Schlüsselverwaltung für SSH-Hosts. Da die meisten oder alle Hosts in einer OpenStack-Bereitstellung einen SSH-Dienst bereitstellen, ist es wichtig, Vertrauen in Verbindungen zu diesen Hosts zu haben. Es kann nicht unterschätzt werden, dass es nicht möglich ist, eine vernünftig sichere und zugängliche Methode zur Verfügung zu stellen, um zu bestätigen, dass SSH-Host-Key-Fingerabdrücke für Missbrauch und Ausbeutung reif sind.

Alle SSH-Dämonen haben private Host-Key und bieten bei der Verbindung einen Host-Key-Fingerabdruck. Dieser Host-Key-Fingerabdruck ist der Hash eines nicht signierten öffentlichen Schlüssels. Es ist wichtig, dass diese Host-Key-Fingerabdrücke im Voraus bekannt sind, um SSH-Verbindungen zu diesen Hosts zu machen. Die Überprüfung der Host-Key-Fingerabdrücke ist maßgeblich bei der Erkennung von Man-in-the-Middle-Attacken.

In der Regel, wenn ein SSH-Daemon installiert ist, werden Host-Keys generiert. Es ist notwendig, dass die Hosts eine ausreichende Entropie während der Host-Key-Generierung haben. Eine unzureichende Entropie während der Host-Key-Generierung kann dazu führen, dass die SSH-Sitzungen abgehört werden können.

Sobald der SSH-Host-Key erzeugt wird, sollte der Host-Key-Fingerabdruck an einem sicheren und abrufbaren Ort gespeichert werden. Eine besonders bequeme Lösung ist DNS mit SSHFP Resource Records wie in RFC-4255 definiert. Damit dies sicher ist, ist es notwendig, dass DNSSEC eingesetzt wird.

Management-Dienstprogramme

Die OpenStack Management Utilities sind Open-Source-Python-Befehlszeilenclients, die API-Aufrufe tätigen. Es gibt einen Client für jeden OpenStack Service (z.B. nova, glance). Zusätzlich zum Standard-CLI-Client verfügen die meisten Dienste über ein Management-Befehlszeilenprogramm, das direkte Anrufe in die Datenbank macht. Diese dedizierten Management-Dienstprogramme werden langsam veraltet.

Sicherheitsüberlegungen

  • Die dedizierten Verwaltungsdienstprogramme (*-manage) verwenden in manchen Fällen die direkte Datenbankverbindung.

  • Stellen Sie sicher, dass die .rc-Datei, die Ihre Anmeldeinformationen enthält, gesichert ist.

Literaturverzeichnis

OpenStack.org, OpenStack End Benutzerhandbuch. 2016. OpenStack-Befehlszeilen-Clients-Übersicht

OpenStack.org, legen Sie Umgebungsvariablen mit der OpenStack RC-Datei fest. 2016. „Downloaden und sourcen Sie die OpenStack RC Datei <https://docs.openstack.org/user-guide/common/cli_set_environment_variables_using_openstack_rc.html#download-and-source-the-openstack-rc-file>`__

Out-of-Band-Management-Schnittstelle

Das OpenStack-Management beruht auf Out-of-Band-Management-Schnittstellen wie dem IPMI-Protokoll, um auf Knoten zuzugreifen, die OpenStack-Komponenten ausführen. IPMI ist eine sehr beliebte Spezifikation, um Server zu verwalten, zu diagnostizieren und neu zu starten, ob das Betriebssystem läuft oder das System abgestürzt ist.

Sicherheitsüberlegungen

  • Verwenden Sie starke Passwörter und schützen Sie sie, oder verwenden Sie die clientseitige TLS-Authentifizierung.

  • Stellen Sie sicher, dass sich die Netzwerkschnittstellen auf einem eigenen privaten (Management oder separaten) Netzwerk befinden. Segregate Management-Domains mit Firewalls oder anderen Netzwerk-Equipment.

  • Wenn Sie ein Web-Interface verwenden, um mit dem BMC zu interagieren/ IPMI, verwenden Sie immer die TLS-Schnittstelle wie HTTPS oder Port 443. Diese TLS-Schnittstelle sollte NICHT selbst signierte Zertifikate verwenden, wie es oft Standard ist, aber sollten vertrauenswürdige Zertifikate mit den korrekt definierten vollständig qualifizierten Domainnamen haben (FQDNs).

  • Überwachen Sie den Verkehr im Management-Netzwerk. Die Anomalien sind vielleicht einfacher zu verfolgen als auf den belebten Rechenknoten.

Out-of-Band-Management-Schnittstellen auch oft grafische Maschinenkonsolenzugriff. Es ist oft möglich, wenn auch nicht unbedingt standardmäßig, dass diese Schnittstellen verschlüsselt sind. Wenden Sie sich an Ihre Systemsoftware-Dokumentation zur Verschlüsselung dieser Schnittstellen.

Literaturverzeichnis

SANS Technology Institute, InfoSec Handler Tagebuch Blog. 2012. `Hacking Server, die ausgeschaltet sind <https://isc.sans.edu/diary/IPMI%3A+Hacking+servers+that+are+turned+%22off%22/13399> `__