Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
Bezieht sich auf SUSE Enterprise Storage 6

8 Authentifizierung mit cephx Edit source

Das Authentifizierungssystem cephx von Ceph dient dazu, Clients zu identifizieren und sie gegen Man-in-the-Middle-Angriffe zu schützen. Clients in diesem Kontext sind entweder Benutzer (wie zum Beispiel Administratoren) oder auf Ceph bezogene Services/Daemons (beispielsweise OSDs, Monitors oder Object Gateways).

Anmerkung
Anmerkung

Das cephx-Protokoll befasst sich nicht mit der Datenverschlüsselung bei der Übertragung, wie zum Beispiel TLS/SSL.

8.1 Authentifizierungsarchitektur Edit source

cephx verwendet gemeinsame geheime Schlüssel zur Authentifizierung. Dies bedeutet, dass sowohl der Client als auch die Ceph Monitors eine Kopie des geheimen Schlüssels des Clients besitzen. Anhand des Authentifizierungsprotokolls weisen beide Parteien nach, dass sie eine Kopie des Schlüssels besitzen, ohne ihn tatsächlich anzuzeigen. Dies sorgt für gegenseitige Authentifizierung, was bedeutet, der Cluster ist sicher, dass der Benutzer einen geheimen Schlüssel besitzt, und der Benutzer ist sicher, dass der Cluster ebenfalls über eine Kopie des geheimen Schlüssels verfügt.

Eine wichtige Skalierbarkeitsfunktion von Ceph besteht darin, eine zentralisierte Schnittstelle zum Ceph-Objektspeicher zu vermeiden. Dies bedeutet, dass Ceph Clients direkt mit OSDs interagieren. Zum Schutz der Daten steht das Authentifizierungssystem cephx von Ceph zur Verfügung, das die Ceph Clients authentifiziert.

Jeder Monitor kann Clients authentifizieren und Schlüssel verteilen. Daher gibt es bei der Verwendung von cephx keinen Single-Point-of-Failure oder Engpass. Der Monitor gibt eine Authentifizierungsdatenstruktur zurück, die einen Sitzungsschlüssel enthält, mit dem Ceph Services abgerufen werden. Dieser Sitzungsschlüssel wird wiederum mit dem permanenten geheimen Schlüssel des Clients verschlüsselt. Dadurch ist es nur dem Client möglich, Services von den Ceph Monitors anzufordern. Der Client fordert dann mit dem Sitzungsschlüssel die gewünschten Services vom Monitor ab und der Monitor stellt dem Client ein Ticket aus. Dieses Ticket authentifiziert den Client bei den OSDs, die tatsächlich die Daten verarbeiten. Ceph Monitors und OSDs haben ein gemeinsames Geheimnis, sodass der Client das Ticket vom Monitor für jeden OSD oder Metadata Server im Cluster verwenden kann. cephx-Tickets laufen ab, sodass ein abgelaufenes Ticket oder ein Sitzungsschlüssel einem Angreifer, der es sich widerrechtlich angeeignet hat, nichts nützt.

Für cephx muss ein Administrator zunächst Clients/Benutzer einrichten. In der folgenden Grafik ruft der client.admin das Kommando ceph auth get-or-create-key in der Kommandozeile auf, um einen Benutzernamen und einen geheimen Schlüssel zu generieren. Das Teilsystem auth von Ceph generiert den Benutzernamen und Schlüssel, speichert eine Kopie bei den Monitors und überträgt das Geheimnis des Benutzers zurück an den client.admin-Benutzer. Dies bedeutet, dass der Client und der Monitor über einen gemeinsamen geheimen Schlüssel verfügen.

Einfache cephx-Authentifizierung
Abbildung 8.1: Einfache cephx-Authentifizierung

