Quickstart — self-hosted Zelle

Bring eine einzelne OpenDome-Zelle zum Laufen, die die OSL-API bereitstellt, ohne Control-Plane und ohne Phone-home. Das ist der Weg, den ein Self-Hoster geht; das Managed-/Enterprise-Produkt legt die zentrale Control-Plane und Konsole obendrauf — auf exakt dieselben Charts.

Voraussetzungen

Ein Kubernetes-Cluster (kind genügt) mit:
- Einem CNI, das NetworkPolicy durchsetzt — Cilium empfohlen. Das Standard-kindnet von kind setzt es nicht durch. Mit Cilium installiere es mit --set 'policyCIDRMatchMode={nodes}'; ohne das ignoriert Cilium die ipBlock-Regeln, die Node-/Apiserver-IPs abdecken, und der gebündelte Postgres läuft bei „Setting up primary“ in einen Deadlock. (scripts/cluster-create.sh erledigt das für dich auf kind.)
- Einem Ingress-Controller, um die OSL-API zu erreichen.
- Einer Standard-StorageClass (für die PVCs des gebündelten Object Store + Postgres).
- Dem CloudNativePG-Operator, cluster-weit installiert — nur wenn du den gebündelten Postgres verwendest.
helm ≥ 3.12 und kubectl.

Für ingress-nginx installiere es so, dass jeder vom Client gelieferte X-Actor-Roles am Edge entfernt wird (Defense in Depth — die Engine ignoriert den Header im Standalone-Betrieb ohnehin):

helm install ingress-nginx ingress-nginx/ingress-nginx \
  -n ingress-nginx --create-namespace --version 4.11.3 \
  --set-string 'controller.proxySetHeaders.X-Actor-Roles='

Wenn du den gebündelten Postgres verwendest, installiere zuerst CloudNativePG:

helm install cnpg cnpg/cloudnative-pg \
  -n cnpg-system --create-namespace --version 0.27.1

Die Zelle hochfahren

Die Zellen-Shell + gebündelte Infra (Object Store + Postgres).

standard-tenant erstellt den Namespace, eine deny-all NetworkPolicy (keine Allow-Regeln zur Control-Plane), Quotas und — im Standalone-Profil — einen Object Store im Namespace (RustFS) sowie einen CloudNativePG-Postgres, plus das Secret tenant-object-storage.

# The deny-all NetworkPolicy only lets pods reach the Kubernetes API through
# this allowlist (CNPG's init needs it). Derive both addresses from YOUR
# cluster — no per-distro guessing:
APISERVER_VIP=$(kubectl get svc kubernetes -o jsonpath='{.spec.clusterIP}')
APISERVER_EP=$(kubectl get endpoints kubernetes -o jsonpath='{.subsets[0].addresses[0].ip}')

helm install demo charts/standard-tenant \
  -n tenant-demo --create-namespace \
  --set tenant=demo \
  --set "apiServerEgress.cidrs[0]=$APISERVER_VIP/32" \
  --set "apiServerEgress.endpointCidrs[0]=$APISERVER_EP/32"

Ohne explizite Werte erzeugt der Chart bei der ersten Installation zufällige Credentials und verwendet sie bei Upgrades wieder. Hole sie jederzeit ab:

kubectl -n tenant-demo get secret tenant-object-storage -o jsonpath='{.data.accessKey}' | base64 -d
kubectl -n tenant-demo get secret postgres-postgresql   -o jsonpath='{.data.password}'  | base64 -d

Die OSL-Engine — die Konsum-Oberfläche.
Ventana de terminal
```
helm install osl charts/tenant-semantic-api \
  -n tenant-demo \
  --set tenant.id=demo \
  --set ingress.host=osl.tenant-demo.127.0.0.1.nip.io
```
Dies aktiviert den Opt-in-Ingress und rendert das OSL-Manifest lokal aus den Values. Im Standalone-Profil vertraut die Engine dem Header X-Actor-Roles nicht — ein Aufrufer über einen öffentlichen Ingress kann keine Rollen fälschen. ACL-geschützter Zugriff läuft über den lokalen Token-Issuer: Der Chart erzeugt ein Signing-Secret und die Engine validiert Authorization: Bearer HS256-Tokens.

Prüfe, dass die Zelle über ihre API nutzbar ist — ohne Control-Plane.

HOST=osl.tenant-demo.127.0.0.1.nip.io
curl -fsS "http://$HOST/health"            # {"status":"ok",...}
curl -fsS "http://$HOST/osl/conformance"   # engine + conformance levels
curl -fsS "http://$HOST/osl/schema"        # compiled manifest (empty until you author facets)

Erzeuge ein lokal signiertes Token und mache einen gesteuerten Aufruf.

Die Rollen des Tokens steuern die ACL — die Facetten honorieren sie serverseitig.
Ventana de terminal
```
TOKEN=$(scripts/osl-token.sh demo --roles analyst)
curl -fsS -H "Authorization: Bearer $TOKEN" "http://$HOST/osl/schema"
```
Ein ungültiges oder abgelaufenes Token ist ein hartes 401 (E3001). Die Engine stuft ein defektes Token niemals stillschweigend auf „anonym“ herab.

Wenn diese 200 zurückgeben, ohne dass der Namespace opendome-system vorhanden ist, ist die Zelle standalone-nutzbar. Führe scripts/oss-gate.sh aus, um dies Ende-zu-Ende zu bestätigen.

Optionale Schichten

Strukturiertes Bein (Trino + Nessie + Iceberg) — charts/lakehouse. Standardmäßig Endpoints im Namespace mit Credentials aus dem Secret tenant-object-storage; benötigt den gebündelten/externen Postgres aus Schritt 1.
Config-API (allowlist / pipeline / discovery) — charts/tenant-config. Bereits standalone: Nutzt den eigenen Postgres der Zelle + eine direkte GET/PUT /config/{key}-API.
Ingest / Orchestrierung — charts/dagster. Standardmäßig: keine Control-Plane-Callbacks, keine Upstream-Telemetrie, Jobs laufen in diesem Namespace.

Images in deine eigene Registry neu bauen

Veröffentlichte Charts pinnen Images per unveränderlichem Digest (image.digest: sha256:…), das Vorrang vor dem Tag hat. Dieser Digest identifiziert OpenDomes veröffentlichtes Image — er ist in jeder anderen Registry bedeutungslos. Wenn du die Zellen-Images in deine eigene Registry neu baust, lösche den ausgelieferten Digest, sonst geht jeder Pod in ImagePullBackOff:

helm install osl charts/tenant-semantic-api \
  --set image.repository=myreg.example/tenant-semantic-api \
  --set image.digest=""          # ← REQUIRED when you change the repository

Mache dasselbe für tenant-mgmt-api.runnerImages.*. Wenn du OpenDomes veröffentlichte Images pullst, lass den Digest wie ausgeliefert und führe cosign verify darauf aus.

Echte Daten laden

Um echte Retrievals bereitzustellen: Erstelle den Bucket (tenant-demo) in deinem Object Store, autoriere OSL-Facetten (UnstructuredFacet / JointEntity YAML unter manifest.facets der Engine) und ingestiere Lance-Datasets nach s3://tenant-demo/lance. Siehe Konzepte für das Manifest-Modell und die API-Referenz dazu, wie Retrieval aufgerufen wird.