Troubleshooting

Start with the operator's own view. Most of what looks like a cluster problem is one of five things.

kubectl -n attestkeep get pods
kubectl -n attestkeep logs deploy/attestkeep --tail=200
kubectl -n attestkeep logs deploy/attestkeep-scanner --tail=200

Deployments are being denied and I do not know why

Every denial carries a reason, and the console lists them with the policy that produced each one. The three common causes:

The digest has never been scanned and coldImagePolicy denies unknown images. Wait for the scan or change the setting.
The monthly image quota is exhausted. Only new image names are denied; everything already counted keeps working. The licences page shows where you are.
The policy is doing its job. The reason names the severity or the missing signature. If it should be allowed, make an exception with an owner and an expiry rather than widening the policy.

Everything is being admitted and nothing is being checked

With failurePolicy: Ignore, an operator that is not answering means unreviewed rather than blocked — by design, and it looks exactly like this. Check that the webhook pods are ready and that the ValidatingWebhookConfiguration still exists.

kubectl get validatingwebhookconfiguration | grep attestkeep

Activation is refused

What you see	What it means
Invalid activation key	The key does not match a licence. Copy it again from the panel; the alphabet deliberately excludes the characters that get misread.
Cluster quota exceeded	Every slot is in use. The error names the clusters holding them and when each activated — release one from the panel.
Licence revoked or expired	Check the licences page. A revoked licence applies at the next daily check rather than instantly.
Cannot reach the licence service	Allow `lic.attestkeep.com` on port 443. See air-gapped.

The same cluster spent a second slot

It should not: the fingerprint is a hash of the kube-system namespace UID, and reinstalling into the same cluster hands the existing slot back. A genuinely rebuilt cluster is a different cluster and gets a different fingerprint — release the old slot from the panel.

Scans never finish

A private registry. Nothing needs configuring, but the operator can only use pull secrets the pod references or that are on its service account. A secret nothing references is invisible to it.
A plain-HTTP registry. It has to be named in scan.insecureRegistries. Silently downgrading a connection is not a decision this product makes for you.
A stale or unreachable vulnerability database. In an air-gapped cluster, check the mirror.
A very large image against a 10m timeout. Raise scan.timeout.

A second scanner replica stays pending

The scan cache is a ReadWriteOnce volume, so it binds to one node and a second replica has nowhere to schedule. The chart refuses this combination at install; if you reached it another way, either move the cache to a ReadWriteMany volume or go back to one replica.

Reporting a problem

Open an issue on the public tracker. Please do not paste cluster names, image references, policy contents, credentials or tokens into a public issue — a redacted log is more useful than a deleted one. For a security vulnerability use the disclosure process instead.