Het ontwikkelen van een Terraform drift detectie en herstelplan voor jouw AWS-omgeving is essentieel om de consistentie en betrouwbaarheid van je infrastructuur te waarborgen. Hieronder vind je een stapsgewijze aanpak inclusief tools, scripts en best practices: 1. Drift Detectie: a. Gebruik Terraform's eigen functionaliteit: - `terraform plan`: Voer regelmatig een plan uit om te zien of er afwijkingen zijn tussen de gewenste staat (state-file) en de werkelijke infrastructuur. - `terraform refresh`: Hiermee wordt de state bijgewerkt met de actuele status van de resources, hoewel het gebruik hiervan wordt aanbevolen binnen een gecontroleerde CI/CD-pipeline. b. Automatisering met tools: - Terraform Cloud of Terraform Enterprise biedt ingebouwde driftdetectie en rapportages. - Open-source tools zoals [Terraform-Compliance](https://github.com/terraform-compliance/terraform-compliance) kunnen compliance en drift controleren. c. Gebruik AWS Config: - Configureer AWS Config om resources te monitoren op wijzigingen en afwijkingen ten opzichte van je gedefinieerde regels. - AWS Config kan afwijkingen detecteren en rapporteren, en integreren met SNS of Lambda voor automatische acties. 2. Geautomatiseerde Detectie Scripts: - Scriptvoorbeeld in Bash of Python: - Gebruik `terraform show -json` en vergelijk deze output met de actuele AWS resources via AWS CLI. - Bijvoorbeeld, een script dat: 1. `terraform plan -detailed-exitcode` uitvoert; een exitcode van 2 betekent dat er drift is. 2. AWS CLI commands gebruikt om resource eigenschappen te controleren. - Voor meer geavanceerde detectie kun je tools zoals [Terraformer](https://github.com/GoogleCloudPlatform/terraformer) inzetten om een volledige state-extractie en vergelijking te doen. 3. Best Practices voor Herstel: a. Automatisering: - Integreer `terraform apply` in je CI/CD pipeline om afwijkingen automatisch te corrigeren. - Gebruik ‘terraform taint’ en ‘terraform destroy’ indien nodig om gefaalde of afwijkende resources te herstellen. b. Version control: - Houd je Terraform-configuraties en state-bestanden onder versiebeheer. - Gebruik remote state met locking (bijvoorbeeld S3 met DynamoDB Locking) om concurrentie te voorkomen. c. Regelmatige audits: - Plan periodieke audits met `terraform plan` en AWS Config rapportages. d. Rollback procedures: - Documenteer herstelprocedures, zoals het opnieuw toepassen van configuraties, of het herstellen van backups van DynamoDB. e. Toegangsbeheer: - Beperk IAM-permissies om ongewenste wijzigingen te voorkomen. 4. Multi-Region Overwegingen: - Gebruik geautomatiseerde scripts om resources per regio te controleren. - Overweeg het gebruik van meerdere state-bestanden per regio en centraliseer de driftcontrole. 5. Documentatie en Monitoring: - Documenteer je infrastructuur en driftdetectieprocedures. - Gebruik CloudWatch en SNS voor notificaties bij afwijkingen. Door deze aanpak te volgen, kun je effectief drift detecteren en snel herstellen, waardoor je infrastructuur consistent en betrouwbaar blijft.