Zur Authentifizierung beim Monitor gibt der Client den Benutzernamen an den Monitor weiter. Der Monitor generiert einen Sitzungsschlüssel und verschlüsselt diesen mit dem geheimen Schlüssel, der mit dem Benutzernamen verknüpft ist. Danach überträgt er das verschlüsselte Ticket zurück an den Client. Der Client entschlüsselt dann die Daten mit dem gemeinsamen geheimen Schlüssel, um den Sitzungsschlüssel abzurufen. Der Sitzungsschlüssel identifiziert den Benutzer für die aktuelle Sitzung. Der Client fordert dann ein Ticket an, das sich auf den Benutzer bezieht. Dieses Ticket wird durch den Sitzungsschlüssel signiert. Der Monitor generiert ein Ticket, verschlüsselt es mit dem geheimen Schlüssel des Benutzers und überträgt es zurück an den Client. Der Client entschlüsselt das Ticket und signiert damit Anforderungen an OSDs und Metadata Server im gesamten Cluster.

Authentifizierung mit cephx
Abbildung 8.2: Authentifizierung mit cephx

Das cephx-Protokoll authentifiziert die fortlaufende Kommunikation zwischen dem Client-Rechner und den Ceph Servern. Jede nach der ersten Authentifizierung zwischen einem Client und einem Server gesendete Nachricht wird mit einem Ticket signiert, das die Monitors, OSDs und Metadata Server mit ihrem gemeinsamen geheimen Schlüssel verifizieren können.

Authentifizierung mit cephx – MDS und OSD
Abbildung 8.3: Authentifizierung mit cephx – MDS und OSD
Wichtig
Wichtig

Der durch diese Authentifizierung erreichte Schutz besteht zwischen dem Ceph Client und den Ceph Cluster-Hosts. Die Authentifizierung wird nicht über den Ceph Client hinaus erweitert. Wenn der Benutzer von einem Remote-Host aus auf den Ceph Client zugreift, wird die Ceph-Authentifizierung nicht auf die Verbindung zwischen dem Host des Benutzers und dem Client-Host angewendet.

8.2 Schlüsselverwaltung Edit source

In diesem Abschnitt werden die Ceph Client-Benutzer und deren Authentifizierung und Autorisierung beim Ceph Storage Cluster erläutert. Benutzer sind entweder Einzelpersonen oder Systemaktoren wie Anwendungen, die Ceph Clients für die Interaktion mit den Ceph Storage Cluster Daemons nutzen.

Wenn Ceph mit aktivierter Authentifizierung und Autorisierung ausgeführt wird (standardmäßig aktiviert), dann müssen Sie einen Benutzernamen angeben und einen Schlüsselbund, der den geheimen Schlüssel des angegebenen Benutzers enthält (normalerweise über die Kommandozeile). Wenn Sie keinen Benutzernamen angeben, verwendet Ceph client.admin als standardmäßigen Benutzernamen. Wenn Sie keinen Schlüsselbund angeben, sucht Ceph nach einem Schlüsselbund über die Schlüsselbundeinstellung in der Ceph-Konfigurationsdatei. Wenn Sie beispielsweise das Kommando ceph health ausführen, ohne einen Benutzernamen oder Schlüsselbund anzugeben, dann interpretiert Ceph das Kommando folgendermaßen:

cephadm@adm > ceph -n client.admin --keyring=/etc/ceph/ceph.client.admin.keyring health

Alternativ können Sie mit der CEPH_ARGS-Umgebungsvariable die wiederholte Eingabe von Benutzername und Geheimnis vermeiden.

8.2.1 Hintergrundinformationen Edit source

Ungeachtet des Typs des Ceph Clients (beispielsweise Blockgerät, Objektspeicher, Dateisystem, systemeigene API) speichert Ceph alle Daten als Objekte in Pools. Ceph-Benutzer benötigen zum Lesen und Schreiben von Daten Zugriff auf die Pools. Außerdem müssen Ceph-Benutzer über Ausführungsberechtigungen verfügen, um die Verwaltungskommandos von Ceph zu verwenden. Die Ceph-Benutzerverwaltung verstehen Sie am besten anhand der folgenden Konzepte.

8.2.1.1 Benutzer Edit source

Ein Benutzer ist entweder eine Einzelperson oder ein Systemaktor wie eine Anwendung. Durch die Erstellung von Benutzern steuern Sie, wer (oder was) auf Ihren Ceph Storage Cluster, dessen Pools und die Daten in den Pools Zugriff hat.

