Frequently asked questions

It scans the images your cluster runs for vulnerabilities, verifies their signatures and attestations, decides what the admission webhook accepts, and keeps an audit record of every decision, exception and break-glass. The operator, its API, its console and its database are installed into a namespace you own.

It is not a runtime sensor. It does not watch syscalls, network flows or process trees inside a running container, and it will not tell you that a pod started behaving oddly at three in the morning. It is not a cloud posture tool either — it does not read your cloud provider account or your IAM policies.

What it does is narrower and provable: it decides what is allowed to start, and it keeps the record of what it decided.

For image security it overlaps with them, and it goes further: those engines can express "deny the :latest tag", but they have no scanner, no CVE cache and no signature verifier behind the rule. Attestkeep carries all three, and enforces the image-related rules from the same verdict store it scans into.

For everything else a policy engine does — labels, resource limits, namespace conventions — they remain the right tool, and the two run side by side without conflict. There is a longer answer on the page that puts Kyverno and Attestkeep side by side, and the same treatment for Trivy Operator and Sigstore policy-controller.

Not in this release. Each cluster runs its own operator with its own database and its own console, and they are independent by design — which is exactly why nothing has to cross a cluster boundary. A fleet view that summarises many installations on one page is on the roadmap, without a date attached — we would rather say that than name a release we might miss.

The operator itself does — the release image is built and signed for both. Scan verdicts, however, are currently recorded against linux/amd64, so on a multi-architecture image the finding describes the amd64 child of the index rather than the variant an arm64 node will run. Per-platform verdicts are on the list.

Any conformant distribution from 1.27 onwards, including managed services, k3s and OpenShift. The operator uses standard admission webhooks and CRDs; it needs no node agent, no privileged DaemonSet and no kernel module.

Three values, once a day, for licensing: the licence identifier, a fingerprint of the cluster, and the operator version. Nothing else, and nothing that describes what you run — no image names, no findings, no CVE identifiers, no workload or namespace names, no cluster topology, no user accounts, nothing from your database.

It is not that we choose not to send those; there is no path that would carry them. The limits your plan sets on images, frameworks and nodes are counted and enforced by the operator inside your own cluster, so the counts have no reason to leave it. We hold no copy of your findings, your image names or your cluster's shape, and a security console that needs a list of every image you run is exactly the thing this product is built not to be.

Why the daily check exists at all, and what happens when it fails, is on the licensing page.

None. The daily licence check is not analytics and does not double as any: it carries the three values listed above and returns a verdict, and no part of it describes how you use the product. Nobody here can tell how many images you scanned, which frameworks you opened or whether anyone logged in this week.

The website has none either — no analytics script, no tag manager, no third-party embed — which is why the cookie notice has so little to ask about.

In a PostgreSQL database you control, inside your own namespace or on your own server. Export it, back it up, or drop the namespace — we cannot read it and we hold no copy.

The installation's name, the image reference and the verdict — never a node name, an internal address or an endpoint. Notifications go to the channels you configure (Slack, Teams, e-mail, webhook), and to nothing else.

Yes. The scanner and the signature verifier are pinned into the release image, you mirror the vulnerability database into your own registry, and the compliance mapping ships inside the operator, so a disconnected installation reports what a connected one does.

Licensing is the part that used to need a route out. It is now done with a certificate you carry in: the console writes a small activation request naming this cluster — the fingerprint, the operator's public key, the cluster name and the version — you upload it on your licence page, accepting the offline activation terms first on an Enterprise licence, and the certificate that comes back is issued for that cluster alone. It runs to the end of the paid term plus thirty days, twelve months on a licence with no end date, and warns you thirty days before it expires. While the installation holds one it makes no licence call at all.

Offline activation is available on annual Enterprise licences from the fifteenth day after the purchase, and on any annual licence opened under an agreement with us. The steps are in the install guide. A cluster that does have a route out keeps the simpler path: an activation key and the daily check.

The Helm chart brings its own PostgreSQL, or takes a DSN to one you already run. Point it at a database you already run and the chart creates no database and no volume claim for one; the only claim left is the scanner's vulnerability-database cache. Either way the operator creates and migrates its own tables on first start — there is no SQL for you to run and no migration step to forget on upgrade.

By default the webhook failure policy is Ignore: if the operator cannot answer, deployments proceed unguarded rather than stopping. That is the safe default for a cluster you have to keep running. Any edition, Community included, can set Fail and deny anything not yet scanned — a deliberate trade, made explicitly.

Admission is replicated and spread across nodes. Periodic work — scanning, licence checks, retention — is held by exactly one replica at a time through a PostgreSQL advisory lock, so a second replica never duplicates a scan or a notification.

The operator does. The pair is generated and rotated in-cluster, and every replica picks up a new one without a restart. There is no cert-manager dependency and no annual reminder in your calendar.

Upgrade is helm upgrade; embedded migrations apply the new steps and skip the rest. Uninstall is helm uninstall plus dropping the namespace. The webhook is removed with the release, so an uninstalled operator never leaves admission blocking behind it.

You create an account at attestkeep.com, choose a package and any add-ons, and get a key. You enter that key in your own console, and the activation exchanges it for a signed certificate carrying what you bought, the cluster it was issued for and the date it runs to. Community Edition works the same way; its certificate simply has no expiry.

