Im Vergleich mit Sigstore policy-controller

Er sagt, wer das Image signierte. Nicht, was darin ist.

policy-controller ist die Referenzantwort auf eine Frage, geschrieben vom Projekt, das das Format dieser Antwort festlegt. Wenn Signatur- und Attestation-Prüfung die ganze Aufgabe ist, gibt es kaum ein Argument dagegen. Was er nicht fragt: was das Image enthält.

Was policy-controller ist

Ein Admission Controller aus dem Sigstore-Projekt. Eine ClusterImagePolicy nennt die Autoritäten, die ein Image erfüllen muss – einen Public Key oder eine keyless Identität mit Issuer – und die Attestations, die es mitbringen muss; ein Pod wird zugelassen, wenn jede passende Policy mindestens eine Autorität hat, deren Prüfung besteht. Er löst Tags in Digests auf, damit läuft, was zugelassen wurde; die Durchsetzung wird pro Namespace eingeschaltet, und eine CUE- oder Rego-Policy lässt sich auf den Inhalt einer Attestation anwenden, sobald deren Signatur geprüft ist.

Er steht unter Apache-2.0, ist kostenlos und schlank und wird von den Leuten gepflegt, die die Formate von cosign festlegen. Für einen Cluster, dessen Lieferkette lautet: „alles, was wir betreiben, ist von unserem eigenen Build-System signiert“, ist das eine vollständige Antwort, und Sie sollten ihn einsetzen.

Wo sie sich decken

Genau bei der Prüfung von Signaturen und Attestations bei der Admission. Attestkeep prüft cosign-Signaturen mit Schlüssel oder keyless gegen Identität und Issuer, prüft in-toto-Attestations und kann ein Höchstalter dafür verlangen, fordert ein geprüftes SBOM oder eine Provenance-Aussage, wo die Policy es vorsieht, und pinnt Images auf Digests. Wenn Sie genau diese Liste suchen: policy-controller erledigt das und kostet nichts.

Die Nahtstelle

Eine Signatur sagt, dass sich jemand für diese Bytes verbürgt. Sie sagt nicht, dass die Bytes sicher sind. Ein Image, das heute Morgen von einem Build-System Ihres Vertrauens signiert wurde, kann eine kritische Schwachstelle enthalten, die letzte Nacht veröffentlicht wurde, und jede Policy im Cluster lässt es zu, und zwar korrekt, weil die Signatur gültig ist. Signaturprüfung und Schwachstellen sind verschiedene Fragen, und gestellt wird nur eine davon.

policy-controller hat keinen Scanner, keine Schwachstellendatenbank und keine Historie: Er bewertet die vorliegende Anfrage und ist fertig. Attestkeep beantwortet beide Fragen in einem Urteil – die Signatur und Trivys Befunde zum selben Digest, wobei der CISA-Katalog bekannter ausgenutzter Schwachstellen die angegriffenen markiert – und bewahrt die Antwort auf. Die Datenbank wird alle sechs Stunden aktualisiert und jedes Image täglich neu gescannt; ein Image, das bei der Admission sauber war, gilt also nicht einfach weiter als sauber.

Und der Eintrag überdauert die Anfrage. Urteile werden in ein PostgreSQL unter Ihrer Kontrolle geschrieben, zusammen mit dem Hash der Policy, die sie erzeugt hat – erst das macht einen Zeitraumbericht überhaupt möglich: 13 Regelwerke und Kontrollkataloge, 293 Anforderungen, jede mit Fundstelle zitiert und als erfüllt, teilweise, Lücke oder außerhalb des Umfangs markiert, signiert in Ihrem Cluster und von Ihrem Auditor ohne uns prüfbar.

Funktionsvergleich

Was Sigstore policy-controller und Attestkeep jeweils mitbringen
Funktionpolicy-controllerAttestkeep
Signaturprüfung bei der AdmissionJa, Schlüssel und keylessJa, Schlüssel und keyless
Prüfung von AttestationsJa, mit CUE oder Rego über den InhaltJa, mit Höchstalter
Tag zu Digest aufgelöstJaJa
SchwachstellenscanNeinTrivy, fest im Release
Neuer Scan bereits laufender ImagesNeinJedes Image, täglich
Bekannt ausgenutzte Schwachstellen markiertNeinCISA KEV
Historie der EntscheidungenNeinPostgreSQL in Ihrer Hand
Befristete Ausnahmen, Break-Glass, Audit-LogNeinJa
Konsole im selben ReleaseNeinJa
Zeitraumbericht gegen einen KontrollkatalogNein13 Regelwerke, 293 zitierte Anforderungen
LizenzApache-2.0, kostenlosCommunity dauerhaft kostenlos; bezahlte Editionen bringen Kapazität, SSO, Support

Was Sie brauchen

policy-controller allein, wenn Sie alle Images, die Sie betreiben, selbst bauen und signieren, wenn Sie Herkunft statt Inhalt durchsetzen müssen und wenn Sie so nah am Sigstore-Projekt bleiben wollen, wie es ein Deployment erlaubt.

Attestkeep, wenn „signiert“ in Ihrem Bedrohungsmodell nicht dasselbe ist wie „sicher“ – Basis-Images aus fremden Quellen, Images von Herstellern, alles, was Sie nicht selbst gebaut haben –, oder wenn die Signaturprüfung ein Nachweis sein muss und nicht nur ein Verhalten. Beide laufen als validierende Webhooks und können im selben Cluster stehen, auch wenn eine Image-Regel besser nur einmal formuliert wird, in einem der beiden. Die Community Edition ist dauerhaft kostenlos, Sie können unsere Lösung also neben Ihre stellen, bevor Sie entscheiden.

Selbst installieren.

Konto anlegen, die E-Mail mit dem zugesandten Code bestätigen, den kostenlosen Community-Schlüssel auf der Seite Licences holen und mit Helm installieren.

Konto anlegen