It answers who signed the image. Not what is in it.

What policy-controller is

An admission controller from the Sigstore project. A ClusterImagePolicy names the authorities an image must satisfy — a public key, or a keyless identity and issuer — and the attestations it must carry; a pod is admitted when every matching policy has at least one authority that passes. It resolves tags to digests so that what runs is what was admitted, enforcement is switched on per namespace, and a CUE or Rego policy can be applied to the contents of an attestation once its signature has been verified.

It is Apache-2.0, free, small, and it is maintained by the people who define cosign's formats. For a cluster whose supply-chain story is "everything we run is signed by our own build system", that is a complete answer and you should use it.

Where they overlap

Squarely on signature and attestation verification at admission. Attestkeep verifies cosign signatures with a key or keylessly against an identity and issuer, checks in-toto attestations and can require them to be no older than a maximum age, requires a verified SBOM or provenance statement where the policy says so, and pins images to digests. If that list is what you came for, policy-controller does it and costs nothing.

Where the seam is

A signature says somebody vouched for these bytes. It does not say the bytes are safe. An image signed this morning by a build system you trust can carry a critical vulnerability published last night, and every policy in the cluster will admit it, correctly, because the signature is valid. Verification and vulnerability are different questions and only one of them is being asked.

policy-controller has no scanner, keeps no vulnerability database and holds no history: it evaluates the request in front of it and moves on. Attestkeep asks both questions from one verdict — the signature, and Trivy's findings on the same digest, with CISA's known-exploited catalogue marking the ones under attack — then keeps the answer. The database refreshes every six hours and every image is rescanned daily, so an image that was clean when it was admitted does not stay clean by assumption.

And the record outlives the request. Verdicts are written to a PostgreSQL you control under the hash of the policy that produced them, which is what makes a period report possible at all: thirteen regulations and control sets, 293 clauses, each quoted by citation and marked met, partial, gap or outside scope, signed inside your cluster and verifiable by your auditor without us.

Which one you need

policy-controller alone when the images you run are all built and signed by you, when what you need enforced is provenance rather than content, and when you would rather stay as close to the Sigstore project as a deployment can get.

Attestkeep when "signed" is not the same as "safe" in your threat model — base images from elsewhere, vendor images, anything you did not build — or when the signature check has to be evidence rather than behaviour. Both run as validating webhooks and can sit in one cluster, though an image rule is better expressed once, in one of them. Community Edition is free forever, so you can put ours next to yours before you decide.