proposal - shift left - policies on iaac assets

[kapilt]

tldr: we want to enable writing custodian policies against IaaC assets (terraform, cfn, etc) directly in devops/ci pipelines.

Purpose

The primary purpose of this is to integrate with ci/cd pipelines to evaluate compliance
and governance early in the deployment lifecycle. Custodian cloud providers provide for
realtime detection and remediation as a detective control against infrastructure already
deployed in the environment regardless of how it was provisioned. As an initial target, the terraform provider is designed to complement that with preventive enforcement earlier in the lifecycle. ie. enabling a shift-left to policy enforcement.

Pipeline CLI

In looking at expanding out to shift-left pipeline use cases, one thing that becomes
clearer is that custodian's default cli ux isn't perhaps the best fit for the target audience. When we're operating against cloud resources we have to deal with cardinalities in the thousands
to millions. When we're operating in the pipelines we're typically dealing with resource
cardinalities in the 10s. Additionally there is a goal expectation of having rich output that correlates to the ci tooling (github annotations, etc) or pinpointing the issue for a developer, as well as color'd output and other niceties. we could incorporate that as a new subcommand into the main custodian cli (dependent on presence of iaac providers installed), or have a dedicated subcommand associated.

The other main deficiency with the cli is that we're not able to pass directly the iaac files as
data sets we want to consider. Typically policies have expressed this as query parameterization
within the policy as being able to specify the exact target set. But the use case here
is more typically command line driven with specification of both policy files and target
IaaC files, as well as other possible vcs integrations (policystream style wrt delta files) or ci integrations.

Resources

wrt to the iaac provider we can either operate loosely typed or strongly typed. with strong typing we can spec out exact attributes and potentially do additional possibly validation wrt to user specified attributes, but it requires keeping an up to date store of all iaac provider assets, which could be both fairly large and rapidly changing (terraform has over 150 providers all release independently). for now, I think it would be good to keep to loose typing on resources. .. and perhaps document provider addressable resource attributes as part of documentation.

Loose typing would enable working out of the box with extant providers, but policy authors would have to consult reference docs for their respective providers on available attributes or even provider resource type existence. From a custodian perspective we would use a common resource implementation across provider resource types.

Examples

- resource: terraform.aws_dynamodb_table
   name: ensure encryption
   filters:
      server_side_encryption.enabled: true
      kms_key_arn: key_alias

Note we're not trying to normalize attributes to the underlying types from the same resource in a provider. effectively its a different resource even though its also represented by aws.dynamodb-table as there's too much variation on casing and exposed attributes to cover off on the deltas.

[jtroberts83]

This would be absolutely amazing! Our developers have been asking for something like this for a while now and the value add would be HUGE!!!!

[pjshort22]

That would be great! for our Developers and save us a lot of work and let Developers know the issues before deploying.

[matt-hutchins]

Our Developer Community has been asking for this feature for a while and the initial response to this proposal is very positive. Looking forward to seeing how this progresses.

[jhegyi]

That would be great! Our Developer Community has been asking for this feature for a while

[EhrMike]

That would be great for the Developer Community!

[aakifshaikh]

Thats called proactive security rather than being a reactive/fire-drill. Love the idea.

[PelayoMarinas]

I love this feature!

[skylar-stark]

This would be a great feature add!

[jfjcn]

Heck yeah!

[dsatgithub]

👍 anything to make life easier.

[sergei-ivanov]

Question to the audience/maintainers: I wonder how much overlap this is going to have with tflint and tfsec ? They are already pretty mature tools with extensive sets of rules, and we have been successfully using both of them for the last few months in CI and/or as pre-commit hooks. And we have been using c7n in production for over 18 months now, but I am not sure whether our c7n policies for AWS will easily translate into a set of policies for static analysis of our Terraform codebase.

[marcoceppi]

@sergei-ivanov great questions. There's certainly some overlap between tflint and tfsec. I've used both before as well, and both have a very mature set of rules when evaluating terraform statically.

The main difference between tflint and tfsec compared to c7n-terraform is that c7n_terraform uses the same policy format as all the c7n tools. Both tflint and tfsec have their rules embedded in their runtime, great for a baseline standard, but if you're looking to extend those with policies specific to your organization or usecase you need to fork the project.

For people like yourself already using these tools c7n-terraform provides a means to augment those tools policies with your own expressed in a format similar to the rules you're already using to evaluate cloud environments. For those not already using tflint or tfsec this tool provides a common language for building and evaluating policies against terraform modules.

There are some other differences between these tools. One example is in how c7n-terraform parses the terraform, it's nuanced but it attempts to recurse all including modules allowing us to validate rules further down the dependency tree (currently only local, but potentially remote modules in the future) enforcing policies as far down as it can. Another example, the first pass of this c7n-terraform is only static, though there's certainly room to make it more dynamic and allow, optionally, to evaluate a modules' state in it's processing which would yield a richer state of data to author policies against.

Ultimately, I see c7n-terraform as being complimentary to the existing tfsec and tflint projects. It allows individuals like yourself to continue using these tools and supplement policies which aren't part of baseline but that you'd like to enforce. Either at a cost savings level, security level, or organization best practice.

[kapilt]

work on this capability has started in #7803, its pretty early on though, at the moment its just simple k=v value filters. we decided against trying to parse terraform / hcl in python versus having an extension that does the parsing in golang.