Ceph verwendet Typen von Benutzern. Zum Zweck der Benutzerverwaltung lautet der Typ immer client. Ceph kennzeichnet Benutzer durch (.) getrennt und bestehend aus Benutzertyp und Benutzer-ID. Beispiel: TYPE.ID, client.admin oder client.user1. Der Grund dafür besteht darin, dass Ceph Monitors, OSDs und Metadata Server ebenfalls das cephx-Protokoll verwenden, jedoch keine „clients“ sind. Durch unterschiedliche Benutzertypen wird zwischen Client-Benutzern und anderen Benutzern unterschieden, was die Zugriffskontrolle, die Benutzerüberwachung und Nachverfolgbarkeit verbessert.

Der Benutzertyp von Ceph kann unter Umständen verwirrend erscheinen, da Sie in der Ceph-Kommandozeile einen Benutzer mit oder ohne Typ angeben können, je nach Ihrer Nutzung der Kommandozeile. Bei --user oder --id können Sie den Typ weglassen. client.user1 kann also einfach als user1 eingegeben werden. Bei --name oder -n müssen Sie den Typ und den Namen angeben, z. B. client.user1. Als optimales Verfahren wird empfohlen, nach Möglichkeit stets den Typ und den Namen anzugeben.

Anmerkung
Anmerkung

Ein Ceph Storage Cluster-Benutzer ist nicht dasselbe wie ein Ceph Object Storage-Benutzer oder ein Ceph-Dateisystembenutzer. Das Ceph Object Gateway nutzt einen Ceph Storage Cluster-Benutzer für die Kommunikation zwischen dem Gateway Daemon und dem Storage Cluster, doch das Gateway verfügt über eine eigene Benutzerverwaltungsfunktion für Endbenutzer. Das Ceph-Dateisystem verwendet die POSIX-Semantik. Der damit verknüpfte Benutzerbereich entspricht nicht einem Ceph Storage Cluster-Benutzer.

8.2.1.2 Autorisierung und Capabilities Edit source

Mit dem Begriff „Capabilities“ (Caps) beschreibt Ceph die Autorisierung eines authentifizierten Benutzers zur Ausführung der Funktionalität der Monitors, OSDs und Metadata Servers. Die „Capabilities“ können außerdem den Zugriff auf Daten in einem Pool oder Pool-Namespace einschränken. Ein verwaltungsbefugter Benutzer von Ceph legt die Capabilities eines Benutzers bei dessen Erstellung oder Aktualisierung fest.

Die Syntax der Capabilities entspricht der folgenden Form:

daemon-type 'allow capability' [...]

Hier sehen Sie eine Liste der Capabilities für die einzelnen Service-Typen:

Monitor-Capabilities

sind r, w, x und allow profile cap.

mon 'allow rwx'
mon 'allow profile osd'
OSD-Capabilities

sind r, w, x, class-read, class-write und profile osd. Außerdem sind bei OSD-Capabilities auch Pool- und Namespace-Einstellungen möglich.

osd 'allow capability' [pool=poolname] [namespace=namespace-name]
MDS-Capability

Dafür ist nur allowerforderlich oder es erfolgt kein Eintrag.

mds 'allow'

Die folgenden Einträge beschreiben die einzelnen Capabilities:

allow

Geht den Zugriffseinstellungen für einen Daemon voran. Schließt rw nur für MDS ein.

r

Gewährt Benutzern Lesezugriff. Erforderlich bei Monitors zum Abrufen der CRUSH Map.

w

Gewährt Benutzern Schreibzugriff auf Objekte.

x

Gewährt Benutzern die Capability zum Aufrufen von Klassenmethoden (Lesen und Schreiben) und zur Ausführung von auth-Operationen an Monitors.

class-read

Gewährt Benutzern die Capability zum Aufrufen von Methoden zum Lesen für Klassen. Teilmenge von x.

class-write

Gewährt Benutzern die Capability zum Aufrufen von Methoden zum Schreiben für Klassen. Teilmenge von x.

*

