Terraform macht Infrastruktur wiederholbar. Genau das ist die Gefahr: eine Fehlkonfiguration wird nicht einmal falsch, sondern bei jedem Apply erneut ausgerollt, über alle Umgebungen hinweg. Ein offener Bucket im Modul ist dann kein Einzelfehler mehr, sondern ein Muster. Ich sehe in Reviews immer wieder dieselben Handvoll Probleme. Die meisten kosten zwei Zeilen, um sie zu schließen.

Offene Security Groups mit 0.0.0.0/0

Der Klassiker. Ein Ingress-Regelblock, der SSH oder RDP für die ganze Welt öffnet, weil es beim Debuggen kurz praktisch war. Danach bleibt es stehen. Der Punkt ist nicht, dass 0.0.0.0/0 nie vorkommen darf, sondern dass es bewusst und eng passieren muss: ein Load Balancer auf Port 443 ja, der Management-Port nein.

# Fehlerhaft: SSH offen fuer die Welt
resource "aws_security_group_rule" "ssh" {
  type        = "ingress"
  from_port   = 22
  to_port     = 22
  protocol    = "tcp"
  cidr_blocks = ["0.0.0.0/0"]
}
# Besser: nur aus dem eigenen Netz oder ueber SSM
resource "aws_security_group_rule" "ssh" {
  type        = "ingress"
  from_port   = 22
  to_port     = 22
  protocol    = "tcp"
  cidr_blocks = [var.admin_cidr]
}

Verschluesselung nicht als Default

Viele Ressourcen sind unverschluesselt, solange man es nicht explizit setzt. S3-Buckets, EBS-Volumes, RDS-Instanzen, SNS-Topics. Der Fehler ist selten Absicht, sondern das Fehlen einer Zeile. Wer das pro Ressource nachtraegt, vergisst irgendwann eine. Sinnvoller ist ein Default auf Account-Ebene, etwa EBS-Encryption by default, plus ein Scanner, der die Ausnahmen findet.

resource "aws_s3_bucket" "data" {
  bucket = "mh-app-data"
}
resource "aws_s3_bucket_server_side_encryption_configuration" "data" {
  bucket = aws_s3_bucket.data.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "aws:kms"
    }
  }
}

Secrets im Klartext und im State

Ein Passwort direkt in der .tf-Datei landet im Git und in jedem Klon. Aber selbst wenn das Secret ueber eine Variable kommt, schreibt Terraform es im Klartext in den State. Wer den State ungeschuetzt in einem Bucket ablegt, hat die Secrets damit dort liegen. Zwei Konsequenzen: Secrets ueber eine dafuer gebaute Quelle beziehen, und den State verschluesselt und mit Zugriffskontrolle speichern. Zum State-Thema hatte ich hier schon einmal geschrieben, deshalb hier nur die kurze Version.

# Nicht so
variable "db_password" {
  default = "SuperGeheim123"
}
# Sondern aus einem Secret-Store, ohne Default im Code
data "aws_secretsmanager_secret_version" "db" {
  secret_id = "prod/db/password"
}

Zu weite IAM-Policies

Action „*“ auf Resource „*“ ist schnell geschrieben und laeuft garantiert. Es ist auch der Grund, warum aus einem kompromittierten Service sofort ein kompromittierter Account wird. Least Privilege ist muehsam, aber es ist der Unterschied zwischen einem begrenzten und einem totalen Schaden. Wer nicht sofort die perfekte Policy findet, engt wenigstens die Ressource ein statt die Action offen zu lassen.

Nicht hoffen, sondern scannen

Der wichtigste Punkt: keine dieser Fehlkonfigurationen muss ein Mensch im Review finden. Statische Scanner fuer IaC kennen die Muster und laufen in Sekunden. tfsec, checkov oder Trivy im IaC-Modus finden offene Ports, fehlende Verschluesselung und zu weite Policies zuverlaessig. In die Pipeline gehoert der Scan vor den Apply, nicht danach.

# Trivy scannt das Terraform-Verzeichnis auf Fehlkonfigurationen
trivy config --severity HIGH,CRITICAL .
# Alternativ checkov
checkov -d . --compact

Ein sinnvoller Ablauf: der Scan laeuft im Pull Request, blockt bei HIGH und CRITICAL, und dokumentiert bewusste Ausnahmen mit einer Begruendung im Code statt mit einem stillen Ignore. So bleibt sichtbar, welche Abweichung jemand entschieden hat und welche einfach durchgerutscht ist.

Was ich mitnehme

Die teuren Terraform-Fehler sind selten exotisch. Es sind offene Ports, fehlende Verschluesselung, Secrets am falschen Ort und zu weite Rechte. Alle vier lassen sich automatisiert finden, bevor sie ausgerollt werden. Wer den Scan einmal in die Pipeline haengt, verschiebt die Fehlersuche vom Vorfall nach hinten in den Pull Request, wo sie zwei Minuten kostet statt eines Wochenendes. Wie sich das in einen sauberen Lieferprozess einfuegt, vertiefe ich gelegentlich auf digital-business.blog.