Workspace-Verschlüsselung: Secrets DSGVO-konform verwalten – ohne externes Tooling

TL;DR

• Unverschlüsselte SSH-Keys, Passwörter in Plaintext und Credentials im Wiki sind ein Compliance-Risiko – insbesondere unter DSGVO (seit dem 25.05.2018) und NIS‑2 (tritt am 17.10.2024 in Kraft).
• Polycrate bringt Workspace-Verschlüsselung direkt mit: Alle Secrets liegen als Dateien im Workspace, werden mit age verschlüsselt und können sicher im Git-Repository versioniert werden.
• secrets.poly enthält sensible Block-Konfiguration (Overrides zu workspace.poly), die zusammen mit Dateien unter artifacts/secrets/ mit einem Workspace-Encryption-Key (v. a. über die Polycrate API oder WORKSPACE_ENCRYPTION_KEY) per age verschlüsselt wird; beim Ausführen stellt Polycrate entschlüsselte Pfade bereit – Zugriff im Playbook über workspace.secrets[...].
• Im Alltag ist der Workflow einfach: polycrate workspace decrypt zum Arbeiten, Änderungen vor dem Commit mit polycrate workspace encrypt absichern – keine externen Tools, kein zusätzliches Secret-Management-System.
• ayedo verbindet Workspace-Verschlüsselung mit Platform Engineering: Polycrate bietet eine containerisierte Toolchain, Guardrails durch das Block-Modell und ein API-fähiges Ökosystem, das Security- und Compliance-Anforderungen von Anfang an mitdenkt.

Das Secrets-Problem: Wenn Bequemlichkeit zur Haftung wird

Wer länger mit Ansible, Shell-Skripten oder manueller Administration arbeitet, kennt typische Muster:

• SSH-Private-Keys liegen im Projektordner, damit „es bei allen funktioniert“.
• Datenbank-Passwörter stehen im group_vars/all.yml in Klartext.
• VPN-Credentials werden „schnell“ per E-Mail oder Chat geteilt.
• Für ein Audit muss mühsam nachgewiesen werden, wo welche Credentials lagen – meist ohne klare Antwort.

Unter DSGVO und NIS‑2 ist das nicht mehr nur unschön, sondern ein reales Risiko:

• Kommt ein Git-Repository mit Klartext-Secrets abhanden (z. B. durch ein kompromittiertes Developer-Laptop), musst du im Zweifel einen Sicherheitsvorfall melden.
• Ohne technische und organisatorische Maßnahmen (TOMs) zum Schutz von Zugangsdaten wird die Rechenschaftspflicht verletzt.

Mit plain Ansible gibt es zwar Ansible Vault, aber:

• es verschlüsselt nur Ansible-Content, nicht deine gesamte Automation-Toolchain,
• du brauchst zusätzliche Prozesse für andere Tools (kubectl, OpenSSL, eigene Skripte),
• das Zusammenspiel mit mehreren Team-Mitgliedern ist oft sperrig.

Polycrate setzt genau hier an: Workspace-Verschlüsselung ist ein Kernfeature – nicht ein nachträglicher Zusatz.

Polycrate Workspace Encryption: age statt Passwort-Kryptik

Polycrate nutzt age als Verschlüsselungsformat. Das bedeutet:

• Moderne Kryptografie mit klaren Primitiven.
• Ein Workspace-Encryption-Key pro Workspace-Verschlüsselung: Auflösung in der Praxis mit Priorität Polycrate API → WORKSPACE_ENCRYPTION_KEY → interaktiver Prompt (siehe Architektur in der Dokumentation).
• Dateibasiert: secrets.poly und Dateien unter artifacts/secrets/** werden zu .age-Artefakten; im Git-Repository liegen nur die verschlüsselten Varianten.

Die Details sind in der Polycrate-Dokumentation beschrieben:
Workspace-Verschlüsselung in Polycrate

Die Grundidee:

1. Du legst geheime Dateien in artifacts/secrets/ ab (z. B. id_rsa, DB-Passwort-Datei, Kubeconfig) und optional sensible Einträge in secrets.poly (Block-Overrides).
2. Du verschlüsselst mit polycrate workspace encrypt – Polycrate bezieht den Key aus API oder Umgebungsvariable (s. o.).
3. Im Repository liegen u. a. secrets.poly.age und artifacts/secrets/**/*.age.
4. Beim Ausführen einer Action entschlüsselt Polycrate transparent im Container – Playbooks greifen über workspace.secrets[...] auf Pfade zu den Klartext-Dateien zu.