Gewährt Benutzern Lese-, Schreib- und Ausführungsberechtigungen für einen bestimmten Daemon/Pool sowie die Möglichkeit zum Ausführen von Admin-Kommandos.

profile osd

Gewährt Benutzern Berechtigungen zum Herstellen einer Verbindung als OSD mit anderen OSDs oder Monitors. Wird OSDs gewährt, um OSDs die Verarbeitung von Heartbeat-Datenverkehr und Statusberichterstellung für Reproduktionen zu ermöglichen.

profile mds

Gewährt Benutzern Berechtigungen zum Herstellen einer Verbindung als MDS mit anderen MDSs oder Monitors.

profile bootstrap-osd

Gewährt Benutzern Berechtigungen für OSD-Bootstraps. Übertragen an Bereitstellungswerkzeuge, damit diese berechtigt sind, beim Bootstrapping eines OSDs Schlüssel hinzuzufügen.

profile bootstrap-mds

Gewährt Benutzern Berechtigungen für Metadata Server-Bootstraps. Übertragen an Bereitstellungswerkzeuge, damit diese berechtigt sind, beim Bootstrapping eines Metadata Servers Schlüssel hinzuzufügen.

8.2.1.3 Pools Edit source

Ein Pool ist eine logische Partition, in der Benutzer Daten speichern. Bei Ceph-Bereitstellungen ist es üblich, einen Pool als logische Partition für ähnliche Datentypen zu erstellen. Wenn beispielsweise Ceph als Back-End für OpenStack bereitgestellt wird, dann würde eine typische Bereitstellung Pools für Volumes, Images, Sicherungen und virtuelle Maschinen umfassen sowie Benutzer wie client.glance oder client.cinder.

8.2.2 Verwalten von Benutzern Edit source

Die Benutzerverwaltungsfunktion ermöglicht es Ceph Cluster-Administratoren, Benutzer direkt im Ceph Cluster zu erstellen, zu aktualisieren und zu löschen.

Wenn Sie Benutzer im Ceph Cluster erstellen oder löschen, müssen Sie möglicherweise Schlüssel an Clients verteilen, damit diese zu Schlüsselbunden hinzugefügt werden können. Weitere Informationen finden Sie in Abschnitt 8.2.3, „Schlüsselbundverwaltung“.

8.2.2.1 Auflisten von Benutzern Edit source

Führen Sie folgendes Kommando aus, um die Benutzer in Ihrem Cluster aufzulisten:

cephadm@adm > ceph auth list

Ceph listet alle Benutzer in Ihrem Cluster auf. In einem Cluster mit zwei Nodes beispielsweise sieht die Ausgabe von ceph auth list folgendermaßen aus:

installed auth entries:

osd.0
        key: AQCvCbtToC6MDhAATtuT70Sl+DymPCfDSsyV4w==
        caps: [mon] allow profile osd
        caps: [osd] allow *
osd.1
        key: AQC4CbtTCFJBChAAVq5spj0ff4eHZICxIOVZeA==
        caps: [mon] allow profile osd
        caps: [osd] allow *
client.admin
        key: AQBHCbtT6APDHhAA5W00cBchwkQjh3dkKsyPjw==
        caps: [mds] allow
        caps: [mon] allow *
        caps: [osd] allow *
client.bootstrap-mds
        key: AQBICbtTOK9uGBAAdbe5zcIGHZL3T/u2g6EBww==
        caps: [mon] allow profile bootstrap-mds
client.bootstrap-osd
        key: AQBHCbtT4GxqORAADE5u7RkpCN/oo4e5W0uBtw==
        caps: [mon] allow profile bootstrap-osd
Anmerkung
Anmerkung: Schreibweise TYPE.ID

Beachten Sie, dass die Schreibweise TYPE.ID für Benutzer so angewendet wird, dass osd.0 einen Benutzer vom Typ osd und dessen ID 0 bezeichnet. client.admin ist ein Benutzer vom Typ client und seine ID lautet admin. Beachten Sie auch, dass sich jeder Eintrag aus einem Eintrag key: value und einem oder mehreren Einträgen caps: zusammensetzt.

