security

Drei Schichten für ein Secret — von pass über SOPS und Vault in den Pod

Permalink 6 min read Published:
 security  infrastructure  #sops #vault #external-secrets #secrets #gitops #flux #age #pgp #kubernetes
In einem öffentlichen GitOps-Repo darf nie ein Klartext-Secret liegen — und trotzdem muss jeder Workload an seine Passwörter kommen. Mein Lab löst das in drei klar getrennten Schichten: SOPS+PGP/age für die paar Bootstrap-Secrets, die vor Vault existieren müssen; Vault KV als Langzeitspeicher für alles Anwendungsnahe; und der External Secrets Operator, der daraus zur Laufzeit Kubernetes-Secrets materialisiert. Eine Tour durch den Lebensweg eines Geheimnisses.

Mein Lab ist ein öffentliches GitOps-Repo — über meinen Radicle -Seed-Node seed.this-is-fine.io kann es jeder klonen. Daraus folgt eine harte Regel: kein Klartext-Secret, niemals, nirgends in Git. Und trotzdem braucht jeder Workload im Cluster seine Passwörter, API-Tokens und Signing-Keys. Diesen Widerspruch löse ich in drei Schichten, von denen jede genau eine Aufgabe hat.

Im Beitrag über die pre-commit-Hooks ging es darum, wie ich verhindere, dass ein Secret versehentlich in Git landet. Hier geht es um den geplanten Weg: wie ein Secret absichtlich von meiner Maschine bis in einen Pod fließt, ohne je unverschlüsselt das Repo zu berühren.

Kein Klartext-Secret kommt durch — pre-commit, gitleaks und SOPS

Permalink 3 min read Published:
 security  automation  #pre-commit #gitleaks #sops #secrets #git #gitops #shellcheck
Ein GitOps-Repo ist öffentlich, sobald man es vergisst. Drei Hooks sorgen dafür, dass ich gar nicht erst ein unverschlüsseltes Secret committen kann: gitleaks scannt auf Muster, ein SOPS-Hook verweigert Klartext in geschützten Pfaden, und ein lokaler Decrypt-Check stellt sicher, dass jede verschlüsselte Datei sauber entschlüsselt und alle Empfänger trägt.

Mein Lab-Repo ist öffentlich — abrufbar über meinen Radicle -Seed-Node seed.this-is-fine.io. Genau deshalb darf da nie ein Klartext-Secret hineinrutschen. Nicht „sollte nicht", sondern kann nicht: Drei pre-commit -Hooks fangen den Fehler ab, bevor er ein Commit-Objekt wird. Das ist die billigste Versicherung, die ich kenne — ein paar Zeilen YAML gegen einen Leak, den man nie ganz zurückholt.

Pocket-ID: Ein OIDC-Provider, der nur eine Sache kann — und die gut

Permalink 4 min read Modified: (UPDATED)
 infrastructure  security  #pocket-id #oidc #authentik #sso #passkey #webauthn #kubernetes #gitops
Warum ich meinen schwergewichtigen Authentik-Stack gegen das schlanke, passkey-zentrierte Pocket-ID als zentralen OIDC-Provider getauscht habe

Single Sign-On im Homelab ist ein zweischneidiges Schwert: Man will einen Login für alles, handelt sich damit aber schnell einen Identity-Provider ein, der schwerer wiegt als die Dienste, die er absichert. Genau an diesem Punkt habe ich meinen bisherigen Authentik -Stack gegen Pocket-ID getauscht — erreichbar unter auth.this-is-fine.io und seitdem der zentrale OIDC-Provider für mein gesamtes Lab.

Signierte Images erzwingen: Cosign in der Pipeline, Kyverno im Cluster

Permalink 4 min read Modified: (UPDATED)
 infrastructure  security  #cosign #kyverno #sigstore #oci #supply-chain #kubernetes #zot #ci
Wie selbstgebaute OCI-Images in der CI mit cosign signiert und im Cluster von Kyverno-Policies im Enforce-Modus verifiziert werden

Wer eigene Container-Images baut und in einer eigenen Registry hält, hat ein Vertrauensproblem in petto: Woher weiß der Cluster, dass ein Image wirklich aus meiner Pipeline stammt und nicht unterwegs manipuliert wurde? Meine Antwort ist eine geschlossene Kette aus zwei Hälften — cosign signiert in der CI, Kyverno verifiziert im Cluster und lässt nichts Unsigniertes durch.