Zum Hauptinhalt springen
Administration · Objektspeicher

MinIO-Bucket verwalten

Stellen Sie einen Bucket über den vorgesehenen UDSP-Weg bereit, begrenzen Sie den Zugriff mit bucketbezogenen Rollen und prüfen Sie Schutz, Aufbewahrung und technische Zugänge.

Für einen abgestimmten Zweck existiert ein eindeutig benannter Bucket. Benutzer oder Anwendungen können darin mit einer bucketbezogenen Rolle arbeiten, ohne Zugriff auf alle Buckets des Mandanten zu erhalten. Bucket, Policies, Aufbewahrung und verantwortliche Stelle sind dokumentiert.

Planung

Zweck und Schutz klären

Inhalte, Verantwortlichkeit, Aufbewahrung und benötigte Operationen sind entschieden.

Bereitstellung

Bucket anlegen

Der Bucket wird bevorzugt über die Plattformkonfiguration oder begründet in der Konsole erstellt.

Zugriff

Rollen bereitstellen

Bucketbezogene Policies und technische Zugänge werden auf die benötigten Operationen begrenzt.

Abnahme

Rollen testen

Lesen, Hochladen, Überschreiben und Löschen funktionieren nur wie vorgesehen.

Zuerst den Bereitstellungsweg wählen​

Empfohlener Regelweg

Über die UDSP-Konfiguration

Ein dauerhaft benötigter Bucket wird im Mandanten-Inventory ergänzt. Der Rollout erzeugt Bucket, Policies und zugehörige Keycloak-Rollen gemeinsam.

Konfiguration öffnen
Vorhandene Ablage

Bestehenden Bucket nutzen

Existiert bereits ein Bucket für denselben Zweck, wird dieser mit der passenden bucketbezogenen Rolle weiterverwendet.

Nutzung öffnen
Begründete Ausnahme

In der Konsole anlegen

Ein consoleAdmin kann einen Bucket unmittelbar anlegen. Die UDSP-spezifischen Rollen entstehen dabei jedoch nicht automatisch.

Für den Regelbetrieb ist der konfigurierte Weg vorzuziehen. Im aktuellen Plattformcode erzeugt der Rollout für jeden Eintrag unter tenant.minio.tenant.buckets neben dem Bucket auch die Policies und Keycloak-Client-Rollen read_<BUCKET>, readcreate_<BUCKET> und readwrite_<BUCKET>.

Ein manuell angelegter Bucket ist noch nicht übergabefertig

Die MinIO-Konsole kennt das UDSP-Inventory nicht. Wird dort ein Bucket erstellt, fehlen zunächst die automatisch erzeugten bucketbezogenen Policies und Keycloak-Rollen. Verwenden Sie diesen Weg nur, wenn die Betriebsstelle den Bucket anschließend in die verwaltete Konfiguration übernimmt oder die benötigten Policies ausdrücklich ergänzt. Andernfalls könnten nur weitreichende mandantenweite Rollen auf die Ablage zugreifen.

Voraussetzungen​

  • den MinIO-Konsolenzugang des Mandanten unter https://minio.<MANDANTENDOMAIN>,
  • consoleAdmin zum manuellen Erstellen eines Buckets oder eine bereits bereitgestellte bucketbezogene Rolle,
  • einen abgestimmten Bucketnamen und Zweck,
  • Vorgaben für erlaubte Dateitypen, maximale Objektgröße, Aufbewahrung und Löschung sowie
  • bei technischen Anwendungen einen eigenen S3-Zugang statt persönlicher Anmeldedaten.

1. Bucket in der MinIO-Konsole anlegen​

Dieser Schritt ist nur erforderlich, wenn der Bucket nicht über das Inventory bereitgestellt wurde und die manuelle Anlage ausdrücklich vorgesehen ist:

Vergeben Sie einen stabilen, kleingeschriebenen Namen mit Bindestrichen, beispielsweise mobilitaet-rohdaten. Vermeiden Sie Personen-, Projektphasen- oder Jahresnamen, wenn der fachliche Zweck dauerhaft bleibt. Legen Sie vor der Erstellung fest, ob Versionierung, Object Locking, eine Quota oder Retention benötigt werden. Retention setzt Versionierung voraus; Object Locking ist eine bewusste Schutzentscheidung und darf nicht testweise aktiviert werden. Die jeweils aktuellen Bedienelemente beschreibt die offizielle MinIO-Dokumentation.