Speichern Sie die Ausgabe mit der Option -o filename und ceph auth list in eine Datei.

8.2.2.2 Abrufen von Informationen zu Benutzern Edit source

Führen Sie folgendes Kommando aus, um einen bestimmten Benutzer, Schlüssel und Capabilities abzurufen:

cephadm@adm > ceph auth get TYPE.ID

Beispiel:

cephadm@adm > ceph auth get client.admin
exported keyring for client.admin
[client.admin]
	key = AQA19uZUqIwkHxAAFuUwvq0eJD4S173oFRxe0g==
	caps mds = "allow"
	caps mon = "allow *"
 caps osd = "allow *"

Entwickler können auch Folgendes ausführen:

cephadm@adm > ceph auth export TYPE.ID

Das Kommando auth export entspricht auth get und gibt außerdem die interne Authentifizierungs-ID aus.

8.2.2.3 Hinzufügen von Benutzern Edit source

Durch Hinzufügen eines Benutzers wird ein Benutzername (TYPE.ID) erstellt sowie ein geheimer Schlüssel und die Capabilities, die im Kommando enthalten sind, mit dem sie den Benutzer erstellen.

Benutzerschlüssel ermöglichen es Benutzern, sich beim Ceph Storage Cluster zu authentifizieren. Durch ihre Capabilities sind Benutzer autorisiert, an Ceph Monitors (mon), Ceph OSDs (osd) oder Ceph Metadata Server (mds) zu lesen, zu schreiben und Vorgänge auszuführen.

Zum Hinzufügen von Benutzern stehen einige Kommandos zur Verfügung:

ceph auth add

Dieses Kommando ist die herkömmliche Methode zum Hinzufügen von Benutzern. Es erstellt den Benutzer, generiert einen Schlüssel und fügt beliebige angegebene Capabilities hinzu.

ceph auth get-or-create

Dieses Kommando ist oft die bequemste Methode zum Erstellen eines Benutzers, weil es ein Schlüsseldateiformat mit dem Benutzernamen (in Klammern) und dem Schlüssel zurückgibt. Wenn der Benutzer bereits vorhanden ist, gibt dieses Kommando einfach den Benutzernamen und den Schlüssel im Schlüsseldateiformat zurück. Speichern Sie die Ausgabe mit der Option -o filename in eine Datei.

ceph auth get-or-create-key

Dieses Kommando ist eine bequeme Methode zum Erstellen eines Benutzers. Es gibt (nur) den Schlüssel des Benutzers zurück. Dies ist nützlich für Clients, die nur den Schlüssel benötigen (beispielsweise libvirt). Wenn der Benutzer bereits vorhanden ist, gibt dieses Kommando einfach den Schlüssel zurück. Speichern Sie die Ausgabe mit der Option -o filename in eine Datei.

Beim Erstellen von Client-Benutzern können Sie auch einen Benutzer ohne Capabilities erstellen. Ein Benutzer ohne Capabilities kann nichts anderes als authentifizieren. Ein derartiger Client kann nicht die Cluster-Zuordnung vom Monitor abrufen. Es ist jedoch möglich, einen Benutzer ohne Capabilities zu erstellen, wenn Sie später Capabilities mit dem Kommando ceph auth caps hinzufügen möchten.

Ein normaler Benutzer verfügt zumindest über Lese-Capabilities für den Ceph Monitor und Lese- und Schreib-Capabilities für Ceph OSDs. Außerdem sind die OSD-Berechtigungen eines Benutzers oft auf den Zugriff auf einen bestimmten Pool beschränkt.

cephadm@adm > ceph auth add client.john mon 'allow r' osd \
 'allow rw pool=liverpool'
cephadm@adm > ceph auth get-or-create client.paul mon 'allow r' osd \
 'allow rw pool=liverpool'
cephadm@adm > ceph auth get-or-create client.george mon 'allow r' osd \
 'allow rw pool=liverpool' -o george.keyring
cephadm@adm > ceph auth get-or-create-key client.ringo mon 'allow r' osd \
 'allow rw pool=liverpool' -o ringo.key
