OSS Spotlight: Cloud Custodian (c7n)

An open-source policy engine that turns "we should really block public S3 buckets across every account" from a recurring audit into a five-line YAML file.

Cloud Custodian — usually just called c7n — is a rules engine for managing AWS, Azure, and GCP resources through policy-as-code. It's a CNCF Incubating project, Apache 2.0 licensed, led by a community of hundreds of contributors, and sitting at just over 6,000 stars on GitHub. It doesn't get the mainstream coverage that a CSPM product pitch deck does, but it's doing real work quietly in a lot of environments that would otherwise be running the same manual audit script every quarter.

How it works

Every c7n policy is YAML, and every policy follows the same three-part shape:

• resource — what you're targeting (aws.s3, aws.ec2, azure.vm, and well over a hundred other resource types)
• filters — the conditions a resource has to match (public access, missing tags, unencrypted volumes, cross-account permissions, whatever you're looking for)
• actions — what happens to anything that matches (tag it, notify on it, remediate it, or just report it)

That's the whole model. No custom scripting language to learn, no SDK boilerplate — just declare what you're looking for and what should happen when you find it.

A concrete example

Here's a real policy from the project's own README — it finds S3 buckets with cross-account access and strips it out:

policies:
 - name: s3-cross-account
   description: |
     Checks S3 for buckets with cross-account access and
     removes the cross-account access.
   resource: aws.s3
   region: us-east-1
   filters:
     - type: cross-account
   actions:
     - type: remove-statements
       statement_ids: matched

Five lines of actual policy, and it directly covers one of the access-control items in our S3 hardening cheat sheet — instead of manually reviewing bucket policies for stray cross-account grants, this runs on a schedule and fixes them.

Getting started

python3 -m venv custodian
source custodian/bin/activate
pip install c7n

Then, before running anything with real consequences, run it in dry-run mode:

custodian run --dryrun -s out policy.yml

--dryrun applies the filters and shows you exactly which resources would be affected, without touching anything. It's the equivalent of terraform plan before terraform apply — and given that c7n's own example gallery includes policies that terminate EC2 instances outright (an actual example: auto-terminating any new instance whose EBS volumes aren't encrypted), dry-run isn't optional caution, it's the normal way to develop a policy before trusting it with the actions block live.

The honest caveats

• It needs real permissions to be useful — read access at minimum, write/remediate access if you want it to actually fix things, not just report. The IAM role c7n runs under deserves the same least-privilege scrutiny you'd apply to anything else with account-wide reach.
• The actions block is where it gets serious. Filters alone are just a fancy describe call. The moment a policy includes an action beyond "notify," it can modify or delete real infrastructure — worth treating every new policy as untrusted until it's been run dry, reviewed, and tested somewhere that isn't production.
• Community pace varies by provider. AWS support is the deepest and most actively maintained; Azure and GCP coverage exists and works, but it's worth checking recent commit activity on the specific resource type you're depending on before betting a compliance requirement on it.

For a team already comfortable with YAML and looking to stop manually re-running the same audit checklist every quarter, it's a genuinely useful tool — not flashy, just quietly doing the job.

Sources: Cloud Custodian documentation · cloud-custodian/cloud-custodian on GitHub · Cloud Custodian — Getting Started