Zum Inhalt

Object Storage (S3)

S3-kompatible Buckets der Plattform — anlegen, belegen, Inhalte listen. Backend ist ein S3-Cluster in einer Region (Ceph RGW, MinIO, RustFS). Nicht an einen Managed-Service-Vertrag gebunden: UI, REST und Kubernetes-CR nutzen dieselbe API.

Komponenten: Object Storage · API-Referenz: S3 Buckets.

Bucket anlegen

Drei Wege, ein Lifecycle (Bucket + IAM-User + Credentials):

1. Polycrate-API-UI

Storage → S3 Buckets → New

Feld Bedeutung
Name DNS-konformer Bucket-Name
Region wird auf einen S3-Cluster aufgelöst
Organization / Workspace Zuordnung
CORS Allow All optional für Browser-Uploads

Nach dem Speichern: Bucket auf dem Cluster, Access/Secret Key (einmalig in der Create-Response / Tab Credentials → Reveal).

2. REST API

POST /api/v1/s3/buckets/
{
  "name": "my-app-data",
  "region": "eu-central",
  "organization": "<org-uuid>",
  "workspace": "<workspace-uuid>"
}

CLI-Zugang: Polycrate API — Erste Schritte.

3. Kubernetes CR (Operator)

apiVersion: polycrate.io/v1alpha1
kind: S3Bucket
metadata:
  name: my-app-data
  namespace: my-app
spec:
  region: eu-central
  corsAllowAll: false

Der Operator legt den Bucket in der API an und schreibt ein Secret (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_ENDPOINT_URL_S3, BUCKET_NAME). GitOps: CR ins App-Manifest, App via envFrom.

Existiert Name+Region schon, wird der Bucket adoptiert.

Belegung und Billing

Die API zieht periodisch Provider-Statistiken (Ceph-Telemetry / MinIO Admin):

In der UI Quelle
Belegung (Bytes) Capacity-Tracking pro Bucket
Object Count Anzahl Objekte
Cluster-Belegung Aggregat der Region / des S3-Clusters

Pfad: Storage → S3 Buckets (Tabellen-Spalten) und Bucket-Detail (Metriken). Dieselben Werte fließen in die Pricing-Schicht und Prometheus-Metriken.

Inhalte anzeigen

Es gibt keinen vollständigen Object-Browser in der API. Listing und Download über S3-API mit den Bucket-Credentials:

mc alias set ayedo "$S3_ENDPOINT" "$AWS_ACCESS_KEY_ID" "$AWS_SECRET_ACCESS_KEY"
mc ls ayedo/$BUCKET_NAME/
mc ls --recursive ayedo/$BUCKET_NAME/
mc du ayedo/$BUCKET_NAME/
mc cat ayedo/$BUCKET_NAME/path/to/object

Endpoint und Keys: UI-Tab Credentials, Create-Response, oder das Operator-Secret. Presigned Upload: POST /api/v1/s3/buckets/{id}/objects/upload-url/ — siehe S3 Buckets.

CNPG-Backup-Layout und mc-Beispiele: Backup & Restore.

Private / cluster-scoped Buckets

Muster Beschreibung
Cluster-internes S3 Ceph RGW oder RustFS im Cluster; Endpoint oft nur aus dem Cluster-/VPN-Netz erreichbar
Tenant-Bucket eigener Bucket (oder Prefixe) pro Namespace/App; Credentials als Secret
Öffentliches Internet nur wenn explizit freigeschaltet (Ingress/Edge + Policies) — Default ist privat

Typische Verbraucher: Velero, CloudNativePG Barman, App-Uploads, SFTPGo-Backend.

# Beispiel: Endpoint und Credentials aus dem Secret der Managed App
kubectl get secret <s3-credentials> -n <namespace> -o yaml

Verbinde Clients mit:

  • Endpoint-URL (HTTPS bevorzugt)
  • Access Key / Secret Key (oder STS, falls bereitgestellt)
  • Bucket-Name und optional Region/Path-Style laut Übergabe

SFTPGo + S3

SFTPGo als Managed App oder Workload kann Object Storage als Storage-Backend nutzen:

  1. privaten Bucket und IAM-/Key-Credentials bereitstellen
  2. SFTPGo auf S3-Backend konfigurieren (Endpoint, Bucket, Prefix)
  3. virtuelle SFTP-User auf Verzeichnisse/Prefixes mappen
  4. Netzwerk: SFTP-Ingress nur über vereinbarte Edge-/VPN-Pfade
Schicht Verantwortung
S3-Backend-Betrieb ayedo (Managed) bzw. vereinbarter Scope
Bucket-Inhalte, User, Quotas in SFTPGo Kunde (soweit Self-Service)
TLS/SSH-Keys der SFTP-User Kunde

Backups der Dateien hängen am Backend und an der vereinbarten Backup-Policy — Defaults siehe Leistungsanhang zu den AGB.

Sicherheit

  • keine öffentlichen ACLs auf Buckets mit Kundendaten
  • Keys rotieren bei Personalwechsel
  • Network Policies: nur SFTPGo-/App-Namespaces zum S3-Endpoint
  • Audit: Transfer-Logs in SFTPGo; Object-Zugriffe je nach Backend

Weiterführend