Ich bat KI, meine Terraform zu schreiben. Ein Realitätscheck

In Nimmt mir KI meinen DevOps-Job weg? Ich warnte, dass KI Konfigurationen schreibt, die perfekt aussehen und subtil kaputt sind. Eine Erlaubnis, die viel zu offen ist. Eine Einstellung, die bei Tests funktioniert und unter echtem Verkehr umfällt.

Das ist leicht zu sagen. Dieser Beitrag zeigt, wie es tatsächlich aussieht und wie ich es verhindern kann, dass es in Produktion geht.

Die Anforderung

Hier ist die Art von Anfrage, die ich einem KI-Assistenten an einem normalen Tag geben würde:

"Schreiben Sie Terraform für eine AWS PostgreSQL-Datenbank für eine kleine Web-App, plus eine Sicherheitsgruppe, damit sich die App verbinden kann".

Kurz, realistisch und fehlt viel Kontext. Genau so schreiben die meisten von uns Anweisungen.

Was kam zurück

Die Antwort ist normalerweise ein sauberer, gut formatierter Block Terraform. Es erstellt eine RDS-Instanz, eine Sicherheitsgruppe und einige Variablen. Es funktioniert wahrscheinlich beim ersten Versuch. Aber es umfasst oft mehrere dieser Fragen:

resource "aws_security_group" "db" {
  name = "db-sg"

  ingress {
    from_port   = 5432
    to_port     = 5432
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]   # anyone on the internet
  }
}

resource "aws_db_instance" "main" {
  engine              = "postgres"
  instance_class      = "db.t3.micro"
  allocated_storage   = 20
  username            = "admin"
  password            = "ChangeMe123!"   # hardcoded secret
  publicly_accessible = true
  skip_final_snapshot = true
}

Hier ist nichts ein Syntaxfehler. terraform plan ist glücklich. Und doch:

Die Fehler, eine nach der anderen

1. Die Datenbank ist über das gesamte Internet erreichbar. 0.0.0.0/0 am Hafen 5432 und publicly_accessible = true- Ich weiß . Die App brauchte Zugang, nicht die Welt.
2. Ein festes Passwort Das wird in Git und im Terraform-Zustand enden.
3. Keine Verschlüsselung in Ruhe (storage_encrypted fehlt).
4. Keine Sicherungen. keine Aufbewahrungsfrist festgelegt ist und skip_final_snapshot = true bedeutet, dass das Löschen der Ressource Ihre Daten ohne Schnappschuss löscht.
5. Keine Löschschutz. Ein Fehler. terraform destroy Und es ist weg.
6. Keine Version festgehalten Die Ergebnisse der Prüfung werden in einem anderen Fall als bei der Prüfung der Ergebnisse der Prüfung ermittelt.
7. Keine Markierung, so dass die Kostenverfolgung und Eigentumsansprüche unklar sind.

Um fair zu sein, wenn man die KI fragt: "Ist das sicher?", findet sie normalerweise die meisten dieser Probleme. Aber das ist der Punkt: Sie gab Ihnen zuerst die unsichere Version, und das mit Selbstvertrauen.

KI schreibt Terraform wie ein Tutorial: optimiert, um beim ersten Versuch zu arbeiten, nicht um ein Audit zu überleben.

Was die Linters fangen

Hier verdienen langweilige Werkzeuge ihren Platz. Ich habe diesen Code durchlaufen:

• terraform validate und terraform fmt: Syntax und Formatierung. Notwendig, aber sie erkennen keine der Sicherheitsprobleme oben.
• Schnapp mit dem AWS-Regelsatz: ungültige Instanztypen, veraltete Argumente, fehlende Best Practices.
• - Ich weiß. oder Trivy (Konfigurierungsscannen): Diese fangen die wichtigen auf. Offener Zugang, öffentliche Datenbank, fehlende Verschlüsselung, fehlende Backups, fest verschlüsselte Geheimnisse.
• Geheime Scan (gitleaks, GitHub Push Protection): fängt das Passwort ein, bevor es überhaupt gedrückt wird.

Was sie nicht verstehen, ist, ob das Design den Bedürfnissen Ihrer Firma entspricht. Sollte das stattdessen Aurora sein? - Ich weiß . db.t3.micro Wirkliches Verkehrswesen? Gehört es in dieses VPC? Dafür braucht man einen Menschen, der den Kontext kennt.

Mein Arbeitsprozess: Erstellen, Lint, Test, Überprüfung

1. Generieren Sie mit Kontext. Geben Sie der KI Ihre Konventionen: "Verwenden Sie unser Modul X, niemals öffentlich, immer verschlüsselt, Geheimnisse von AWS Secrets Manager, taggen Sie mit Eigentümer und Kostenzentrum". Eine Regelfilder im Repo hilft hier sehr, so dass Sie es nicht jedes Mal wiederholen müssen.
2. Lint automatisch. Vorverpflichtungshaken für fmt, validieren, tflint und Checkov und die gleichen Kontrollen in CI wie die erforderlichen Statuskontrollen.
3. Plan in CI Und den Plan lesen, nicht nur den Code.
4. Test, wo es wichtig ist: terraform test oder ein politischer Test für die Regeln, die niemals gebrochen werden dürfen.
5. Überprüfung durch Menschen Die Schlüssel für die Erstellung von Modellen sind Design und Absicht, da die Werkzeuge die Muster bereits überprüft haben.

Noch besser: Richten Sie die KI auf Ihre vorhandenen, überprüften Module, anstatt sie Rohressourcen schreiben zu lassen. "Verwenden Sie unsere rds-postgres Modul" erzeugt viel sicherere Ergebnisse als "schreibe mir eine Datenbank".

Sollten Sie KI für Terraform verwenden?

- Ja, das ist es. Es spart Zeit für Boilerplate, wenn man unbekannten Code neu strukturiert und erklärt. Betrachten Sie seine Ausgabe einfach nie als fertig. Sie müssen es durch die gleiche Pipeline bringen, wie Sie es bei der ersten Anfrage eines neuen Kollegen tun würden, denn das ist ungefähr das, was es ist.

Meine Meinung: KI ist ein großartiger Erstausschreiber für Infrastruktur. Ihre Linters, Ihre Richtlinien und Ihre Rezension sind die Redakteure, und in der Infrastruktur ist der Redakteur am wichtigsten.

Desly