What Attestkeep does not do

A security tool that answers "yes, we do that too" to every question is a tool nobody can plan around. Attestkeep decides what may enter the cluster and keeps the record of that decision. These five jobs are outside that line, on purpose, and here is what to run beside it for each.

The short version

Runtime behaviour detection

Attestkeep does not watch syscalls, does not profile processes, and does not flag network anomalies inside a running container. A container that was admitted and then starts a shell, reads a file it never touched before, or dials an address it has no business dialling produces no event here.

This is a design consequence, not a gap waiting to be filled. Behavioural detection means a privileged agent on every node, seeing every process on that node. Attestkeep is two Deployments in one namespace — the operator and the scanner — with no DaemonSet, no host mounts and no node-level access; the full inventory is published precisely so you can check that. Adding behavioural detection would mean asking for the privilege we currently tell you we do not have.

Pair it with Falco or Tetragon. Attestkeep is the gate; they are the patrol. The gate decides what is allowed through and can prove afterwards what it decided; the patrol watches what the admitted thing then does. Neither substitutes for the other, and a cluster that has funded only one of them should know which one it bought.

Manifest and infrastructure misconfiguration scanning

Attestkeep does not scan your Terraform, your Helm charts in a repository, or your manifests before they are applied, and it does not assess the cluster's own configuration against a CIS benchmark. Whether the API server has anonymous auth on, whether etcd is encrypted at rest, whether kubelet ports are exposed — none of that is read, scored or reported here.

Pair it with Kubescape, or with Checkov and kube-bench.

There is one honest overlap, and it is worth naming rather than glossing. The workloadHardening control in an ImageSecurityPolicy does inspect a pod's own specification at admission — privileged containers, host namespaces, hostPath mounts and their relatives — and can refuse on what it finds. That control exists because admission is the only place a pod can actually be refused for those things: a posture scanner can tell you the pod is privileged, but only the gate can decline to let it start. It looks at the object being admitted and nothing else. It does not audit the cluster's configuration, and it is not a benchmark report.

Cloud account context

Attestkeep has no view of your cloud account. IAM roles and trust policies, storage buckets and their public-access settings, security groups, load balancers and what they expose to the internet — all of it is outside this product, and the operator holds no cloud credentials that would let it look. Its horizon ends at the cluster it runs in.

That means a workload can be admitted here on a perfectly clean image and still be reachable from the internet through a rule Attestkeep never saw, or hold a role far wider than it needs. Pair it with your cloud provider's own posture tooling, or with a CSPM product.

Code-level reachability analysis

When a scan reports a vulnerable package inside an image, Attestkeep does not determine whether the vulnerable function is ever called. There is no call-graph analysis in this product, so a finding in a library your application never invokes is reported the same as one on your hottest path. Severity and the thresholds in your policy are what separate them, and that is a blunter instrument than reachability.

What Attestkeep does instead is accept the producer's statement. requireVulnAttestation makes an image carry a signed vulnerability-scan attestation, and attestationMaxAge keeps that statement fresh — the claim travels with the image, verified, rather than being re-derived at the gate. Version 1.1 will accept VEX documents on the same footing, so a "not affected" judgement your build pipeline already produces can be honoured at admission instead of re-argued in a triage screen.

For reachability itself, pair with your SCA vendor. The output that matters here is a statement Attestkeep can verify and record.

Source repository dependency scanning

Attestkeep does not read your repositories. It does not watch lock files, does not open pull requests that bump a dependency, and has no connection to your source forge at all.

The distinction is about the subject, not the depth. Attestkeep scans what is inside the image that reaches the cluster — operating system packages and language packages alike: npm and PyPI dependencies, Go modules embedded in the binary, JARs on the classpath. That is often a strictly different set from what the repository declares, because an image also carries base-layer packages nobody wrote a line of manifest for, and because the image that deployed on Tuesday was not necessarily built from the commit that is on the branch today. Repository scanning tells you what your next build will contain; Attestkeep tells you what is running now, and refuses it if your policy says so.

Pair it with Dependabot or Renovate. Fixing a dependency belongs where the fix is committed.

The rule

The line is the door. What affects the decision made at that door — the image, its digest, its packages, its signature, its attestations, the specification of the pod asking to start, and the record of what was decided and under which policy — is inside this product. Watching what happens after the door, or judging the ground the door is set in, is not. Every one of the five above is a real job and most clusters need several of them; they are simply not this one, and a product that pretended otherwise would be harder to trust about the part it does do.