Infrastructure as Code (IaC) Rules

infrastructureterraformdevops

Conventions for writing maintainable, secure, and idempotent infrastructure code with Terraform, Pulumi, or CDK, covering module structure, state management, and change workflows.

Целевые файлы

Файл	Формат
.cursorrules	plaintext
CLAUDE.md	markdown

Содержимое

# Infrastructure as Code Rules ## General Principles - All infrastructure must be defined as code — no manual console changes in environments managed by IaC. - IaC configurations must be idempotent: applying the same code multiple times produces the same result. - Treat IaC code with the same standards as application code: peer review, linting, testing, version control. - Document every resource with a comment explaining its purpose and business context. ## File & Module Structure (Terraform example, adapt for Pulumi/CDK) - Organize by environment: `environments/prod/`, `environments/staging/`, `environments/dev/`. - Shared modules live in `modules/`: `modules/vpc/`, `modules/ecs-service/`, `modules/rds/`. - Each module must have: `main.tf`, `variables.tf`, `outputs.tf`, `README.md`. - Use consistent file naming: `main.tf` (resources), `variables.tf` (inputs), `outputs.tf` (outputs), `locals.tf` (computed values), `versions.tf` (provider pins). ## Naming Conventions - Resource names: `{project}-{environment}-{resource-type}-{descriptor}`. Example: `mindaxis-prod-rds-primary`. - Variables: `snake_case`. Boolean variables: `enable_*` or `create_*` prefix. - Locals: `snake_case`. Use locals to avoid repeating complex expressions. - Module names: `snake_case` in code, `kebab-case` in directories. ## Variables & Outputs - Every variable must have a `description` and explicit `type`. Use `validation` blocks for constrained values. - Mark sensitive variables with `sensitive = true`. Never output sensitive values without `sensitive = true`. - Prefer specific types over `any`: use `object({ ... })`, `list(string)`, `map(number)`. - Provide defaults only for genuinely optional variables. Required infrastructure inputs should have no default. ## State Management - Always use remote state (S3 + DynamoDB, GCS, Terraform Cloud) — never commit `.tfstate` files. - Enable state locking to prevent concurrent applies. - Use state workspaces or separate state files per environment — never share state across environments. - Enable state versioning and point-in-time recovery on the backend storage. ## Secrets - Never hardcode secrets in IaC code or variable defaults. - Reference secrets from a secrets manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager). - Use `data` sources to read secrets at apply time — never bake secrets into resource definitions. - Mark all output values containing secrets as `sensitive = true`. ## Change Workflow - Always run `plan` before `apply`. Review the plan diff carefully — never auto-approve production applies. - Use a CI pipeline for `plan` on PRs; require approval before `apply` on protected branches. - For destructive changes (resource deletion/replacement), require explicit confirmation and a change request. - Use `target` flag sparingly and only for emergency hotfixes — it can leave state inconsistent. ## Security - Enforce least privilege on IAM roles and policies created by IaC. - Enable encryption at rest and in transit for all storage and database resources. - Block public access on S3 buckets unless explicitly required. Document and justify any public resource. - Use security group rules with minimal CIDR ranges — avoid `0.0.0.0/0` ingress except for public-facing load balancers. ## Testing - Use `terraform validate` and `tflint` in CI for every PR. - Run `checkov` or `tfsec` for security policy checks in CI. - Write integration tests for modules using Terratest or equivalent. - Maintain a `test/` environment that applies the full stack — run nightly to catch drift. ## Anti-Patterns - Do not use `count` to manage fundamentally different resources — use `for_each` with meaningful keys. - Do not use `terraform taint` to force replacement — prefer updating the resource configuration. - Do not store provider credentials in the IaC config — use environment variables or instance profiles. - Do not bypass plan review with `--auto-approve` in production pipelines.

CLI

npx mindaxis apply infrastructure-as-code-rules --target cursor --scope project

Используется в паках

AWS Serverless

Full AWS serverless stack with Lambda, DynamoDB, and Cognito

Открыть пак →

Multi-Cloud Deployment

Deploy anywhere — AWS, Azure, GCP, and beyond

Открыть пак →

← Правила

Infrastructure as Code (IaC) Rules

infrastructureterraformdevops

Conventions for writing maintainable, secure, and idempotent infrastructure code with Terraform, Pulumi, or CDK, covering module structure, state management, and change workflows.

Целевые файлы

Файл	Формат
.cursorrules	plaintext
CLAUDE.md	markdown

Содержимое

CLI

npx mindaxis apply infrastructure-as-code-rules --target cursor --scope project

Используется в паках

AWS Serverless

Full AWS serverless stack with Lambda, DynamoDB, and Cognito

Открыть пак →

Multi-Cloud Deployment

Deploy anywhere — AWS, Azure, GCP, and beyond

Открыть пак →