Der Name wird Bestandteil von Rollen, S3-Pfaden und Anwendungskonfigurationen. Eine spätere Umbenennung entspricht technisch einer Migration in einen neuen Bucket.

2. Zugriff passend vergeben​

Weisen Sie Benutzern und Gruppen in Keycloak die kleinste passende Rolle des MinIO-Clients zu:

Bucket-Rolle

read_<BUCKET>

Objekte auflisten und herunterladen. Hochladen, Überschreiben und Löschen bleiben gesperrt.

Bucket-Rolle

readcreate_<BUCKET>

Objekte lesen, hochladen und mit Tags versehen. Ein allgemeines Löschen vorhandener Objekte ist nicht vorgesehen.

Bucket-Rolle

readwrite_<BUCKET>

Objekte lesen, hochladen, überschreiben und löschen. Nur für Aufgaben mit tatsächlicher Pflegeverantwortung verwenden.

consoleAdmin, read, readwrite und writeonly wirken mandantenweit und sind keine geeignete Abkürzung für eine fachliche Bucketfreigabe. Die vollständige Einordnung steht unter MinIO: Rollen und Rechte.

HYPERSENSUS-Zugriff mit der eingesetzten Version abnehmen

Die bucketbezogenen Keycloak-Rollen und ihre Auswertung in HYPERSENSUS müssen versionsabhängig zusammenpassen. Leiten Sie aus einer sichtbaren Upload-Aktion oder einem sichtbaren Bucket keine korrekte Rollenwirkung ab. Testen Sie Sichtbarkeit, Lesen und Schreiben mit einem Konto der tatsächlichen Zielgruppe. Fehlt die Wirkung, korrigieren Sie Rollenabbildung oder Produktkonfiguration; vergeben Sie nicht ersatzweise eine mandantenweite Rolle.

3. Bucket für die Nutzung abnehmen​

Prüfen Sie die Bereitstellung mit der tatsächlich vorgesehenen bucketbezogenen Rolle und nicht nur als consoleAdmin:

  • Der Bucket ist sichtbar, andere fachliche Buckets bleiben verborgen.
  • Lesen, Hochladen, Überschreiben und Löschen funktionieren genau entsprechend der zugewiesenen Rolle.
  • Größenbegrenzung, Versionierung, Aufbewahrung und Löschung entsprechen der abgestimmten Vorgabe.
  • Ein technischer Prozess erhält eigene S3-Credentials und verwendet keine persönlichen Zugangsdaten.
  • Ein Testobjekt lässt sich über den vorgesehenen externen Zugang verarbeiten und anschließend kontrolliert entfernen.

Das Bereitstellen und Prüfen einer Quelldatei für Node-RED beschreibt Datenquelle prüfen. Ein durch einen Datenfluss erzeugtes Objekt kontrollieren Benutzer unter Dateien und Lieferstände prüfen. Technische S3-Zugänge werden unter Technische Zugänge verwalten eingeordnet.

Die im Plattform-Inventory konfigurierte Option max_file_size begrenzt Uploads am externen Ingress. Ein HTTP-Status 413 Request Entity Too Large weist typischerweise darauf hin, dass die Datei diese Grenze überschreitet. Die Grenze wird über den technischen Bereitstellungsweg geändert und nicht in der MinIO-Konsole.

Abnahme​

  • Bucketname und Zweck sind eindeutig und dokumentiert.
  • Die Zielrolle sieht nur die vorgesehenen Buckets.
  • read_<BUCKET> kann lesen, aber nicht hochladen oder löschen.
  • readcreate_<BUCKET> kann hochladen, aber keine vorhandenen Objekte allgemein löschen.
  • readwrite_<BUCKET> wird nur bei begründetem Änderungs- und Löschbedarf vergeben.
  • Eine erlaubte Objektoperation funktioniert über den vorgesehenen externen Zugang; gesperrte Operationen werden abgewiesen.
  • Maximalgröße, Versionierung, Aufbewahrung und Löschung sind geklärt.
  • Technische Anwendungen verwenden eigene S3-Credentials.

Referenzen​