Organisationen & Workspaces¶

Übersicht¶

Die Polycrate API verwendet ein hierarchisches Modell zur Strukturierung von Ressourcen:

graph TB
    subgraph ORG[Organisation<br/>z.B. Meine Firma oder Kunde ABC]
        subgraph WS1[Workspace 1 - Production]
            WS1_BLOCKS[Blocks]
            WS1_CREDS[Credentials]
            WS1_RUNS[Action-Runs]
        end

        subgraph WS2[Workspace 2 - Staging]
            WS2_BLOCKS[Blocks]
            WS2_CREDS[Credentials]
            WS2_RUNS[Action-Runs]
        end

        subgraph SHARED[Shared Resources]
            CONTACTS[Contacts]
            ORG_CREDS[Credentials org-level]
            MW[Maintenance Windows]
            RETENTION[Backup Retention Policies]
        end
    end

Organisationen¶

Eine Organisation ist die oberste Ebene der Ressourcen-Hierarchie. Sie repräsentiert typischerweise:

• Ein Unternehmen oder eine Abteilung
• Einen Mandanten (bei MSP-Szenarien)
• Ein Projekt oder Produkt

Organisation erstellen¶

Organisationen werden in der Web-Oberfläche unter Administration → Organisationen erstellt.

Organisations-Einstellungen¶

Auf Organisations-Ebene konfigurierbar:

• Kontakte: Personen, die bei Alerts benachrichtigt werden
• Credentials: Geteilte Zugangsdaten für alle Workspaces
• Backup-Retention: Wie lange Backups aufbewahrt werden
• Default-Settings: Vererbte Einstellungen für neue Workspaces

Workspaces¶

Ein Workspace entspricht einem Polycrate-Workspace auf der CLI-Seite. Er wird automatisch registriert, wenn die CLI mit aktivierter API eine Action ausführt.

Automatische Registrierung¶

# Workspace wird automatisch in der API registriert
polycrate run my-block install --api-enabled

Bei der ersten Ausführung:

1. CLI prüft, ob Workspace in API existiert
2. Falls nicht: Workspace wird mit Labels polycrate.io/auto-created: true erstellt
3. Block wird ebenfalls automatisch erstellt falls nötig
4. Action-Run wird protokolliert

Workspace-Eigenschaften¶

Workspace-Ansicht¶

In der Web-Oberfläche zeigt die Workspace-Detailseite:

• Übersicht: Status, letzte Aktivität, Metriken
• Blocks: Alle Blocks mit Versionen und Status
• Action-Runs: Historie aller Ausführungen
• Alerts: Aktive Alerts für diesen Workspace
• Credentials: Zugehörige Secrets (verschlüsselt)

Credentials¶

Credentials sind verschlüsselte Zugangsdaten, die auf verschiedenen Ebenen definiert werden können:

Credential-Hierarchie¶

graph TB
    ORG_CREDS[Organisation-Credentials] -->|vererbt an| WS_CREDS[Workspace-Credentials]
    WS_CREDS -->|vererbt an| BLOCK_CREDS[Block-Credentials]

Credential-Typen¶

Credential-Sicherheit¶

• Alle Credentials werden verschlüsselt in der Datenbank gespeichert
• Audit-Logging für alle Zugriffe
• Keine Klartext-Anzeige in der UI (nur bei explizitem Export)
• API-Key-basierter Zugriff für programmatische Nutzung

Multi-Tenancy¶

Die Polycrate API unterstützt vollständige Multi-Tenancy:

Ressourcen-Isolation¶

• Jede Organisation sieht nur ihre eigenen Ressourcen
• Workspaces sind strikt isoliert
• Keine Cross-Organisation-Zugriffe möglich

Berechtigungsmodell¶

graph TB
    SUPER[Super-Admin<br/>System-weit] --> ORG_ADMIN[Org-Admin<br/>Organisations-weit]
    ORG_ADMIN --> WS_ADMIN[Workspace-Admin<br/>Workspace-spezifisch]
    WS_ADMIN --> VIEWER[Viewer<br/>Nur-Lese-Zugriff]

SSO-Integration¶

Für Enterprise-Umgebungen:

• OIDC-Support: Keycloak, Okta, Azure AD, etc.
• Gruppen-Mapping: OIDC-Gruppen → Polycrate-Rollen
• Automatische Benutzer-Erstellung bei erstem Login
• Zentrales Session-Management

Best Practices¶

Organisations-Struktur¶

Organisation: meine-firma
├── Workspace: production
├── Workspace: staging
└── Workspace: development

Organisation: kunde-a
├── Workspace: kunde-a-prod
└── Workspace: kunde-a-staging

Organisation: kunde-b
├── Workspace: kunde-b-prod
└── Workspace: kunde-b-staging

Organisation: produkt-alpha
├── Workspace: alpha-prod-eu
├── Workspace: alpha-prod-us
└── Workspace: alpha-staging

Organisation: produkt-beta
└── Workspace: beta-prod

Credential-Management¶

1. Organisations-weite Credentials für geteilte Ressourcen (z.B. Cloud-Provider)
2. Workspace-spezifische Credentials für umgebungsspezifische Zugänge
3. Regelmäßige Rotation über die API oder Web-UI
4. Minimale Berechtigungen nach Least-Privilege-Prinzip