Wir erweitern unsere API für bessere Terraform-Provisionierung
Kürzlich kam ein Kunde auf uns zu und äußerte den Wunsch, Transloadit mit Hashicorps Terraform zu provisionieren. Wir bieten bereits das Terraform Provider Plugin (English) an, das unsere API nutzt, um ein Konto und Templates einzurichten. Wie der Kunde jedoch anmerkte, fehlte eine zentrale Funktion. Template-Zugangsdaten mussten weiterhin über die Transloadit Console erstellt und verwaltet werden.
Das war der einzige Weg … bis heute! Wir haben nun einen zusätzlichen Endpunkt hinzugefügt, mit dem Sie Ihre Zugangsdaten von Drittanbietern verwalten können, ohne dafür im guten alten Point-and-Click-Stil auf unsere Website wechseln zu müssen.
Wenn Sie schon vorausschauen möchten, finden Sie hier die Dokumentation zum Endpunkt der Template-Zugangsdaten-API.

Warum ist das notwendig?
Als Head of Engineering bei Tastemade machte uns Bryan McLemore auf diesen Anwendungsfall aufmerksam und beschrieb, wie unsere API damals dazu führte, dass mehr Personen als nötig mit API-Secrets in Berührung kamen.
Ihnen blieben zwei Möglichkeiten:

