Ein Schwank aus dem Maschinenraum

Role Based Access Control in OpenStack – Berechtigungen einschränken

OpenStack verwendet eine auf Policies aufbauende Rollenbasierte Zugriffskontrolle, wie ich im Artikel Role Based Access Control in OpenStack – Einführung näher beschrieben habe.

Rollen mit gegenüber normalen Nutzern eingeschränkten Berechtigungen umzusetzen, erfordert in OpenStack besonderes Fingerspitzengefühl. Obwohl es für normale Nutzer gewöhnlich die Rolle _member_ oder Member gibt, sind die meisten Policy-Rules nicht an diese Rollen gebunden, sondern allgemein gehalten, sodass sie für jeden angemeldeten Nutzer erfüllt sind. In der Glance-Policy gibt es zum Beispiel viele Regeln wie die folgende.

Diese Regel erlaubt es jedem Nutzer, in seinem Projekt Images hochzuladen, unabhängig davon welche Rolle er in diesem Projekt hat. Möchte man nun zum Beispiel eine Rolle erstellen, die explizit nur lesend auf Ressourcen zugreifen darf, muss man für alle schreibenden Berechtigungen definieren, dass diese nicht gewährt werden.

Als weitere Schwierigkeit kommt hinzu, dass nicht nur die Policy für eine OpenStack-Komponente angepasst werden muss, sondern für alle Komponenten, in denen die Rolle weniger als die Berechtigungen eines normalen Projekt-Members gewähren soll.

Will man eigene Rollen in OpenStack einbauen, sollte man sich also immer zuerst überlegen, was ein normaler Nutzer darf und an welchen Stellen die eigene Rolle explizit davon abweichen soll.

David Rabel arbeitet bei B1 Systems als Trainer und Consultant für Themen rund um Linux und OpenStack. Er ist Mitglied des Debian OpenStack Packaging Teams und steuert selbst gelegentlich Patches zum OpenStack Code oder der Dokumentation bei.

Role Based Access Control in OpenStack – Einführung

OpenStack RBAC

OpenStack verwendet role based access control (RBAC) als Authorisierungsmodell. Das bedeutet, dass Berechtigungen nicht direkt für einzelne User oder Gruppen von User gewährt werden. Berechtigungen werden stattdessen über einen Satz von Regeln (Rules) zu Rollen zugeordnet, welche dann wiederum Nutzern oder Gruppen von Nutzern zugeordnet werden.

Hat ein Nutzer beispielsweise in seinem Projekt die Member-Rolle, sind damit im Hintergrund diverse Berechtigungen verknüpft, wie für das Hochladen von Images oder Starten von Virtuellen Maschinen. Obwohl Rollen gewöhnlich bezüglich eines Projekts oder einer Domain vergeben werden, sind einige der Berechtigungen – insbesondere für Admins – global gültig.

policy.json

Der Regelsatz, mit dem einer Rolle Berechtigungen zugewiesen werden, wird Policy genannt. Standardmäßig sind diese Policies für jede Komponente in einer JSON-Datei hinterlegt, die policy.json heißt. Der Trend geht jedoch in OpenStack dahin, die Standarpolicy im Quelltext statt einer policy.json auszuliefern.

Es gibt zwei Arten von Regeln in einer policy.json-Datei: Regeln, die direkt einem API-Call entsprechen, und Regeln, die aus Übersichtsgründen definiert werden, um sie innerhalb der policy.json wiederzuverwenden.

Beispiele

Die folgenden Zeilen sind aus einer policy.json von Keystone.

In der ersten Zeile wird eine Regeln admin_required definiert, die erfüllt ist, wenn der Nutzer die Rolle admin hat.

Die nächste Zeile erlaubt jedem, der die Regel admin_required erfüllt, list_services-API-Calls auszuführen. Mit dem OpenStackClient würde das dem Kommando openstack service list entsprechen.

Es lassen sich ebenfalls Regeln definieren, die immer erfüllt sind. Die meisten Komponenten haben weitere Prüfungen im Quelltext eingebaut, die Zugriffe nur Admins und Usern erlauben, die im richtigen Projekt eingeloggt sind.

Außer der Rolle, die ein User innehat, können viele andere Werte abgefragt und zur Definition von Regeln verwendet werden. Zum Beispiel kann überprüft werden, ob die Domain der angefragten Ressource der Domain des Users entspricht.

 

