A Gatekeeper Constraint's status lists 20 violating PVCs; why is that not the offender count?

## The list is a sample; the count is elsewhere When Gatekeeper's audit controller finishes a sweep it writes results onto each Constraint's own `status`. The part people read is `violations` — a list of offending objects with kind, name, namespace and the rule's message. It is capped. `--constraint-violations-limit` bounds how many entries are stored per Constraint, and its default is **20**. The cap exists for a good reason. Status is part of the Constraint object, stored in etcd and shipped to every watcher. A rule that matches four hundred PersistentVolumeClaims would otherwise write four hundred messages into one object on every sweep, repeatedly, for every noisy rule you have. The count you actually want is right there next to the list: `totalViolations`. A status that says `totalViolations: 412` with twenty entries beneath it is not inconsistent — it is the design. Reading the list's length as the population is the classic error, and it is the one that makes a security lead tell leadership that twenty claims are unencrypted when four hundred are. ```yaml status: auditTimestamp: "2026-08-27T02:14:09Z" totalViolations: 412 violations: - enforcementAction: dryrun kind: PersistentVolumeClaim name: data-payments-0 namespace: payments message: 'storageClassName "standard" is not in the approved encrypted set' # ... 19 more, then the list simply stops ``` ## Four more ways the number can still be wrong Even `totalViolations` is not a live population count. Interrogate it: **It is stale by design.** Audit refreshes on its interval. `auditTimestamp` tells you as of when. If the audit pod is unhealthy, a sweep errored partway, or someone set `--audit-interval=0`, the status keeps whatever it last wrote — an old number is visually identical to a current one apart from that timestamp. A status showing zero violations deserves the same suspicion: check that a sweep actually ran recently. **Part of the estate may be outside the sweep.** Namespaces exempted from Gatekeeper are not audited. If audit is reading a replicated cache rather than the live API, kinds nobody replicated contribute nothing. And the Constraint's own match block is a filter — if it selects a label or namespace set narrower than you assume, the objects you care about were never in scope. **Nothing was blocked.** If `enforcementAction` is `dryrun`, admission is still accepting new non-compliant claims while you read the status. The number is not a shrinking backlog; it is a moving one. Distinguishing "412 legacy claims to migrate" from "412 and rising" is the difference between a project plan and a leak. **A capped list biases what you see.** The twenty entries you got are not a random sample and should not be treated as representative of which teams or namespaces are affected. If you need to know where the four hundred live, you need all of them, not the page audit chose to keep. ## Getting the full list, carefully Two honest options. Raise `--constraint-violations-limit` deliberately for one investigation, read what you need, and put it back — leaving it at several thousand across many noisy Constraints bloats objects in etcd, makes every watcher carry the payload, and can push a Constraint toward the object size ceiling. Or bypass status entirely and enumerate the objects yourself with a direct query on the property the rule checks, which for the StorageClass rule is a one-line list of claims and their `storageClassName`. The second scales better and is what most teams end up doing, with audit's total as the cross-check. ## Reading a sweep as a population estimate The question behind the question is what you are entitled to conclude from one status block. A defensible statement sounds like: *as of 02:14 today, the audit sweep found 412 PersistentVolumeClaims outside the approved encrypted StorageClass set, across the namespaces audit covers; the rule is in dryrun so new ones are still being created; the twenty named in status are a truncated sample and the full list came from a direct query.* Every clause in that sentence is a hedge you can defend. The indefensible version is "we have twenty unencrypted volumes" — a number that is wrong by a factor of twenty, presented as a fact, sourced from a field that never claimed to be the total. The mechanical knowledge here (a cap, a default of 20, a `totalViolations` field) is small. The habit it protects — never quote a number out of a truncated view without checking the denominator and the timestamp — is the thing being tested.