Keine zusätzliche Binary wie sops, kein externer Storage wie HashiCorp Vault, kein „nur für Ansible“ wie Ansible Vault. Alles bleibt innerhalb des Polycrate-Workspaces.

secrets.poly: Struktur, Merge mit workspace.poly und der Weg ins Playbook

secrets.poly liegt im Workspace-Root (neben workspace.poly). So wie in der offiziellen Dokumentation enthält sie keine recipients-Liste, sondern sensible Block-Konfiguration, die Werte aus workspace.poly überschreibt – Merge-Priorität: block.poly < workspace.poly < secrets.poly. Siehe Workspace-Verschlüsselung – secrets.poly.

Ein Beispiel (angepasst an unser Szenario – fiktive Werte):

# secrets.poly – sensible Overrides (werden mitverschlüsselt)
blocks:
  - name: linux-user-ssh
    config:
      # Beispiel: zusätzliche, nicht öffentliche Block-Config
      deploy_key_comment: "acme-deploy@2026"

Die Verschlüsselung selbst nutzt einen Workspace-Encryption-Key (nicht pro Person eine Empfängerliste in secrets.poly). Schlüsselquellen und Ablauf: Workspace-Verschlüsselung – Überblick und Architektur.

Polycrate verschlüsselt u. a. secrets.poly und alle relevanten Dateien unter artifacts/secrets/. In Playbooks greifst du auf entschlüsselte Dateien über workspace.secrets['<dateiname>'] zu (Pfad im Action-Container).

Beispiel-block.poly (nach Pull aus der Registry; name = vollständiger Registry-Pfad ohne Tag):

# blocks/registry.acme-corp.com/acme/ops/linux-user-ssh/block.poly
name: registry.acme-corp.com/acme/ops/linux-user-ssh
version: 0.1.0
kind: generic

config:
  username: "deploy"
  ssh_private_key_file: "id_deploy"  # Dateiname in artifacts/secrets/

actions:
  - name: provision
    playbook: provision.yml

Im Ansible-Playbook referenzierst du das Secret über workspace.secrets[...]:

# blocks/registry.acme-corp.com/acme/ops/linux-user-ssh/provision.yml
- name: Linux-User für Deployments anlegen
  hosts: all
  become: true

  vars:
    deploy_user: "{{ block.config.username }}"

  tasks:
    - name: Benutzer anlegen
      ansible.builtin.user:
        name: "{{ deploy_user }}"
        shell: /bin/bash
        state: present

    - name: .ssh-Verzeichnis anlegen
      ansible.builtin.file:
        path: "/home/{{ deploy_user }}/.ssh"
        state: directory
        owner: "{{ deploy_user }}"
        group: "{{ deploy_user }}"
        mode: "0700"

    - name: Private Key deployen (aus Workspace-Secret)
      ansible.builtin.copy:
        src: "{{ workspace.secrets[block.config.ssh_private_key_file] }}"
        dest: "/home/{{ deploy_user }}/.ssh/id_rsa"
        owner: "{{ deploy_user }}"
        group: "{{ deploy_user }}"
        mode: "0600"

Was hier passiert:

• workspace.secrets["id_deploy"] ist ein Pfad im Polycrate-Container, unter dem die entschlüsselte Datei bereitgestellt wird.
• Dein Playbook bleibt idempotent und klar lesbar – kein Kryptografie-Ballast im Task selbst.

Mit plain Ansible müsstest du jetzt mit Ansible Vault arbeiten, die Datei außerhalb der Playbooks verwalten oder eigene Scripte rundherum bauen. Mit Polycrate reicht die Referenz über workspace.secrets.

Komplettes Workspace-Beispiel: SSH-Key sicher in Git versionieren

Nehmen wir einen simplen Workspace acme-corp-automation, der Linux-Server von ACME verwaltet:

