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.