Weitere Informationen

Weitere Informationen zu OpenStack Policies finden sich in der offiziellen Dokumentation:
https://docs.openstack.org/security-guide/identity/policies.html

David Rabel arbeitet bei B1 Systems als Trainer und Consultant für Themen rund um Linux und OpenStack. Er ist Mitglied des Debian OpenStack Packaging Teams und steuert selbst gelegentlich Patches zum OpenStack Code oder der Dokumentation bei.

OpenStack Freezer – Backup und Restore

Backups sind ein integraler Bestandteil jeder IT-Strategie. In einer komplexen Infrastruktur wie OpenStack ist es nicht immer leicht den Überblick über zu sichernde Komponenten zu behalten. Sollte wirklich einmal ein größerer Ausfall eintreten, ist es wichtig, Daten schnell und möglichst ohne Verluste wiederherstellen zu können.

Backup und Restore mit Freezer

OpenStack bietet für die Durchführung von Backups und Restores die Komponente Freezer an. Mit Freezer können sowohl Datenbanken, einzelne Verzeichnisse als auch OpenStack-Ressourcen wie virtuelle Maschinen oder Volumes gesichert und wiederhergestellt werden.

Als Backup-Ziel stehen zurzeit lokale Ordner (und damit auch über NFS eingehängte Verzeichnisse), ein entfernter Host über SSH, sowie Storage, der über eine Swift-API oder S3-API erreichbar ist, zur Verfügung. Dabei können verschiedene Backup-Ziele beliebig kombiniert werden. Es ist zum Beispiel möglich, Backups lokal zu speichern und gleichzeitig in Swift hochzuladen.

Aufbau von Freezer

Kern von Freezer ist freezer-agent, ein Dienst um die eigentlichen Backups und das Wiederherstellen der Backups durchzuführen. Der Dienst ist auf den einzelnen Nodes der Control Plane installiert und kann auch manuell als Kommandozeilentool verwendet werden.

Die API von Freezer dient dazu sogenannte Jobs zu spezifizieren. In diesen Jobs, die im JSON-Format übergeben werden, werden verschiedene Aktionen definiert und wann und wie oft sie ausgeführt werden sollen. Dabei können verschiedene Backup-Aktionen – auch auf unterschiedlichen Nodes – parallel ausgeführt werden, um möglichst konsistente Daten zu erhalten.

Diese Jobdefinitionen fragt der Dienst freezer-scheduler von der API ab und startet den freezer-agent mit entsprechenden Parametern, um die Aktionen durchzuführen.

Daneben gibt es das Plugin freezer-web-ui für das OpenStack Dashboard Horizon.

Momentan wird noch an dem unabhängigen Service freezer-dr gearbeitet, der für Disaster Recovery bei Ausfall eines oder mehrerer Compute-Nodes zuständig ist.

Weitere Informationen

OpenStack Wiki:
https://wiki.openstack.org/wiki/Freezer

OpenStack Git:
https://git.openstack.org/cgit/openstack/freezer/
https://git.openstack.org/cgit/openstack/freezer-api/
https://git.openstack.org/cgit/openstack/freezer-dr/
https://git.openstack.org/cgit/openstack/freezer-web-ui/

Dokumentation:
https://docs.openstack.org/freezer/latest/index.html

IRC-Channel:
#openstack-freezer auf freenode.org

David Rabel arbeitet bei B1 Systems als Trainer und Consultant für Themen rund um Linux und OpenStack. Er ist Mitglied des Debian OpenStack Packaging Teams und steuert selbst gelegentlich Patches zum OpenStack Code oder der Dokumentation bei.

OpenStack Masakari – Virtual Machine High Availability

Während Applikationen in der Cloud im Idealfall so aufgebaut sind, dass der Ausfall einer virtuellen Maschine durch das Starten einer anderen virtuellen Maschine aufgefangen werden kann (Cattle-Model), sind in der Praxis noch häufig virtuelle Maschinen anzutreffen, deren Ausfall nur durch das Wiederherstellen genau dieser virtuellen Maschine aufgefangen werden kann (Pet-Model).

Aber selbst wenn man nur mit cloud-nativen Applikationen arbeitet, wo also ein Ausfall durch das Starten einer neuen virtuellen Maschine behoben werden kann, will man gegebenenfalls das Wiederherstellen von virtuellen Maschinen automatisieren.