Wichtig
Wichtig

Wenn Sie einem Benutzer die Capabilities für OSDs gewähren, aber nicht den Zugriff auf bestimmte Pools beschränken, dann hat der Benutzer Zugriff auf alle Pools im Cluster.

8.2.2.4 Bearbeiten der Capabilities für Benutzer Edit source

Mit dem Kommando ceph auth caps können Sie einen Benutzer angeben und die Capabilities dieses Benutzers ändern. Wenn Sie neue Capabilities festlegen, werden die aktuellen damit überschrieben. Führen Sie das Kommando ceph auth get USERTYPE aus, um die aktuellen Capabilities anzuzeigen.USERID. Zum Hinzufügen von Capabilities müssen Sie auch die bestehenden Capabilities angeben, wenn Sie folgende Form verwenden:

cephadm@adm > ceph auth caps USERTYPE.USERID daemon 'allow [r|w|x|*|...] \
     [pool=pool-name] [namespace=namespace-name]' [daemon 'allow [r|w|x|*|...] \
     [pool=pool-name] [namespace=namespace-name]']

Beispiel:

cephadm@adm > ceph auth get client.john
cephadm@adm > ceph auth caps client.john mon 'allow r' osd 'allow rw pool=prague'
cephadm@adm > ceph auth caps client.paul mon 'allow rw' osd 'allow r pool=prague'
cephadm@adm > ceph auth caps client.brian-manager mon 'allow *' osd 'allow *'

Zum Entfernen einer Capability können Sie diese zurücksetzen. Wenn der Benutzer auf einen bestimmten Daemon, auf den er vorher zugreifen konnte, keinen Zugriff mehr haben soll, geben Sie eine leere Zeichenkette an:

cephadm@adm > ceph auth caps client.ringo mon ' ' osd ' '

8.2.2.5 Löschen von Benutzern Edit source

Einen Benutzer löschen Sie mit ceph auth del:

cephadm@adm > ceph auth del TYPE.ID

Dabei steht TYPE für client, osd, mon oder mds und ID ist der Benutzername oder die ID des Daemon.

Wenn Sie Benutzer mit Berechtigungen genau für einen Pool erstellt haben, der nicht mehr vorhanden ist, sollten Sie diese Benutzer ebenfalls löschen.

8.2.2.6 Ausgabe des Benutzerschlüssels Edit source

Führen Sie folgendes Kommando aus, um die Authentifizierungsschlüssel eines Benutzers in der Standardausgabe auszugeben:

cephadm@adm > ceph auth print-key TYPE.ID

Dabei steht TYPE für client, osd, mon oder mds und ID ist der Benutzername oder die ID des Daemon.

Die Ausgabe eines Benutzerschlüssels ist nützlich, wenn Sie in einer Client-Software einen Benutzerschlüssel (wie zum Beispiel libvirt) angeben müssen. Beispiel:

root # mount -t ceph host:/ mount_point \
-o name=client.user,secret=`ceph auth print-key client.user`

8.2.2.7 Importieren von Benutzern Edit source

Importieren Sie einen oder mehrere Benutzer mit ceph auth import und geben Sie einen Schlüsselbund an:

cephadm@adm > ceph auth import -i /etc/ceph/ceph.keyring
Anmerkung
Anmerkung

Der Ceph Storage Cluster fügt neue Benutzer, deren Schlüssel und Capabilities hinzu und aktualisiert bestehende Benutzer, deren Schlüssel und Capabilities.

8.2.3 Schlüsselbundverwaltung Edit source

Wenn Sie über einen Ceph Client auf Ceph zugreifen, sucht der Cient nach einem lokalen Schlüsselbund. Ceph legt standardmäßig in der Schlüsselbundeinstellung vorab die folgenden vier Schlüsselbundnamen fest. Sie müssen diese daher nicht in der Ceph-Konfigurationsdatei festlegen, es sei denn, Sie möchten die Standardwerte überschreiben:

/etc/ceph/cluster.name.keyring
/etc/ceph/cluster.keyring
/etc/ceph/keyring
/etc/ceph/keyring.bin

