Containers, Kubernetes and infrastructure as code

33 container rules and a policy table of 1,082 controls, over the files that describe where your code runs. Cordon reads the definitions -- it never contacts a cluster, a cloud account or a registry to do it.

The 33 container rules above match a pattern against a file: they answer "does this contain something alarming". Most infrastructure policy is the other question -- this resource is missing that setting -- and a regex cannot express absence over a region it has no notion of.

   A FILE IS READ INTO BLOCKS FIRST     resource "aws_db_instance" "prod" { ... }      one block     kind: Deployment                               one block     Resources: { Bucket: { Type: AWS::S3::Bucket   one block     services: { web: ...                           one block   AND EACH POLICY ASKS ONE OF TWO THINGS INSIDE IT     forbid    the block says something insecure     acl = "public-read"     require   the block does not say something it   storage_encrypted               must -- which is the provider's       absent means false               default, and is written nowhere

storage_encrypted absent from an aws_db_instance is an unencrypted database, and the file does not mention it. That is the half the pattern rules could not reach, and it is where most of the 1,082 controls live: encryption at rest and in transit, public exposure, logging, backups, deletion protection, obsolete TLS, and the Kubernetes and Compose settings that hand a container the node.

220 of them are written by hand, and 862 are generated. The rest are generated from the providers' own schemas, because which resources have storage_encrypted is a fact rather than a memory, and a policy naming an attribute a provider does not have can never fire -- it looks exactly like a clean scan.

   terraform providers schema -json     ->  3,845 resources, with every                                            attribute and its type   a control table                      ->  what deletion_protection means,                                            and why its absence matters   scripts/build_iac_policies.py        ->  one policy per resource that                                            actually has the attribute

Every policy, written or generated, ships with the block it must report and the block it must not, and the suite runs both on every push -- a control that stops matching fails the build rather than quietly reporting nothing.

cordon-scanner rules list | grep IAC     # the pattern rules and the policies

A Deployment, StatefulSet, DaemonSet, Job, CronJob or Pod names images, and so does a Kustomization's images: override. Each one is a dependency like a package, read from the manifest Kubernetes would apply:

  Cordon's default gate fails a build on compromise, and reports  posture without failing it.

Every rule in this tutorial sits in the container or infrastructure threat domain, and both are in policy.advisory_domains by default. You will see them in the report; they will not turn the build red. That is deliberate -- these findings are frequently correct and intentional, and a gate that fails on them gets a blanket exception added, at which point it protects nothing.

Two lines make them blocking:

policy:  advisory_domains: []

# everything, including manifests wherever they livecordon-scanner scan .# just this groundcordon-scanner scan . -f json:out.jsonjq '.findings[] | select(.rule_id | test("CONTAINER|K8S|IAC|HELM")) |    {rule_id, path: .location.path}' out.json# make posture blocking -- config only, there is no CLI flag#   cordon.yaml:#     policy:#       advisory_domains: []cordon-scanner scan . --config strict.yaml --fail-on medium

Next: 09 · The advisory database.