Hochverfügbare VMs (VMHA) mit Masakari

Dieses automatische Wiederherstellen bezeichnet man als Virtual Machine High Availability (VMHA). Wobei der Begriff „Hochverfügbarkeit“ in diesem Fall eher weit ausgelegt wird: Nicht die unterbrechungsfreie Verfügbarkeit steht im Mittelpunkt, sondern die automatische Wiederherstellung.

In OpenStack stellt die Komponente Masakari genau diese Funktionalität bereit. 2015 vom japanischen Telekommunikationsunternehmen NTT gestartet, gehört Masakari seit 2016 offiziell zu OpenStack.

Aufbau von Masakari

Masakari besteht grob aus drei Komponenten: Einer API, mit deren Hilfe sich Failover-Segmente definieren lassen; Monitor-Diensten, die jeweils den Host, den Virtual Machine Manager und die virtuelle Maschine selbst überwachen; und einer Engine, die im Fehlerfall mit anderen OpenStack-APIs kommuniziert um einen Failover einzuleiten.

Um auch den Ausfall eines kompletten Hypervisors abfangen zu können, sollten die virtuellen Maschinen auf einem Shared Storage liegen. Um einen Ausfall dieser Art erkennen zu können, setzt Masakari auf Pacemaker in Verbindung mit seinem Hostmonitor, während der Processmonitor und der Instancemonitor jeweils direkt nova-compute und libvirtd überwachen.

Weitere Informationen

Einen weiterführenden Überblick gibt die Vorstellung von Masakari auf dem OpenStack Summit in Tokyo 2015.

OpenStack Wiki:
https://wiki.openstack.org/wiki/Masakari

OpenStack Git:
https://git.openstack.org/cgit/openstack/masakari/
https://git.openstack.org/cgit/openstack/masakari-monitors/
https://git.openstack.org/cgit/openstack/python-masakariclient/

Dokumentation:
https://docs.openstack.org/masakari/latest/index.html

IRC-Channel:
#openstack-masakari auf freenode.org

David Rabel arbeitet bei B1 Systems als Trainer und Consultant für Themen rund um Linux und OpenStack. Er ist Mitglied des Debian OpenStack Packaging Teams und steuert selbst gelegentlich Patches zum OpenStack Code oder der Dokumentation bei.

Font Awesome in Sphinx nutzen

Um Font Awesome in Sphinx nutzen zu können wird die Erweiterung sphinx_fontawesome benötigt.

Diese zunächst mit pip install sphinx_fontawesome installieren und anschliessend die Erweiterung in der conf.py hinzufügen (extensions = ['sphinx_fontawesome']).

Nun können die Icon mittels .. fa:: check oder |check| genutzt werden. Ein Beispiel dazu kann man sich in unserer Dokumentation ansehen.

Repositories einer GitHub Organisation anzeigen

Mit PyGitHub ist es möglich auf die GitHub API v3 via Python zuzugreifen. Mit pip install PyGitHub kann die Library installiert werden.

Open vSwitch Provider Bridge einer Kolla Umgebung hinzufügen

Um auf einem bereits laufendem Open vSwitch (OVS) in einer Kolla Umgebung die Provider Bridge br-bond2 zu erstellen und dieser das physikalische Device bond2 hinzuzufügen wird das folgende Kommando ausgeführt.

Mit dem Kommando ovs-vsctl show kann die neu erstellte Provider Bridge geprüft werden.

In der Konfiguration von Kolla wird die neue Provider Bridge dem Parameter neutron_bridge_name hinzugefügt. Das physikalische Device dem Parameter neutron_external_interface. Eine anschliessende Rekonfiguration des Neutron Dienstes ist dann erforderlich.

Die oben beschriebene manuelle Erstellung der Provider Bridge ist nur erforderlich wenn man einer bereits ausgerollten Kolla Umgebung eine neue Provider Bridge hinzufügt. Die Erstellung muss auf allen Knoten durchgeführt werden auf dem die Provider Bridge später genutzt werden soll.

Get rid of ubuntu-xenial-16.04-cloudimg-console.log

When using the Vagrantbox ubuntu/xenial64 you will have a file ubuntu-xenial-16.04-cloudimg-console.log after the start. If you do not need it simply add the following lines to your Vagrantfile to get rid of it.

Source: https://groups.google.com/forum/#!topic/vagrant-up/eZljy-bddoI