# workspace.poly
name: acme-corp-automation
organization: acme

blocks:
  - name: linux-user-ssh
    from: registry.acme-corp.com/acme/ops/linux-user-ssh:0.1.0
    config:
      username: "deploy"
      ssh_private_key_file: "id_deploy"

Das Inventory liegt im Workspace-Root als inventory.yml. Kein Jinja in der Inventory-Datei: {{ workspace.secrets[...] }} wird dort nicht ausgewertet. Für den SSH-Login von Ansible nutzt Polycrate typischerweise den Private Key unter artifacts/secrets/id_rsa, wenn er existiert (siehe Workspace-Verschlüsselung):

# inventory.yml
all:
  hosts:
    server01.acme-corp.com:
      ansible_user: ubuntu

Wir nutzen damit zwei Secret-Dateien:

• artifacts/secrets/id_rsa – SSH-Key für den Ansible-Zugriff auf die Hosts (üblicher Standard)
• artifacts/secrets/id_deploy – Key für den neuen Deploy-User (wird im Playbook über workspace.secrets referenziert)

Die unverschlüsselten Dateien liegen lokal unter:

artifacts/secrets/id_rsa
artifacts/secrets/id_deploy

In Git landen nur die verschlüsselten Varianten (.age).

Workspace verschlüsseln und ausführen

Stelle sicher, dass der Workspace-Encryption-Key verfügbar ist (Polycrate API, WORKSPACE_ENCRYPTION_KEY oder Eingabe beim Prompt – siehe Architektur). Anschließend:

# Workspace einmalig einrichten
polycrate workspace decrypt   # falls schon verschlüsselt geklont
polycrate workspace encrypt   # verschlüsselt alle Dateien in artifacts/secrets/

Um den Block auszuführen:

# Aus Polycrate-Sicht immer im Container
polycrate run linux-user-ssh provision

Polycrate sorgt dafür, dass:

• beim Start der Action die Secrets entschlüsselt und im Container bereitgestellt werden,
• ANSIBLE_INVENTORY automatisch auf inventory.yml gesetzt wird,
• die gesamte Toolchain (Ansible, Python, SSH-Binary, ggf. kubectl/Helm) im Container läuft – keine lokalen Dependencies, kein Python-Chaos.

Damit adressiert Polycrate nicht nur das Secrets-Problem, sondern auch das klassische Dependency-Problem von Automation-Stacks: Alle Tools sind im Container definiert (Dockerfile.poly / Bash-Script), überall gleich und müssen nicht auf jedem Laptop per Hand nachgezogen werden.

Der Workflow im Alltag: encrypt, decrypt, commit

Workspace-Verschlüsselung ist nur dann hilfreich, wenn sie den Alltag nicht ausbremst. Ein typischer Tagesablauf:

1. Workspace klonen

   git clone git@git.acme-corp.com:platform/acme-corp-automation.git
   cd acme-corp-automation

2. Secrets lokal entschlüsseln

   Wenn du den Workspace-Encryption-Key hast (z. B. via API, WORKSPACE_ENCRYPTION_KEY oder Team-Prozess):

   polycrate workspace decrypt

   Polycrate erkennt verschlüsselte Dateien unter artifacts/secrets/ sowie secrets.poly.age und legt unverschlüsselte Versionen an – nur auf deinem lokalen Filesystem.

3. Änderungen vornehmen

   • Neue Secret-Datei anlegen, z. B. neues DB-Passwort:

     echo "super-secure-db-password" > artifacts/secrets/db_password

   • Block anpassen, um das Secret zu verwenden.

   • Playbook erweitern.

4. Lokales Testen

   polycrate run linux-user-ssh provision

5. Vor dem Commit: wieder verschlüsseln

   polycrate workspace encrypt
   git status
   git add .
   git commit -m "Neuen Deploy-User + DB-Secret hinzugefügt"

Im Git-Repository liegen u. a. verschlüsselte Artefakte (*.age, secrets.poly.age). Ohne den Workspace-Encryption-Key sind sie nicht nutzbar – ein starkes Argument in jeder DSGVO- oder NIS‑2-Risikoanalyse.

