validate pre-commit hook? about cloud-custodian

[jmreicha]

Hey @ajkerrigan thanks for the info and suggestions. Happy to bring it up in Slack if you think it’s worthwhile.

The way I’ve seen it done elsewhere is to provide both a dockerized and non dockerized version of the hook. I can put together a PR in my spare time.

[JMReich]

Hey, just fyi, you tagged the wrong account.
Thanks!

[ajkerrigan]

I believe the idea has come up before, though at a glance I don't see other issues so thanks for filing 👍 . There's nothing official today, though you can certainly use local hooks effectively if that's helpful. If you're running in an environment that already has custodian installed locally, you can use something like:

.pre-commit-config.yaml

repos:
- repo: local
  hooks:
  - id: c7n-validate
    entry: custodian validate
    language: system
    name: Validate Cloud Custodian Policies
    files: policies/.*\.y?ml$

While if you're looking for something that doesn't assume that custodian is already available, you could lean on the Custodian Docker image instead. (Note: I've tried the docker and docker_image support which sounds smoother in theory, but it auto-mounts local code to /src inside the container which clobbers the custodian source and prevents the image from working properly).

./bin/c7n-validate.sh

#!/usr/bin/env bash
set -euo pipefail

for f in $*; do
	echo "Validating $f..."
	docker run -v "$PWD":/precommit:rw,Z "cloudcustodian/c7n:0.9.37.0" validate "/precommit/$f"
done

.pre-commit-config.yaml

repos:
  - repo: local
    hooks:
      - id: c7n-validate
        name: Validate Cloud Custodian Policies
        language: script
        entry: ./bin/c7n-validate.sh
        files: policies/.*\.y.*ml$

It's worth raising this on a community meeting call or in Slack though - if it's something folks are interested in, it could be reasonable to provide an official hook 🤔 .

[jmreicha]

Hey @ajkerrigan just opened #9581 let me know what you think. I mentioned it in the PR but I was thinking of adding Docker support in a future PR when I get more time to play with it.

[ajkerrigan]

Thanks again, just saw this was merged. But since @kapilt mentioned supply chain risk...

I think the main mitigation for supply chain attacks is pinning repo tags/hashes in your pre commit config, since under the hood it's effectively checking out that repo, running a dev install and then whatever command is defined in the repo's hook config.

@jmreicha's point about splitting hook definitions into a separate repo is a good callout though. That lets us use a pyproject.toml explicitly for pre-commit's use, which also means we'd install a built wheel rather than running a dev install (which would also mean a quicker first run). I think there's value in starting simple, but it's worth keeping this stuff in mind 🤷

[ajkerrigan]

Hey, just fyi, you tagged the wrong account. Thanks!

Oops, apologies and thanks for the heads up :)

[jmreicha]

I think the main mitigation for supply chain attacks is pinning repo tags/hashes in your pre commit config, since under the hood it's effectively checking out that repo, running a dev install and then whatever command is defined in the repo's hook config.

@ajkerrigan sounds good, I will take a look at how other folks are handling this and see how to get it addressed.