CZtack

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.

Design Principles

More TODO here

Consistent Tagging

We tag all applicable resources with 'owner', 'project', 'env', 'service' and 'managedBy'.

Modules

AWS Default VPC security

This will name, tag, and optionall lock down AWS default VPCs.

AWS IAM ECS Task Role

This creates a role for use with an ECS task, you bring your own policy and we create the role for you.

AWS IAM Group assume-role

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.

AWS IAM Group console-login

This will create a group, add users to it, and grant permission to log into the AWS console and manage one's own credentials.

AWS IAM password policy

This module will create a good password policy for your AWS account.

AWS IAM instance profile

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).

AWS IAM cloudwatch logs policy

This will create a policy that allow writing to cloudwatch logs.

AWS IAM poweruser role

This will create a poweruser role, based off the AWS-managed "poweruser" policy, but with a few additions that we find useful.

AWS IAM Role Cloudfront poweruser

This will create a role that gives "poweruser" level access to cloudfront.

AWS IAM Role ECS poweruser

This will create a role that gives "poweruser" level access to ECS.

AWS IAM Role infraci

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.

AWS IAM role readonly

This creates a readonly role, based off the AWS-managed readonly policy, but with a few changes.

AWS IAM role security-audit

This creates a security-audit role, based off the AWS-managed policy, but with a few changes.

GitHub Webhooks to S3

Accept GitHub webhooks and store them in S3

Adding a new module

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.

Writing tests

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 terraform 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 init so 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.

Test Dependencies

go
terraform
terraform-provider-bless - Place it in the same directory as your terraform executable. dirname \which terraform``

syllogy / cztack Goto Github PK

cztack's Introduction