Häufige Fragen

Es scannt die Images, die Ihr Cluster ausführt, auf Schwachstellen, prüft ihre Signaturen und Attestations, entscheidet, was der Admission-Webhook annimmt, und führt ein Audit-Log über jede Entscheidung, jede Ausnahme und jedes Break-Glass. Operator, API, Konsole und Datenbank werden in einen Namespace installiert, der Ihnen gehört.

Es ist kein Runtime-Sensor. Es beobachtet selbst keine Syscalls, Netzwerkflüsse oder Prozessbäume in laufenden Containern; wenn Sie Falco installieren, tut Falco das, und die Runtime-Policies von Attestkeep entscheiden, was aus seinen Events folgt. Es ist auch kein Cloud-Posture-Werkzeug – es liest weder Ihr Konto beim Cloud-Anbieter noch Ihre IAM-Policies.

Was es tut, ist enger gefasst und belegbar: Es entscheidet, was starten darf, und führt den Nachweis darüber, was es entschieden hat.

Bei der Image-Sicherheit überschneidet es sich mit ihnen und geht weiter: Diese Engines können „deny the :latest tag“ formulieren, haben hinter der Regel aber keinen Scanner, keinen CVE-Cache und keinen Signaturprüfer. Attestkeep bringt alle drei mit und setzt die Image-Regeln aus demselben Urteilsspeicher durch, in den es seine Scans schreibt.

Für alles andere, was eine Policy-Engine tut – Labels, Ressourcengrenzen, Namespace-Konventionen –, bleiben sie das richtige Werkzeug, und beide laufen konfliktfrei nebeneinander. Ausführlicher steht es auf der Seite, die Kyverno und Attestkeep gegenüberstellt; dasselbe gibt es für Trivy Operator und Sigstore policy-controller.

In diesem Release nicht. Jeder Cluster betreibt seinen eigenen Operator mit eigener Datenbank und eigener Konsole, und diese sind bewusst unabhängig – genau deshalb muss nichts eine Cluster-Grenze überschreiten. Eine Flottenansicht, die viele Installationen auf einer Seite zusammenfasst, steht ohne Datum auf der Roadmap; das sagen wir lieber, als ein Release zu nennen, das wir verfehlen könnten.

Der Operator selbst ja – das Release-Image wird für beide gebaut und signiert. Scan-Urteile werden derzeit jedoch für linux/amd64 erfasst: Bei einem Multi-Architektur-Image beschreibt der Befund das amd64-Image im Index, nicht die Variante, die ein arm64-Node ausführt. Urteile pro Plattform stehen auf der Liste.

Jede konforme Distribution ab 1.27, einschließlich Managed Services, k3s und OpenShift. Der Operator nutzt Standard-Admission-Webhooks und CRDs; er braucht keinen Node-Agent, kein privilegiertes DaemonSet und kein Kernel-Modul.

Einmal am Tag drei Werte für die Lizenzierung: die Lizenzkennung, ein Fingerabdruck des Clusters und die Operator-Version. Sonst nichts, und nichts, was beschreibt, was Sie betreiben – keine Image-Namen, keine Befunde, keine CVE-Kennungen, keine Workload- oder Namespace-Namen, keine Cluster-Topologie, keine Benutzerkonten, nichts aus Ihrer Datenbank.

Das liegt nicht daran, dass wir uns gegen das Senden entscheiden: Es gibt schlicht keinen Weg, auf dem diese Daten übertragen würden. Die Grenzen, die Ihr Plan für Images, Frameworks und Nodes setzt, zählt und erzwingt der Operator in Ihrem eigenen Cluster; die Zahlen müssen ihn also nicht verlassen. Wir haben keine Kopie Ihrer Befunde, Ihrer Image-Namen oder des Aufbaus Ihres Clusters, und eine Sicherheitskonsole, die eine Liste aller Ihrer Images braucht, ist genau das, was dieses Produkt nicht sein soll.

Warum es die tägliche Prüfung überhaupt gibt und was passiert, wenn sie fehlschlägt, steht auf der Lizenzseite.

Keine. Die tägliche Lizenzprüfung ist keine Analyse und dient auch nicht als solche: Sie überträgt die drei oben genannten Werte und liefert ein Urteil zurück, und nichts davon beschreibt, wie Sie das Produkt nutzen. Niemand bei uns kann sehen, wie viele Images Sie gescannt haben, welche Frameworks Sie geöffnet haben oder ob sich diese Woche jemand angemeldet hat.