Wir könnten unsere Prinzipien rund um Automatisierung brechen und die IAM-Schlüssel manuell erstellen, die dann von Hand in die Transloadit Console kopiert werden müssen. Dieser Prozess allein würde die Zahl der Personen erhöhen, die Zugriff auf das Secret benötigen, und zudem mehr Menschen zwingen, es zu sehen. Beides ist nicht gut.
Alternativ injizieren wir die Secrets in die Templates, während sie in Terraform generiert werden. Das erhält die Automatisierung, führt aber dazu, dass jeder, der die Template-Definition sehen kann, auch die Secrets sieht, da sie im Klartext gespeichert sind. Man müsste sich schon Mühe geben, um sie zu sehen, aber möglich ist es trotzdem.
Keine dieser Optionen ist ideal. Stattdessen haben wir Bryans Feedback aufgegriffen und den
API-Endpunkt /template_credentials eingeführt, um diesen umständlichen Austausch von
Secrets zu umgehen. So hat er sich das vorgestellt:
Mein grundsätzliches Muster ist, dass IAM-Schlüssel (und andere Secrets) von Terraform generiert und dann direkt dort gespeichert werden, wo sie benötigt werden. Zum Beispiel in unseren CI-Variablen und in diesem Fall in unseren neuen Transloadit Templates. Um die Risiken beim Generieren von IAM-Schlüsseln in Terraform zu verringern, liegt unser Terraform-State an einem sicheren, entfernten Ort, für den überhaupt erst spezielle Berechtigungen nötig sind.
Nach der Einführung des Endpunkts konnte jeder Kunde HTTP-Aufrufe an unsere API senden, um Zugangsdaten automatisch zu provisionieren. Um Bryans Anwendungsfall zu unterstützen, haben wir jedoch auch den Lead Maintainer Etienne Carriere gebeten, die Unterstützung für diesen Endpunkt im Transloadit Terraform Provider Plugin auszurollen.
In Terraform definieren Sie Ihre gewünschte Transloadit-Konfiguration lokal in Git. Sie entwickeln sie gemeinsam mit Ihrem Team weiter und können sie zurückrollen, genau wie den Code Ihrer App. Wenn Sie Terraform ausführen, zeigt es Ihnen die Unterschiede zwischen der tatsächlichen und der gewünschten Transloadit-Konfiguration und schlägt alle Änderungen vor, die nötig sind, damit Ihre tatsächliche Transloadit-Konfiguration Ihrer gewünschten Konfiguration entspricht.
Das schützt vor Drift durch menschliche Fehler, vor Transloadit-Datenverlust und vor anderen Problemen, die den modernen IT-Betrieb plagen. Es ist ganz ähnlich wie damals, als wir alle davon abrückten, Websites mit FTP direkt auf der Serverfestplatte zu verwalten, und stattdessen zu Git und CI/CD übergingen.
Provisionierung in Terraform
Nachdem wir nun wissen, warum wir Terraform mit Transloadit einsetzen möchten, sehen wir uns unten ein Beispiel an, wie sich eine einfache Infrastruktur umsetzen lässt.
provider "aws" {
region = "us-east-1"
}
provider "transloadit" {}
resource "aws_iam_user" "transloadit" {
name = "transloadit"
}
resource "aws_iam_access_key" "transloadit" {
user = aws_iam_user.transloadit.name
}
resource "transloadit_template_credential" "s3_credentials" {
name = "my-terreaform-credentials"
type = "s3"
content = jsonencode({
bucket = "uploads-bucket"
bucket_region = "us-east-1"
key = aws_iam_access_key.transloadit.id
secret = aws_iam_access_key.transloadit.secret
})
}
resource "transloadit_template" "my-terraform-template" {
name = "my-terraform-template"
template =
{
"steps": {
":original": {
"robot": "/upload/handle"
},
"exported": {
"use": [ ":original" ],
"credentials": "${transloadit_template_credential.s3_credentials.name}",
"robot": "/s3/store"
}
}
}
}
In unserem Beispielcode definieren wir zwei Provider: Transloadit und AWS. Daraus erstellen wir zwei
Ressourcen, aws_iam_user und aws_iam_access_key. Diese stehen für
unseren AWS-IAM-Benutzer, über den wir dann auf unseren S3-Schlüssel und unser Secret zugreifen
können. Der Schlüssel wird unter der Ressource transloadit_template_credential bereitgestellt; an
diese übergeben wir anschließend den Namen unserer Template-Zugangsdaten, den Typ der
Zugangsdaten (in diesem Fall S3, aber viele weitere
Drittanbieter, die wir anbinden, werden unterstützt)
sowie den eigentlichen Schlüssel und das Secret für die Zugangsdaten des AWS-IAM-Benutzers.
Der größte Vorteil dieses Musters ist, dass Sie damit eine verschlüsselte Speicheroption wie Hashicorp Vault einbinden können, was zu einer sicheren Speicherung unseres Terraform-States führt, da unsere IAM-Schlüssel standardmäßig im Klartext gespeichert würden.
Danach können wir eine Ressource angeben, um das Template zu definieren, das wir ausführen möchten – und schon geht es los.
Mehr über die Parameter erfahren Sie in der Dokumentation zu unserem Terraform-Plugin. Und wenn Sie plattformspezifische Parameter für Ihre Zugangsdaten suchen, werfen Sie einen Blick in die Dokumentation zu einem unserer vielen Robots für den Dateiimport und Dateiexport.
Um dieses erste Mal zu bestätigen, dass alles wie erwartet funktioniert, können Sie einen Blick in Ihre Transloadit Console werfen: Dort sollten Sie Ihre neuen S3-Zugangsdaten sehen, bereit für die Integration.

Die Macht, Transloadit zu verändern, liegt in Ihren Händen
All das wurde in weniger als einem Monat aus einem bescheidenen Feature-Request zu einem Teil unserer API. Wir sind sehr stolz darauf, immer noch dieselbe Agilität zu besitzen, mit der wir vor 17 Jahren gestartet sind. Darüber hinaus freut es uns, dass wir damit den anhaltenden Einfluss zeigen konnten, den unsere Kunden auf die Zukunft von Transloadit haben. Wenn es also irgendetwas gibt, womit wir Ihren aktuellen Workflow verbessern könnten – wir hoffen, dies zeigt, dass Sie nicht zögern sollten, sich bei uns zu melden. Scheinbar einfache Feature-Requests wie diese können eine nachhaltige Wirkung auf Transloadit entfalten.
Wenn Sie uns auf etwas aufmerksam machen möchten, hinterlassen Sie ein GitHub-Issue in einem unserer SDKs oder wenden Sie sich an den Support.
