Seit Jahren erwartet, ist endlich Version 4 des Samba-Servers erschienen, der nun als vollwertige Alternative zu Microsofts Active Directory dienen kann. In der ... (mehr)

Separate Pools für separate Benutzer

Pools gelten in Ceph als eine Art Namensschild. Während sie sich auf die interne Organisation des Object Stores nicht auswirken, erlauben sie doch das Zuordnen einzelner Objekte zu bestimmten Benutzern. Erst im CephX-Kontext können sie ihre Fähigkeiten voll zum Einsatz bringen, denn es spricht nichts dagegen, für einzelne Benutzer oder Benutzergruppen eigene Pools anzulegen und den Zugriff auf den Speicher auf diesen Pool zu beschränken.

Um dieses Konzept in die Realität umzusetzen, braucht es zunächst freilich einen Pool. Auch dessen Konfiguration funktioniert etwas anders, wenn CephX bereits aktiv ist. Der Befehl »ceph osd pool create test 1000« würde wieder daran scheitern, dass der Benutzer, der den Befehl ausführt, selbst nicht als Admin in Ceph agiert. Analog zum Beispiel von »ceph -w« funktioniert auch hier der Befehl »ceph --id admin --keyring /etc/ceph/keyring.admin osd pool create test 1000« . Der Befehl liefert keine Ausgabe, gibt aber » « zurück. Im Zweifel lässt sich der Erfolg also mit »echo $?« überprüfen.

Der Pool ist da – es fehlt noch der Benutzer, der ihn exklusiv verwenden darf. Das Usermanagement in Ceph hat in den letzten Monaten einige Änderungen im Hinblick auf Zusatzfunktionen erfahren, große Teile der im Netz zu findenden Dokumentation sind veraltet. Wichtig ist zunächst: Für jeden Nutzer gibt es auf den Ceph-Hosts üblicherweise ein Keyring-File (im Beispiel des Admin-Benutzer »/etc/ceph/keyring.admin« ). Das ist allerdings eben gerade nicht die Datei, die Ceph zum Prüfen von Nutzerberechtigungen verwendet Stattdessen pflegen die MON-Server für diesen Zweck einen eigenen, internen Keyring. Soll ein Benutzer zur Ceph-Installation hinzustoßen, genügt es aus diesem Grund auch nicht, eine Keyring-Datei auf den Ceph-Hosts in der Datei »/etc/ceph« zu hinterlegen. Zusätzlich muss der Admin den Key auch mittels »ceph auth add« in den Cluster integrieren. Alternativ dazu lassen sich die beiden Arbeitsschritte auch in einem einzigen Befehl zusammenfassen. Um zum Beispiel für einen Benutzer namens »test« einen Schlüssel anzulegen und diesen dann gleich in Ceph zu aktivieren, reicht dieses Kommando:

ceph --id admin --keyring /etc/ceph/keyring.admin authget-or-create client.test $$
  mds 'allow' osd 'allow * pool=test' mon 'allow *' > /etc/ceph/keyring.test

Der Befehl funktioniert nur dann sinnvoll, wenn vorher tatsächlich schon ein Pool namens »test« existiert. Anschließend enthält »/etc/ceph/keyring.test« den Keyring des Benutzers, der ausschließlich auf den Pool »test« zugreifen darf. Würde dieser Benutzer versuchen, auf einen anderen Pool zuzugreifen, so würde Ceph das mit einer Permission-Denied-Fehlermeldung verweigern.

Berechtigungen anpassen

Es ist auch möglich, einmal zugewiesene Credentials nachträglich zu ändern und anzupassen (Abbildung 2). Die öffentliche Dokumentation hierzu ist leider unvollständig, so klappt es trotzdem: Zunächst ist Sorge dafür zu tagen, dass der Keyring des Benutzers die neuen, vollständigen Credentials enthält. Der Keyring für den zuvor angelegten »test« -Nutzer in »/etc/keyring/keyring.test« könnte direkt nach dem Anlegen so aussehen:

Abbildung 2: Wer nachträglich die Berechtigungen eines Nutzers verändern will, tut das mittels des Keyring-Files in /etc/ceph.
[client.test]
   key = AQA5XRZRUPvHABAABBkwuCgELluyyXSSYc5Ajw==

Ceph weiß, dass dieser Benutzer auf den Pool »test« zugreifen darf, im Befehl zum Anlegen des Nutzers war das ja ausdrücklich vermerkt. Wenn dieser Nutzer nun auch Zugriff auf den Pool »test2« erhalten soll, wäre das File in »/etc/ceph/keyring.test« so abzuändern:

[client.test]
   key = AQA5XRZRUPvHABAABBkwuCgELluyyXSSYc5Ajw==
   caps osd = "allow * pool=test, allow *     pool=test2"
   caps mds = "allow"
   caps mon = "allow *"

Wichtig ist, dass der Eintrag hinter »key =« unverändert bleibt, sonst würden andere Anwendungen nicht mehr mit Ceph kommunizieren können, wenn diese den Ceph-Schlüssel statisch konfiguriert haben. Schließlich informiert der Admin Ceph noch über die Änderung, indem er den neuen Schlüssel in den internen Ceph-Schlüsselbund einpflegt:

ceph --id admin -k /etc/ceph/keyring.admin auth add client.test-i /etc/ceph/keyring.test

Im Anschluss hat der Benutzer »test« Zugriffsberechtigungen sowohl für den Pool »test« wie auch für den Pool »test2« .

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019