Auch die Website hat keine – kein Analyse-Skript, keinen Tag-Manager, keine Einbettung von Dritten –, deshalb gibt es im Cookie-Hinweis so wenig zu fragen.

In einer PostgreSQL-Datenbank unter Ihrer Kontrolle, in Ihrem eigenen Namespace oder auf Ihrem eigenen Server. Exportieren Sie sie, sichern Sie sie oder löschen Sie den Namespace – wir können sie nicht lesen und haben keine Kopie.

Der Name der Installation, die Image-Referenz und das Urteil – nie ein Node-Name, eine interne Adresse oder ein Endpunkt. Benachrichtigungen gehen nur an die Kanäle, die Sie konfigurieren (Slack, Teams, E-Mail, Webhook).

Ja. Scanner und Signaturprüfer sind in fester Version im Release-Image enthalten, Sie spiegeln die Schwachstellendatenbank in Ihre eigene Registry, und das Compliance-Mapping wird mit dem Operator ausgeliefert; eine Installation ohne Verbindung berichtet also dasselbe wie eine verbundene.

Die Lizenzierung war der Teil, der früher eine Verbindung nach außen brauchte. Heute läuft sie über ein Zertifikat, das Sie selbst in den Cluster bringen: Die Konsole erzeugt eine kleine Aktivierungsanfrage, die diesen Cluster benennt – Fingerabdruck, Public Key des Operators, Cluster-Name und Version. Sie laden sie auf Ihrer Lizenzseite hoch, bei einer Enterprise-Lizenz nach Annahme der Bedingungen für die Offline-Aktivierung, und das ausgestellte Zertifikat gilt nur für diesen Cluster. Es läuft bis zum Ende der bezahlten Laufzeit plus dreißig Tage, bei einer Lizenz ohne Enddatum zwölf Monate, und warnt dreißig Tage vor Ablauf. Solange die Installation eines hat, findet keine Lizenzprüfung statt.

Offline-Aktivierung gibt es für jährliche Enterprise-Lizenzen ab dem fünfzehnten Tag nach dem Kauf und für jede jährliche Lizenz, die über einen Vertrag mit uns eröffnet wurde. Die Schritte stehen in der Installationsanleitung. Ein Cluster mit Verbindung nach außen behält den einfacheren Weg: einen Aktivierungsschlüssel und die tägliche Prüfung.

Das Helm-Chart bringt ein eigenes PostgreSQL mit oder nimmt den DSN einer Datenbank, die Sie bereits betreiben. Verweisen Sie es auf eine vorhandene Datenbank, legt das Chart weder eine Datenbank noch einen Volume Claim dafür an; übrig bleibt nur der Claim für den Cache der Schwachstellendatenbank des Scanners. In beiden Fällen legt der Operator seine Tabellen beim ersten Start selbst an und migriert sie – Sie müssen kein SQL ausführen, und beim Upgrade gibt es keinen Migrationsschritt, den man vergessen könnte.

Die Failure Policy des Webhooks steht standardmäßig auf Ignore: Kann der Operator nicht antworten, laufen Deployments ungeschützt weiter, statt anzuhalten. Für einen Cluster, der laufen muss, ist das die sichere Voreinstellung. Jede Edition, auch Community, kann Fail setzen und alles ablehnen, was noch nicht gescannt ist – eine bewusste Abwägung, ausdrücklich getroffen.

Die Admission ist repliziert und über Nodes verteilt. Periodische Aufgaben – Scans, Lizenzprüfungen, Aufbewahrung – übernimmt über einen PostgreSQL-Advisory-Lock immer genau eine Replica; eine zweite Replica wiederholt also nie einen Scan oder eine Benachrichtigung.

Der Operator. Das Schlüsselpaar wird im Cluster erzeugt und rotiert, und jede Replica übernimmt ein neues ohne Neustart. Es gibt keine Abhängigkeit von cert-manager und keine jährliche Erinnerung in Ihrem Kalender.

Aktualisiert wird mit helm upgrade; eingebettete Migrationen führen die neuen Schritte aus und überspringen den Rest. Deinstalliert wird mit helm uninstall und dem Löschen des Namespace. Der Webhook wird mit dem Release entfernt, ein deinstallierter Operator hinterlässt also keine blockierende Admission.

Sie legen auf attestkeep.com ein Konto an, wählen ein Paket und gewünschte Zusätze und erhalten einen Lizenzschlüssel. Den geben Sie in Ihrer eigenen Konsole ein, und die Aktivierung tauscht ihn gegen ein signiertes Zertifikat, das festhält, was Sie gekauft haben, für welchen Cluster es ausgestellt ist und bis wann es gilt. Die Community Edition funktioniert genauso; ihr Zertifikat hat lediglich kein Ablaufdatum.