Die Metavariable cluster ist Ihr Ceph Cluster-Name, der durch den Namen in der Ceph-Konfigurationsdatei definiert ist. ceph.conf bedeutet, dass der Cluster-Name ceph lautet, was ceph.keyring ergibt. Die Metavariable name ist der Benutzertyp und die Benutzer-ID, wie zum Beispiel client.admin, was ceph.client.admin.keyring ergibt.

Nach Erstellung eines Benutzers (zum Beispiel client.ringo) müssen Sie den Schlüssel abrufen und diesen zu einem Schlüsselbund auf einem Ceph Client hinzufügen, sodass der Benutzer Zugriff auf den Ceph Storage Cluster hat.

In Abschnitt 8.2, „Schlüsselverwaltung“ finden Sie detaillierte Informationen zum Auflisten, Abrufen, Hinzufügen, Bearbeiten und Löschen von Benutzern direkt im Ceph Storage Cluster. Ceph stellt jedoch auch das ceph-authtool-Dienstprogramm zur Verfügung, mit dem Schlüsselbunde von einem Ceph Client aus verwaltet werden.

8.2.3.1 Erstellen eines Schlüsselbunds Edit source

Wenn Sie zum Erstellen von Benutzern wie in Abschnitt 8.2, „Schlüsselverwaltung“ beschrieben vorgehen, dann müssen Sie den Ceph Clients Benutzerschlüssel zur Verfügung stellen. Die Clients rufen den Schlüssel für den angegebenen Benutzer ab und authentifizieren diesen im Ceph Storage Cluster. Ceph Clients greifen auf Schlüsselbunde zu, um einen Benutzernamen zu ermitteln und den Schlüssel des Benutzer abzurufen:

cephadm@adm > ceph-authtool --create-keyring /path/to/keyring

Wir empfehlen, beim Erstellen eines Schlüsselbunds mit mehreren Benutzern den Cluster-Namen (beispielsweise cluster.keyring) als Schlüsselbunddateinamen zu verwenden und diesen im Verzeichnis /etc/ceph zu speichern. Die Standardeinstellung der Schlüsselbundkonfiguration übernimmt den Dateinamen, ohne dass Sie diesen in der lokalen Kopie Ihrer Ceph-Konfigurationsdatei angeben müssen. Erstellen Sie beispielsweise ceph.keyring mit dem folgenden Kommando:

cephadm@adm > ceph-authtool -C /etc/ceph/ceph.keyring

Wir empfehlen, beim Erstellen eines Schlüsselbunds für einen einzelnen Benutzer den Cluster-Namen, den Benutzertyp und Benutzernamen zu verwenden und im Verzeichnis /etc/ceph zu speichern. Beispielsweise ceph.client.admin.keyring für den client.admin-Benutzer.

8.2.3.2 Hinzufügen eines Benutzers zu einem Schlüsselbund Edit source

Beim Hinzufügen eines Benutzers zum Ceph Storage Cluster (weitere Informationen hierzu finden Sie in Abschnitt 8.2.2.3, „Hinzufügen von Benutzern“) können Sie den Benutzer, den Schlüssel und die Capabilities abrufen und den Benutzer in einem Schlüsselbund speichern.

Wenn Sie nur einen Benutzer pro Schlüsselbund verwenden möchten, dann speichern Sie die Ausgabe im Schlüsselbunddateiformat mit dem Kommando ceph auth get und der Option -o. Führen Sie beispielsweise zum Erstellen eines Schlüsselbunds für den client.admin-Benutzer folgendes Kommando aus:

cephadm@adm > ceph auth get client.admin -o /etc/ceph/ceph.client.admin.keyring

Wenn Sie Benutzer in einen Schlüsselbund importieren möchten, dann geben Sie mit ceph-authtool den Ziel-Schlüsselbund und den Ursprungs-Schlüsselbund an:

cephadm@adm > ceph-authtool /etc/ceph/ceph.keyring \
  --import-keyring /etc/ceph/ceph.client.admin.keyring

8.2.3.3 Erstellen von Benutzern Edit source

