> ## Content Index
> Fetch the complete content index at: https://secblog.reedcloudsec.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# OSS Spotlight: Cloud Custodian (c7n)
- URL: https://secblog.reedcloudsec.com/oss-spotlight-cloud-custodian/
- Published: 2026-09-24T20:22:11.000Z
- Updated: 2026-09-24T20:22:11.000Z
- Description: An open-source policy engine that turns a recurring audit of public S3 buckets across every account into a five-line YAML file, plus the dry-run habit that keeps it safe.
- Author: Marselis A. Reed
- Tags: OSS & Tooling Spotlight

*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:

```yaml
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](https://secblog.reedcloudsec.com/aws-s3-bucket-hardening-cheat-sheet/) — instead of manually reviewing bucket policies for stray cross-account grants, this runs on a schedule and fixes them.

## Getting started

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

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

```shell
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](https://cloudcustodian.io/docs/overview.html?ref=secblog.reedcloudsec.com) · [cloud-custodian/cloud-custodian on GitHub](https://github.com/cloud-custodian/cloud-custodian?ref=secblog.reedcloudsec.com) · [Cloud Custodian — Getting Started](https://cloudcustodian.io/docs/aws/gettingstarted.html?ref=secblog.reedcloudsec.com)