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
| Funktion | policy-controller | Attestkeep |
|---|---|---|
| Signaturprüfung bei der Admission | Ja, Schlüssel und keyless | Ja, Schlüssel und keyless |
| Prüfung von Attestations | Ja, mit CUE oder Rego über den Inhalt | Ja, mit Höchstalter |
| Tag zu Digest aufgelöst | Ja | Ja |
| Schwachstellenscan | Nein | Trivy, fest im Release |
| Neuer Scan bereits laufender Images | Nein | Jedes Image, täglich |
| Bekannt ausgenutzte Schwachstellen markiert | Nein | CISA KEV |
| Historie der Entscheidungen | Nein | PostgreSQL in Ihrer Hand |
| Befristete Ausnahmen, Break-Glass, Audit-Log | Nein | Ja |
| Konsole im selben Release | Nein | Ja |
| Zeitraumbericht gegen einen Kontrollkatalog | Nein | 13 Regelwerke, 293 zitierte Anforderungen |
| Lizenz | Apache-2.0, kostenlos | Community 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