Ceph stellt das Kommando ceph auth add zum Erstellen eines Benutzers direkt im Ceph Storage Cluster zur Verfügung. Sie können jedoch auch einen Benutzer, die Schlüssel und Capabilities direkt im Ceph Client-Schlüsselbund erstellen. Danach importieren Sie den Benutzer im Ceph Storage Cluster:

cephadm@adm > ceph-authtool -n client.ringo --cap osd 'allow rwx' \
  --cap mon 'allow rwx' /etc/ceph/ceph.keyring

Es ist auch möglich, einen Schlüsselbund zu erstellen und gleichzeitig einen neuen Benutzer zum Schlüsselbund hinzuzufügen:

cephadm@adm > ceph-authtool -C /etc/ceph/ceph.keyring -n client.ringo \
  --cap osd 'allow rwx' --cap mon 'allow rwx' --gen-key

In den obigen Szenarien ist der neue Benutzer client.ringo nur im Schlüsselbund vorhanden. Zum Hinzufügen des neuen Benutzers zum Ceph Storage Cluster müssen Sie den neuen Benutzer noch zum Cluster hinzufügen:

cephadm@adm > ceph auth add client.ringo -i /etc/ceph/ceph.keyring

8.2.3.4 Bearbeiten von Benutzern Edit source

Geben Sie zum Bearbeiten der Capabilities eines Benutzerdatensatzes in einem Schlüsselbund den Schlüsselbund und den Benutzer gefolgt von den Capabilities an:

cephadm@adm > ceph-authtool /etc/ceph/ceph.keyring -n client.ringo \
  --cap osd 'allow rwx' --cap mon 'allow rwx'

Zum Aktualisieren des bearbeiteten Benutzers in der Ceph Cluster-Umgebung müssen Sie die Änderungen aus dem Schlüsselbund in den Benutzereintrag im Ceph Cluster importieren:

cephadm@adm > ceph auth import -i /etc/ceph/ceph.keyring

Detaillierte Informationen zum Aktualisieren eines Benutzers im Ceph Storage Cluster von einem Schlüsselbund aus finden Sie in Abschnitt 8.2.2.7, „Importieren von Benutzern“.

8.2.4 Verwendung der Kommandozeile Edit source

Das Kommando ceph unterstützt die folgenden Optionen in Bezug auf die Bearbeitung von Benutzername und Geheimnis:

--id oder --user

Ceph kennzeichnet Benutzer mit einem Typ und einer ID (TYPE.ID, wie client.admin oder client.user1). Mit den Optionen id, name und -n geben Sie den ID-Teil des Benutzernamens an (beispielsweise admin oder user1). Sie können den Benutzer mit ‑‑id angeben und den Typ auslassen. Geben Sie beispielsweise zum Angeben des Benutzers "client.foo" Folgendes ein:

cephadm@adm > ceph --id foo --keyring /path/to/keyring health
cephadm@adm > ceph --user foo --keyring /path/to/keyring health
--name oder -n

Ceph kennzeichnet Benutzer mit einem Typ und einer ID (TYPE.ID, wie client.admin oder client.user1). Die Optionen --name und -n ermöglichen es Ihnen, den vollständigen Benutzernamen anzugeben. Sie müssen den Benutzertyp angeben (normalerweise client) mit der Benutzer-ID:

cephadm@adm > ceph --name client.foo --keyring /path/to/keyring health
cephadm@adm > ceph -n client.foo --keyring /path/to/keyring health
--keyring

Der Pfad zum Schlüsselbund mit einem oder mehreren Benutzernamen und Geheimnissen. Die Option --secret hat zwar dieselbe Funktion, funktioniert jedoch nicht bei Object Gateway, weil dort --secret einem anderen Zweck dient. Es ist möglich, einen Schlüsselbund mit ceph auth get-or-create abzurufen und ihn lokal zu speichern. Diese Vorgehensweise wird bevorzugt, weil Sie Benutzernamen wechseln können, ohne den Schlüsselbundpfad zu ändern:

cephadm@adm > rbd map --id foo --keyring /path/to/keyring mypool/myimage
Diese Seite drucken