Étendre notre API pour un meilleur provisionnement Terraform
Récemment, un client nous a contactés pour nous faire part de son souhait de provisionner Transloadit avec l’outil de Hashicorp, Terraform. Nous proposons déjà le plugin de fournisseur Terraform, qui s’appuie sur notre API pour configurer un compte et des Templates. Cependant, comme ce client l’a souligné, une fonctionnalité essentielle manquait. Les informations d’identification de Template devaient encore être créées et gérées via l’interface de la console.
C’était la seule façon de procéder… jusqu’à aujourd’hui ! Nous avons ajouté un nouveau point de terminaison qui vous permet de gérer vos informations d’identification tierces sans passer par notre site web pour le faire à l’ancienne, en pointant et en cliquant.
Si vous voulez déjà aller plus loin, voici la documentation du point de terminaison d’API des informations d’identification de Template.

Pourquoi est-ce nécessaire ?
Le responsable de l’ingénierie chez Tastemade, Bryan McLemore, nous a signalé ce cas d’usage, en expliquant que notre API de l’époque exposait les secrets d’API à plus de personnes que nécessaire.
Deux options s’offraient à son équipe :

Nous pourrions renoncer à nos principes d’automatisation et créer manuellement les clés IAM, qui doivent ensuite être copiées à la main dans la console Transloadit. Ce processus augmenterait à lui seul le nombre de personnes ayant besoin d’accéder au secret, tout en obligeant davantage de personnes à le voir. Aucune de ces deux conséquences n’est souhaitable.
Autrement, nous injectons les secrets dans les Templates au moment où ils sont générés dans Terraform. Cela préserve l’automatisation, mais toute personne pouvant voir la définition du Template peut alors aussi voir les secrets, puisqu’ils sont stockés en texte clair. Elle devrait faire un effort particulier pour les voir, mais cela reste possible.
Aucune de ces options n’est idéale. Nous avons donc décidé de tenir compte des retours de Bryan et
d’introduire le point de terminaison d’API /template_credentials pour éviter cet échange de secrets délicat. Voici
comment il imaginait ce fonctionnement :
Ma pratique habituelle consiste à faire générer les clés IAM (et autres secrets) par Terraform, puis à les stocker directement là où elles sont nécessaires. Par exemple, dans nos variables de CI et, dans ce cas, dans nos nouveaux Templates Transloadit. Pour limiter les risques liés à la génération de clés IAM dans Terraform, l’état Terraform est conservé dans un emplacement distant et sécurisé, dont l’accès exige des autorisations spéciales.
Une fois ce point de terminaison introduit, n’importe quel client pouvait envoyer des requêtes HTTP à notre API pour provisionner automatiquement des informations d’identification. Cependant, pour répondre au cas d’usage de Bryan, nous avons également demandé au mainteneur principal Etienne Carriere d’ajouter la prise en charge de ce point de terminaison au plugin de fournisseur Terraform pour Transloadit.
Dans Terraform, vous définissez localement dans Git la configuration Transloadit souhaitée. Vous la faites évoluer avec votre équipe et vous pouvez revenir en arrière, comme avec le code de votre application. Lorsque vous exécutez Terraform, il vous présente les différences entre la configuration Transloadit réelle et celle souhaitée, puis propose d’effectuer toutes les modifications nécessaires pour que votre configuration Transloadit réelle corresponde à la configuration voulue.
Cela vous protège contre la dérive due aux erreurs humaines, la perte de données chez Transloadit et d’autres problèmes qui affectent les opérations informatiques modernes. Ce n’est pas sans rappeler l’époque où nous sommes collectivement passés de la gestion de sites web directement sur le disque du serveur via FTP à l’utilisation de Git et de la CI/CD.
Provisionner avec Terraform
Maintenant que nous savons pourquoi nous pourrions vouloir utiliser Terraform avec Transloadit, examinons l’exemple ci-dessous pour voir comment mettre en place une infrastructure de base.
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"
}
}
}
}
Dans notre exemple de code, nous définissons deux fournisseurs : Transloadit et AWS. À partir de là,
nous créons deux ressources, aws_iam_user et aws_iam_access_key. Elles représentent notre utilisateur IAM AWS,
grâce auquel nous pouvons ensuite accéder à notre clé et à notre secret S3. La clé est partagée dans
la ressource transloadit_template_credential, à laquelle nous transmettons ensuite le nom de notre
ensemble d’informations d’identification de Template, le type
d’informations d’identification (S3 ici, mais de nombreux autres
services tiers avec lesquels nous nous intégrons sont pris en charge),
ainsi que la clé et le secret réels issus de l’utilisateur IAM AWS.
Le principal avantage de ce modèle est qu’il vous permet de l’intégrer à une solution de stockage chiffré, comme Hashicorp Vault, ce qui assure un stockage sécurisé de notre état Terraform, puisque nos clés IAM y seraient stockées en texte clair par défaut.
Ensuite, nous pouvons spécifier une ressource pour définir le Template que nous voulons exécuter, et c’est parti.
Vous pouvez en savoir plus sur les paramètres dans la documentation de notre plugin Terraform. Et si vous cherchez les paramètres propres à chaque plateforme pour vos informations d’identification, consultez la documentation de l’un de nos nombreux Robots d’importation de fichiers et d’exportation de fichiers.
Maintenant, pour vérifier que tout fonctionne comme prévu cette première fois, vous pouvez consulter votre Transloadit Console : vous devriez y voir vos nouvelles informations d’identification S3, prêtes pour l’intégration.

Le pouvoir de faire évoluer Transloadit est entre vos mains
Tout cela est passé d’une modeste demande de fonctionnalité à une partie intégrante de notre API en moins d’un mois. Nous sommes très fiers d’avoir conservé l’agilité de nos débuts, il y a 17 ans. De plus, nous sommes ravis que cela nous ait permis de montrer l’influence durable de nos clients sur l’avenir de Transloadit. Alors, si nous pouvons améliorer votre flux de travail actuel d’une manière ou d’une autre, nous espérons que cet exemple vous montre que vous ne devez pas hésiter à nous contacter pour nous en faire part. Des demandes de fonctionnalités en apparence simples comme celle-ci peuvent avoir un effet durable sur Transloadit.
Si vous souhaitez porter quelque chose à notre attention, ouvrez une issue GitHub sur l’un de nos SDK ou contactez le support.