Zeker, hier is een gedetailleerd plan voor Terraform drift detectie en herstel voor uw AWS-omgeving. ### **1. Drift Identificatie: Hoe Stel Je Het Vast?** Drift treedt op wanneer de werkelijke staat van uw AWS-resources (EC2, Lambda, DynamoDB) afwijkt van de gewenste staat zoals gedefinieerd in uw Terraform-configuratie en vastgelegd in de state file. **Primaire Methode: Terraform's Eigen Commando's** * `terraform plan`: Dit is uw eerste verdedigingslinie. Wanneer u dit commando uitvoert, vergelijkt Terraform de state file met: 1. Uw actuele Terraform-configuratie (`.tf` bestanden). 2. De *daadwerkelijke* resources in AWS via de API. Een niet-lege output betekent dat er drift is. Let op de `~` (wijziging op plaats) en `-/+` (vervanging) symbolen. * `terraform refresh`: Dit commando werkt de state file bij om de werkelijke eigenschappen van resources te reflecteren. Het wijzigt *niets* in AWS. Het is nuttig om de state file "schoon" te maken voordat u een `plan` uitvoert, maar wees voorzichtig: het kan drift maskeren door de state aan te passen aan de realiteit in plaats van andersom. **Gedetailleerde Analyse per Resource-Type:** * **EC2 Instances**: Drift komt vaak voor bij zaken als: * Wijzigingen in Security Groups (handmatig toegevoegd/verwijderd). * Gewijzigde instance type (bijv. van `t3.micro` naar `t3.small`). * Gewijzigde tags (bijv. `Name`-tag die handmatig is aangepast). * Attachment/Detachment van EBS-volumes. * **Lambda Functions**: Drift is hier subtieler maar kritiek: * De function code (`zip`-file) is buiten Terraform om geüpload (bijv. via AWS Console of CI/CD). * Wijzigingen in Environment Variables, Memory, Timeout. * Toegevoegde/verwijderde triggers (bijv. een EventBridge rule). * **DynamoDB Tables**: * Wijzigingen in de read/write capacity (zelfs als deze op auto-scaling staan). * Toegevoegde/verwijderde globale secundaire indexen (GSI's). * Wijzigingen in tags. --- ### **2. Tools en Scripts voor Geautomatiseerde Detectie** Handmatig `terraform plan` draaien is niet schaalbaar. Automatisering is essentieel. **1. Terraform Cloud/Enterprise (Aanbevolen)** Dit is de meest robuuste oplossing. Het biedt ingebouwde **Drift Detection**. U configureert een workspace en stelt een schema in (bijv. dagelijks). Terraform voert automatisch een `refresh` en `plan` uit en waarschuwt u via e-mail, Slack, etc., als drift wordt gedetecteerd. **2. Open-Source Alternatieven en Scripts** Als u zelf iets wilt bouwen: * **Script met AWS CLI & jq**: U kunt een script schrijven dat de werkelijke configuratie van resources uitleest en vergelijkt met de verwachte waarden uit een bron (bijv. een geëxporteerde state file). Dit is complex en foutgevoelig. * **`terraform plan` output parseren**: Maak een script dat periodiek (bijv. via cronjob of CI/CD pipeline zoals GitHub Actions of GitLab CI) `terraform plan -no-color -json > plan.json` uitvoert. * De `-json` flag geeft een machine-leesbare output. * Het script parseert de `plan.json` en zoekt naar wijzigingen die niet `no-op` zijn. * Bij detectie kan het een melding sturen naar een Slack-kanaal of een Jira-ticket aanmaken. *Voorbeeld van een eenvoudig CI/CD-stap:* ```yaml # .github/workflows/drift-check.yml (GitHub Actions) name: 'Terraform Drift Check' on: schedule: - cron: '0 8 * * 1-5' # Elke werkdag om 08:00 UTC workflow_dispatch: # Sta handmatige trigger toe jobs: drift-check: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: hashicorp/setup-terraform@v3 - name: Terraform Init run: terraform init - name: Terraform Plan for Drift id: plan run: terraform plan -no-color -input=false continue-on-error: true # Plan faalt als er wijzigingen zijn, maar we willen het resultaat verwerken - name: Notify Slack on Drift if: failure() && steps.plan.outcome == 'failure' uses: slackapi/slack-github-action@v2 with: channel-id: 'C12345678' slack-message: "⚠️ Terraform Drift Gedetecteerd! \n ${{ steps.plan.outputs.stdout }}" env: SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }} ``` **3. AWS Native Tools (Beperkt)** * **AWS Config**: Kan configuratiewijzigingen van resources registreren. Het is goed voor auditing en het begrijpen *wat* er is veranderd, maar het linkt deze wijzigingen niet direct terug naar uw Terraform state. Het is een complementaire tool, geen directe vervanging. --- ### **3. Best Practices voor Herstelwerkstromen** Het doel is om Terraform opnieuw de "single source of truth" te laten zijn. **Standaard Herstelprocedure:** 1. **Analyseer**: Begrijp *wat* er is veranderd en *waarom*. Was het een noodfix? Een per ongeluk uitgevoerde handmatige actie? Dit bepaalt de volgende stap. 2. **Importeer (Indien Nodig)**: Als de wijziging gewenst is en u wilt dat Terraform deze resource permanent beheert, gebruik dan `terraform import` om de bestaande resource in uw state op te nemen. **Pas daarna uw `.tf` configuratie aan** om de nieuwe staat te reflecteren. 3. **Terraform Apply**: Voer `terraform apply` uit om de infrastructuur terug te brengen naar de gewenste staat zoals gedefinieerd in uw code. Terraform zal de benodigde wijzigingen voorstellen (meestal een `update` of `replace`). **Belangrijke Workflow Overwegingen:** * **Wijs Eigenaarschap Aan**: Zorg dat elk project/module een duidelijke eigenaar heeft die verantwoordelijk is voor het reageren op drift-meldingen. * **Gebruik een GitOps-flow**: * Alle correcties voor drift moeten via een **Pull Request (PR)** lopen. * De PR moet de `terraform plan` output tonen die laat zien wat wordt hersteld. * Dit zorgt voor transparantie, review en auditing. * **Voorkomen is Beter dan Genezen**: * **Principle of Least Privilege**: Beperk IAM-rechten sterk. Ontneem ontwikkelaars/teams de rechten om resources handmatig te wijzigen via de AWS Console of CLI. Alleen de CI/CD-service (bijv. GitHub Actions runner) zou `terraform apply` moeten kunnen uitvoeren. * **Duidelijke Documentatie**: Zorg dat iedereen weet dat alle infrastructuurwijzigingen via code (Terraform) moeten lopen. * **State Locking**: Zorg dat u state locking (bijv. met een DynamoDB-table) inschakelt om gelijktijdige `apply`-opdrachten te voorkomen die state corruptie kunnen veroorzaken. **Conclusie:** Uw ideale setup is een geautomatiseerd detectiesysteem (zoals Terraform Cloud of een CI/CD job) dat meldingen stuurt naar een centraal kanaal. Een toegewezen engineer analyseert de drift, opent een PR om deze te herstellen (of de configuratie aan te passen) en merge deze na review. Dit proces houdt uw multi-regio AWS-omgeving consistent, veilig en volledig als code gedefinieerd.