Danach prüft der Operator das Zertifikat bei jedem Start, ohne den Cluster zu verlassen – unsere Signatur, das Ablaufdatum und ob der enthaltene Fingerabdruck zu diesem Cluster gehört. Unabhängig davon prüft er einmal am Tag die Lizenz bei uns. Das Zertifikat gilt dreißig Tage; schlägt die tägliche Prüfung fehl, ändert sich also lange nichts. Alle Einzelheiten stehen auf der Lizenzseite.

Die Installation fällt auf die Community Edition zurück. Sie hält nicht an, sperrt Sie nicht aus und beginnt nicht, Deployments abzulehnen – Scans und Admission laufen innerhalb der kostenlosen Grenzen weiter. Eine Sicherheitskontrolle, die sich wegen eines Rechnungsdatums abschaltet, ist schlimmer als eine unbezahlte Rechnung.

Ein Zertifikat, das abläuft, weil der Lizenzserver einen Monat lang nicht erreichbar war, verhält sich genauso und wird lange vorher angekündigt: Die Konsole warnt nach einer Woche ohne Verbindung, und die Administratoren erhalten eine E-Mail, bevor das Zertifikat abläuft.

Eine befristete Testversion gibt es nicht, und das mit Absicht: Die Community Edition enthält alle Sicherheitsfunktionen und läuft nicht ab. Sie leistet also, was eine Testphase leisten würde – im eigenen Cluster, so lange Sie möchten. Die bezahlten Pläne bringen Kapazität und Single Sign-On, keine zusätzlichen Sicherheitsfunktionen. Läuft eine bezahlte Lizenz ohne Verlängerung ab, fällt die Installation auf die Community Edition zurück, statt etwas abzuschalten.

Zahlungen wickelt Polar Software, Inc. ab, unser Merchant of Record, der Ihnen die Lizenz weiterverkauft: Die Rechnung stellt Polar, die für Ihre Rechnungsadresse fällige Steuer berechnet und erhebt Polar im Checkout, und eine Kartennummer erreicht uns nie. Lizenz und Support kommen von uns. Umsatzsteuerlich registrierte Unternehmen in der EU führen die Umsatzsteuer im Reverse-Charge-Verfahren selbst ab.

Ja, bis zu der Zahl, die Ihr Plan bezahlt – genau das bedeutet die Cluster-Anzahl in der Preisliste. Community und Team enthalten 1, Business 3, Enterprise 5. Derselbe Lizenzschlüssel aktiviert jeden davon, und jede Aktivierung belegt einen Slot; Ihr Konto zeigt, welche Cluster Slots belegen und wie viele frei sind.

Darüber hinaus wird die nächste Aktivierung abgelehnt, nicht stillschweigend erlaubt. Sie können einen ungenutzten Slot freigeben oder Ihrem vorhandenen Schlüssel Cluster hinzufügen, ohne die laufenden Installationen anzufassen.

Nicht für die Abrechnung – es gibt keine nutzungsabhängige Messung und keine Rechnung, die sich mit der Nutzung ändert. Jeder Plan legt eine Node-Obergrenze pro Cluster fest: Community 1, Team 6, Business 10, Enterprise 20. Zusätzliche Nodes werden einzeln gekauft, im Checkout bis zu 50 Nodes pro Cluster.

Der Operator zählt die Nodes im Zustand Ready innerhalb des Clusters, und die Zahl wird nirgendwohin gesendet; die tägliche Lizenzprüfung überträgt dieselben drei Werte wie zuvor. Über der Obergrenze hält nichts an: Konsole und Benachrichtigung melden es, mit dem Stichtag in 14 Tagen. Nach diesen 14 Tagen werden nur Image-Namen abgelehnt, die in diesem Zeitraum noch nicht vorkamen, und alles bereits Gezählte läuft weiter. Liegt der Cluster wieder innerhalb der Grenze, wird die Frist zurückgesetzt.

Zehn Tage bis einen Monat lang ändert sich nichts, je nachdem, wie viel Laufzeit das Zertifikat beim Verbindungsverlust noch hatte. Fehlgeschlagene Prüfungen werden nach wenigen Stunden wiederholt, nicht erst am nächsten Tag; ein Ausfall muss also wochenlang anhalten, bevor er zum Lizenzproblem wird – und die Konsole warnt nach der ersten Woche, statt Sie es später herausfinden zu lassen.