Ein Workspace-Encryption-Key und Team-Zusammenarbeit

Die Verschlüsselung arbeitet mit einem Workspace-Encryption-Key pro Workspace (keine Empfängerliste in secrets.poly). Best Practice: Schlüssel und Credentials über die Polycrate API verwalten lassen – dann müssen Entwickler den Key nicht manuell verteilen. Zweitbester Weg ohne API: Key mit polycrate tools pwgen -a age erzeugen, die Zeile AGE-SECRET-KEY-... sicher ablegen (z. B. Keeper, Bitwarden, Vaultwarden) und bei polycrate workspace encrypt / decrypt als WORKSPACE_ENCRYPTION_KEY setzen bzw. einfügen (siehe Dokumentation).

Organisatorisch bleibt wichtig: Wer den Key oder API-Zugang erhält, wer Commits an Secrets reviewt und wie Rotation und Offboarding laufen – das ergänzt die technische Verschlüsselung, ersetzt sie aber nicht.

DSGVO- und NIS‑2-Compliance: Verschlüsselt im Git-Repo – und gut?

Natürlich ersetzt Workspace-Verschlüsselung keine vollständige Datenschutz-Folgenabschätzung, aber sie ist ein starker technischer Pfeiler:

• Vertraulichkeit: Secrets liegen in Git ausschließlich verschlüsselt vor. Ein Datenleck des Repositories bedeutet nicht automatisch ein Geheimnis-Leck.
• Integrität: Änderungen an secrets.poly, an Secret-Dateien und an den .age-Artefakten sind versioniert. Du kannst nachvollziehen, wann welche Konfiguration oder welches Secret geändert wurde.
• Verfügbarkeit: Keine Abhängigkeit von einem zentralen Vault-Cluster – solange der Workspace-Encryption-Key (oder API-gestützter Zugriff) für das Team organisiert bleibt, können Secrets entschlüsselt und Automation ausgeführt werden.

Seit dem 25.05.2018 verlangt die DSGVO, dass du technische und organisatorische Maßnahmen zum Schutz personenbezogener Daten nachweisen kannst. Für NIS‑2-pflichtige Unternehmen (mit Stichtag 17.10.2024) gilt ähnliches für kritische Infrastrukturen.

Polycrate hilft dir dabei, diese Anforderungen in deiner Infrastruktur-Automatisierung umzusetzen, ohne ein zusätzliches Secret-Management-System einführen zu müssen. Gerade in Kombination mit einem sauberen Platform Engineering-Ansatz entsteht so eine einheitliche, audit-fähige Basis.

Vergleich mit Vault, SOPS und Ansible Vault

HashiCorp Vault

Vault ist mächtig – aber:

• braucht einen Cluster, Storage-Backend, HA-Setup, Backup-Strategie,
• erfordert eigene Betriebsprozesse und Monitoring,
• erhöht Komplexität und Kosten spürbar.

Für viele Teams ist das „mit Kanonen auf Spatzen geschossen“, insbesondere wenn es „nur“ um Secrets innerhalb von Automation-Workspaces geht.

Polycrate setzt niedriger an:

• Keine zusätzliche Infrastruktur.
• Verschlüsselung direkt dort, wo du arbeitest – im Workspace.
• Ausreichend für viele DSGVO-/NIS‑2-Anforderungen im Bereich Automation.

SOPS

SOPS ist ein hervorragendes Tool für verschlüsselte YAML/JSON-Dateien, aber:

• es ist ein zusätzliches Binary, das du auf allen Workstations installieren und aktuell halten musst,
• du brauchst Prozesse, wie SOPS mit deinen Tools (Ansible, Terraform, kubectl etc.) zusammenspielt,
• es löst nicht das Dependency-Problem deiner Toolchain.

Mit Polycrate kommen:

• Workspace-Verschlüsselung,
• containerisierte Toolchain (Ansible, kubectl, Helm, Python …),
• das Block-Modell als Guardrail

aus einer Hand. Kein Bruch im Developer-Workflow.

Ansible Vault

Ansible Vault ist eng in Ansible integriert, aber damit auch begrenzt:

