Cztack (pronounced "stack") is CZI's collection of Terraform modules. We use these as way to scale our infrastructure work.
These modules are compatible with Terraform 0.12 and up.
More TODO here
We tag all applicable resources with 'owner', 'project', 'env', 'service' and 'managedBy'.
This will name, tag, and optionall lock down AWS default VPCs.
This creates a role for use with an ECS task, you bring your own policy and we create the role for you.
This module with create and IAM group, add users to it and grant the grouop permission to assume a role. This is commonly used for cross-account access control.
This will create a group, add users to it, and grant permission to log into the AWS console and manage one's own credentials.
This module will create a good password policy for your AWS account.
This module will create an EC2 instance profile, attaching to it a new IAM role with permissions to run standard system agents (Systems Manager Agent and Cloudwatch Logs Agent).
This will create a policy that allow writing to cloudwatch logs.
This will create a poweruser role, based off the AWS-managed "poweruser" policy, but with a few additions that we find useful.
This will create a role that gives "poweruser" level access to cloudfront.
This will create a role that gives "poweruser" level access to ECS.
This is a role we find useful for running CI jobs for terraform code. It is based on the AWS-managed policy for readonly, but includes a few additions, like the ability to read secrets.
This creates a readonly role, based off the AWS-managed readonly policy, but with a few changes.
This creates a security-audit role, based off the AWS-managed policy, but with a few changes.
Accept GitHub webhooks and store them in S3
To create a new module, copy the module-template directory and modify as you see fit. And make sure to add the module to the list of modules to test in .github/workflows/ci.yml.
A few notes on writing test for this repo. Note that this is new ground for us, so this will be a work in progress.
- To make modules testable, all fields that have a unique constraint need to be parameterizeable. Otherwise concurrent tests will conflict.
- It is tempting in testing module A to use module B to set up some context, but because terragrunt will just store the statefile locally, you can have a conflict.
- We've tried to avoid this for now and set up context more directly
- And also to not run tests in parrallel
- and to clean up state files before and after each run
- our linter requires a test for each module. At the very least run
initso that its syntax is checked. See an example here. - AWS IAM is eventually consistent and supposedly is homed in us-east-1, so its probably best to run all tests that use IAM in that region.
- go
- terraform
- terraform-provider-bless - Place it in the same directory as your terraform executable.
dirname \which terraform``