From then on the operator checks the certificate at every start without leaving the cluster — our signature, the expiry, and whether the fingerprint inside it is this cluster's. Separately, once a day, it checks the licence with us. The certificate is good for thirty days, so that daily check failing changes nothing for a long while; the licensing page has the whole of it.

The installation falls back to Community Edition. It does not stop, it does not lock you out, and it does not start denying deployments — scanning and admission carry on under the free limits. A security control that switches itself off over a billing date is a worse outcome than an unpaid invoice.

A certificate that lapses because the licence server has been unreachable for a month behaves the same way, and is announced well before it happens: the console warns after a week without a route and the administrators are e-mailed before the certificate runs out.

No, and deliberately so. Community Edition carries every security feature and does not expire, so it does the job a trial would — on your own cluster, for as long as you want. The paid plans add capacity, and single sign-on, rather than security capability. When a paid licence expires without renewal the installation falls back to Community Edition rather than shutting anything off.

Payments are taken by Polar Software, Inc., our merchant of record, which resells the licence to you: the invoice is Polar's, the tax due at your billing address is worked out and charged at Polar's checkout, and a card number never reaches us. The licence and the support are ours. A VAT-registered business in the EU accounts for VAT itself under the reverse charge.

Up to the number your plan pays for, yes — that is what the cluster count on the price list is. Community and Team buy one, Business three, Enterprise five. The same key activates each of them and every activation spends one slot; your account shows which clusters hold slots and how many are free.

Beyond that number the next activation is refused rather than quietly allowed. You can release a slot you are not using, or add clusters to the key you already own without touching the installations already running.

Not for billing — there is no metering and no bill that changes with usage. Each plan sets a node ceiling per cluster: Community 1, Team 6, Business 10, Enterprise 20. Additional nodes are bought one at a time, up to 50 nodes per cluster at checkout.

The operator counts the Ready nodes inside the cluster, and the count is never sent anywhere; the daily licence check carries the same three values as before. Over the ceiling nothing stops: the console and a notification say so, with a date 14 days ahead. After those 14 days only image names not yet seen this period are denied, and everything already counted keeps running. Coming back within the ceiling clears the clock.

Nothing changes for between ten days and a month, depending on how much life the certificate had left when the connection went. Failed checks are retried a few hours later rather than the next day, so an outage has to be sustained for weeks before it becomes a licensing problem — and the console warns after the first week rather than letting you find out later.

Being unreachable and being refused are different: silence spends the certificate's remaining life, while an answer saying the licence was released or revoked is applied at once.

Reinstalling the operator is free — the fingerprint is derived from the cluster, not from the operator, so deleting and redeploying it needs nothing from us and the certificate keeps working.

Rebuilding the cluster makes a new fingerprint, which is a new cluster as far as the licence is concerned, so it takes a slot. If you still have the old cluster, deactivate there first and the slot is free immediately. If it is already gone, release its slot from your account — the entry lists each cluster holding one and when it was activated, so you can tell which is which.

Thirteen instruments today: the Cyber Resilience Act — Regulation (EU) 2024/2847 — with NIS2 beside it, DORA, SOC 2's Trust Services Criteria, NIST SP 800-190, the SSDF (SP 800-218), selected SP 800-53 Rev. 5 controls, ISO/IEC 27001:2022 Annex A, GDPR Article 32, PCI DSS v4.0.1 Requirements 6 and 11, the MAS Technology Risk Management Guidelines (January 2021), the ASD Essential Eight Maturity Model (November 2023), the Control Criteria of ISMAP (August 2024), and the ISMS-P certification criteria (November 2023).

The mapping ships inside the operator rather than being fetched, so a cluster whose only route out is the licence endpoint produces the same document as a fully connected one. Each clause carries its own citation and the assessment behind it; a clause a cluster cannot answer is marked outside scope with the reason, because an evidence package that overclaims is worth less than one that admits its edges.

The free edition includes one framework of your choice; paid plans carry more.

No, and it says so on the document. It is evidence produced from your own records, and no auditor is obliged to accept it. What it does is remove the spreadsheet stage: the record of who accepted which risk, when, and for how long is already written down.

met, partial, gap and outside_scope. A pass/fail report forces every control into a lie; outside_scope says a control does not apply to a Kubernetes admission controller, which is a defensible answer and a different one from failing. If the webhook was down for forty minutes on a Tuesday, that window is in the document.

In the public issue tracker at github.com/attestkeep/attestkeep-docs. Reports from every edition are handled there in the open, including from Community Edition — the free tier is where most first reports come from, and closing them privately would waste that.

Not in a public issue. Use the private advisory path described on the security page, and you will get an acknowledgement within three working days. Fixed issues are published as advisories on the same repository once a release carrying the fix is out.

Community Edition is supported through the public issue tracker, which is also where paid editions' bugs are handled — reports are not sorted by what you paid. Paid plans add e-mail support, and from Business up your mail is handled before the queue.

We do not publish a response-time guarantee for any plan. A number on this page would be a promise made to everyone at once by a team that has not agreed to it with anyone in particular, and we would rather answer quickly than write down a figure we might have to defend on a bad week.