• Du kannst nur Inhalte verschlüsseln, die Ansible kennt (Vars, Files).
• Andere Tools im gleichen Repository (z. B. Shell-Skripte, TLS-Zertifikate, Kubeconfigs) fallen aus dem Rahmen.
• Sharing über Teams hinweg ist häufig hakelig; Vault-Passwörter müssen separat verwaltet werden.

Polycrate geht weiter:

• Verschlüsselt alle Dateien unter artifacts/secrets/ – unabhängig vom verwendeten Tool.
• Stellt sie Actions im Container über workspace.secrets[...] zur Verfügung – egal ob Ansible, kubectl, ein Bash-Script oder ein eigenes Binary.
• Bietet Sharable Automation: Blöcke können in einer OCI-Registry versioniert und geteilt werden, etwa über den PolyHub. Dabei bleiben Workspace-Secrets stets im Besitz des jeweiligen Teams, nicht des Block-Autors.

Häufige Fragen

Müssen alle Team-Mitglieder denselben age-Private-Key teilen?

Workspace-Verschlüsselung nutzt einen gemeinsamen Workspace-Encryption-Key (nicht pro Person unterschiedliche Empfänger in secrets.poly). Empfohlen ist, den Key nicht per Chat zu verteilen, sondern über die Polycrate API oder einen Passwort-Manager / vertrauliche Übergabe – analog zur offiziellen Doku. Zugriff entziehen funktioniert organisatorisch (API-Rechte, Rotation des Keys, Entfernen aus dem Passwort-Manager) und über eure Git-/Review-Prozesse, nicht durch „Empfänger aus secrets.poly streichen“.

Was passiert, wenn jemand den Workspace ohne Workspace-Encryption-Key klont?

Die verschlüsselten Dateien unter artifacts/secrets/ und secrets.poly.age sind im Repo sichtbar, aber ohne den Workspace-Encryption-Key nutzlos. polycrate workspace decrypt schlägt dann fehl bzw. fordert den Key an. Das ist das gewünschte Verhalten: Code ist lesbar, Secrets nicht – ideal für getrennte Rollen (z. B. Entwickler ohne Produktionszugriff).

Wie passt Workspace-Verschlüsselung in ein größeres Compliance-Framework?

Workspace-Verschlüsselung ist ein Baustein in einem technischen Kontroll-Set, z. B. für DSGVO-TOMs oder NIS‑2-Maßnahmenkataloge. In Kombination mit sauber definierter Rollenverteilung, Logging der Automation-Läufe und klaren Prozessen für Key-Management kannst du gegenüber Prüfern zeigen, dass:

• Zugriff auf Secrets rollenbasiert geregelt ist,
• Secrets nur verschlüsselt im zentralen SCM liegen,
• Änderungen nachvollziehbar versioniert werden.

Weitere Fragen? Siehe unsere FAQ

Compliance in der Praxis

Workspace-Verschlüsselung mit Polycrate ist kein theoretisches Sicherheitsfeature, das im Alltag vergessen wird. Sie ist unmittelbar im Workflow verankert:

• Du arbeitest in einem klar strukturierten Workspace mit Blocks statt Playbook-Wildwuchs.
• Deine gesamte Toolchain läuft im Container – reproduzierbar und unabhängig von lokalen Installationen.
• Secrets werden automatisch dort bereitgestellt, wo sie gebraucht werden, ohne an Klartext-Dateien zu denken.

ayedo begleitet Organisationen genau an dieser Schnittstelle aus Automatisierung, Security und Compliance – ob als Erweiterung bestehender Ansible-Landschaften oder im Rahmen eines modernen Platform Engineering-Ansatzes. Wir helfen dabei,

• bestehende Playbooks in Polycrate-Blöcke zu überführen,
• Workspace-Verschlüsselung sauber in Git-Workflows und Review-Prozesse zu integrieren,
• DSGVO- und NIS‑2-Anforderungen in der Infrastruktur-Automatisierung technisch greifbar umzusetzen.

Wenn du sehen möchtest, wie sich das konkret anfühlt – inklusive polycrate workspace encrypt/decrypt, secrets.poly und der Nutzung von workspace.secrets in deinen eigenen Playbooks –, lohnt sich ein Blick auf unsere Workshops.