Nicht erreichbar und abgelehnt sind zwei verschiedene Dinge: Schweigen verbraucht die Restlaufzeit des Zertifikats, eine Antwort, dass die Lizenz freigegeben oder widerrufen wurde, gilt dagegen sofort.

Den Operator neu zu installieren ist kostenlos – der Fingerabdruck wird aus dem Cluster abgeleitet, nicht aus dem Operator. Löschen und erneutes Deployen braucht also nichts von uns, und das Zertifikat bleibt gültig.

Ein neu aufgebauter Cluster erhält einen neuen Fingerabdruck und ist für die Lizenz damit ein neuer Cluster; er belegt also einen Slot. Haben Sie den alten Cluster noch, deaktivieren Sie ihn zuerst dort, dann ist der Slot sofort frei. Ist er schon weg, geben Sie seinen Slot in Ihrem Konto frei – dort steht jeder Cluster, der einen Slot belegt, mit seinem Aktivierungsdatum, sodass Sie sie auseinanderhalten können.

Derzeit 13 Regelwerke: der Cyber Resilience Act – Verordnung (EU) 2024/2847 – und daneben NIS2, DORA, die Trust Services Criteria von SOC 2, NIST SP 800-190, das SSDF (SP 800-218), ausgewählte Kontrollen aus SP 800-53 Rev. 5, ISO/IEC 27001:2022 Annex A, DSGVO Artikel 32, PCI DSS v4.0.1 Requirements 6 und 11, die MAS Technology Risk Management Guidelines (Januar 2021), das ASD Essential Eight Maturity Model (November 2023), die Control Criteria von ISMAP (August 2024) und die Zertifizierungskriterien von ISMS-P (November 2023).

Das Mapping wird mit dem Operator ausgeliefert statt nachgeladen; ein Cluster, dessen einzige Verbindung nach außen der Lizenz-Endpunkt ist, erzeugt also dasselbe Dokument wie ein voll verbundener. Jede Anforderung trägt ihre eigene Fundstelle und die Bewertung dahinter; eine Anforderung, die ein Cluster nicht beantworten kann, wird mit Begründung als außerhalb des Umfangs markiert, denn ein Nachweispaket, das zu viel behauptet, ist weniger wert als eines, das seine Grenzen offenlegt.

Die kostenlose Edition enthält 1 Framework Ihrer Wahl; bezahlte Pläne enthalten mehr.

Nein, und das steht auch auf dem Dokument. Es ist ein Nachweis aus Ihren eigenen Aufzeichnungen, und kein Auditor muss ihn anerkennen. Was es leistet: Die Tabellenkalkulation entfällt, denn wer welches Risiko wann und für wie lange akzeptiert hat, ist bereits festgehalten.

met (erfüllt), partial (teilweise), gap (Lücke) und outside_scope (außerhalb des Umfangs). Ein Bericht, der nur „bestanden“ oder „nicht bestanden“ kennt, zwingt jede Kontrolle in eine Lüge; outside_scope sagt, dass eine Kontrolle auf einen Kubernetes-Admission-Controller nicht anwendbar ist – eine vertretbare Antwort, und eine andere als ein Nichtbestehen. War der Webhook an einem Dienstag vierzig Minuten lang ausgefallen, steht dieses Zeitfenster im Dokument.

Im öffentlichen Issue-Tracker unter github.com/attestkeep/attestkeep-docs. Meldungen aus allen Editionen werden dort öffentlich bearbeitet, auch aus der Community Edition – aus der kostenlosen Edition kommen die meisten ersten Meldungen, und sie im Stillen zu schließen, wäre Verschwendung.

Nicht in einem öffentlichen Issue. Nutzen Sie den vertraulichen Advisory-Weg, der auf der Sicherheitsseite beschrieben ist; Sie erhalten innerhalb von drei Werktagen eine Eingangsbestätigung. Behobene Probleme werden als Advisories im selben Repository veröffentlicht, sobald ein Release mit der Korrektur erschienen ist.

Die Community Edition wird über den öffentlichen Issue-Tracker unterstützt, wo auch die Bugs der bezahlten Editionen bearbeitet werden – Meldungen werden nicht danach sortiert, was Sie zahlen. Bezahlte Pläne bringen E-Mail-Support, und ab Business wird Ihre E-Mail vor der Warteschlange bearbeitet.

Wir veröffentlichen für keinen Plan eine garantierte Antwortzeit. Eine Zahl auf dieser Seite wäre ein Versprechen an alle zugleich, von einem Team, das sie mit niemandem konkret vereinbart hat; wir antworten lieber schnell, als eine Zahl festzuschreiben, die wir in einer schlechten Woche verteidigen müssten.