# Cloud Custodian Terraform Provider
Custodian's terraform provider enables writing and evaluating
custodian policies against Terraform IaaC modules.
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
```yaml
- resource: terraform.aws_dynamodb_table
name: ensure encryption
filters:
server_side_encryption.enabled: true
kms_key_arn: key_alias
```
#
custodian run terraform.yml
custodian report --format=
# dedicated cli
custodian run-source terraform.yml
Raw data
{
"_id": null,
"home_page": "https://cloudcustodian.io",
"name": "c7n-terraform",
"maintainer": null,
"docs_url": null,
"requires_python": "<4.0,>=3.8",
"maintainer_email": null,
"keywords": null,
"author": "Cloud Custodian Project",
"author_email": null,
"download_url": null,
"platform": null,
"description": "\n# Cloud Custodian Terraform Provider\n\nCustodian's terraform provider enables writing and evaluating\ncustodian policies against Terraform IaaC modules.\n\n\ntldr: we want to enable writing custodian policies against IaaC assets (terraform, cfn, etc) directly in devops/ci pipelines.\n\n# Purpose\n\nThe primary purpose of this is to integrate with ci/cd pipelines to\nevaluate compliance and governance early in the deployment\nlifecycle. Custodian cloud providers provide for realtime detection\nand remediation as a detective control against infrastructure already\ndeployed in the environment regardless of how it was provisioned. As\nan initial target, the terraform provider is designed to complement\nthat with preventive enforcement earlier in the\nlifecycle. ie. enabling a shift-left to policy enforcement.\n\n\n# Pipeline CLI\n\nIn looking at expanding out to shift-left pipeline use cases, one\nthing that becomes clearer is that custodian's default cli ux isn't\nperhaps the best fit for the target audience. When we're operating\nagainst cloud resources we have to deal with cardinalities in the\nthousands to millions. When we're operating in the pipelines we're\ntypically dealing with resource cardinalities in the 10s. Additionally\nthere is a goal expectation of having rich output that correlates to\nthe ci tooling (github annotations, etc) or pinpointing the issue for\na developer, as well as color'd output and other niceties. we could\nincorporate that as a new subcommand into the main custodian cli\n(dependent on presence of iaac providers installed), or have a\ndedicated subcommand associated.\n\nThe other main deficiency with the cli is that we're not able to pass\ndirectly the iaac files as data sets we want to consider. Typically\npolicies have expressed this as query parameterization within the\npolicy as being able to specify the exact target set. But the use case\nhere is more typically command line driven with specification of both\npolicy files and target IaaC files, as well as other possible vcs\nintegrations (policystream style wrt delta files) or ci integrations.\n\n# Resources\n\nwrt 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.\n\nLoose 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.\n\n# Examples\n\n```yaml\n- resource: terraform.aws_dynamodb_table\n name: ensure encryption\n filters:\n server_side_encryption.enabled: true\n kms_key_arn: key_alias\n```\n\n\n\n# \n\n custodian run terraform.yml\n \n custodian report --format=\n \n# dedicated cli\n\n\n custodian run-source terraform.yml\n\n",
"bugtrack_url": null,
"license": "Apache-2.0",
"summary": "Cloud Custodian Provider for evaluating Terraform",
"version": "0.1.25",
"project_urls": {
"Documentation": "https://cloudcustodian.io/docs/",
"Homepage": "https://cloudcustodian.io",
"Repository": "https://github.com/cloud-custodian/cloud-custodian"
},
"split_keywords": [],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "b763ad621daff1be63fb49b7374550304f5f2c430f9eaac3b74c6073fbc18fbd",
"md5": "fcc06a088933e6ebe5c4f7637364191c",
"sha256": "e37144ce7d09dc4effbfb7bae3056ece3cedff0e6f117cd53f1cfb3161629e7b"
},
"downloads": -1,
"filename": "c7n_terraform-0.1.25-py3-none-any.whl",
"has_sig": false,
"md5_digest": "fcc06a088933e6ebe5c4f7637364191c",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": "<4.0,>=3.8",
"size": 7052,
"upload_time": "2024-03-26T21:21:33",
"upload_time_iso_8601": "2024-03-26T21:21:33.208802Z",
"url": "https://files.pythonhosted.org/packages/b7/63/ad621daff1be63fb49b7374550304f5f2c430f9eaac3b74c6073fbc18fbd/c7n_terraform-0.1.25-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-03-26 21:21:33",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "cloud-custodian",
"github_project": "cloud-custodian",
"travis_ci": false,
"coveralls": true,
"github_actions": true,
"lcname": "c7n-terraform"
}
JSON
