Publication le 07 avril 2025

Découvrez les dernières innovations en infrastructure as code et cloud avec HashiCorp Vault, Terraform, Pulumi et AWS CDK

Temps de lecture 10 min

Bienvenue dans cette revue hebdomadaire dédiée à l’Infrastructure as Code (IaC) !
Chaque semaine, nous analysons et synthétisons les actualités, tendances et évolutions majeures en matière d’IaC en nous basant sur diverses sources de référence : blogs spécialisés, forums, réseaux sociaux et publications techniques.

Que vous soyez passionné par Terraform, Pulumi, AWS CDK, Kubernetes ou d'autres outils IaC, ce résumé vous offre un condensé des informations essentielles pour rester à jour.

Avertissement : Contenu généré par IA avec MistralIA
Cet article a été généré automatiquement à l'aide d'une intelligence artificielle. Bien que nous nous efforcions d'assurer l'exactitude des informations, des erreurs ou imprécisions peuvent subsister.

Si vous constatez une erreur ou souhaitez signaler un problème, n'hésitez pas à me contacter :
Email : pro@sarquentin.fr
LinkedIn : Quentin Sar

Le résumé de la semaine

HashiCorp Vault peut être utilisé pour protéger les données sensibles dans Amazon Bedrock.
Mark Tinderholt, expert en Terraform, partage son expérience sur les outils d'infrastructure as code (IaC) et les stratégies cloud.
KubeCon + CloudNativeCon Europe 2025 a mis en avant des innovations en observabilité et en IA.
Pulumi permet de gérer les ressources GitHub via des scripts dynamiques en TypeScript.
AWS CDK offre des composants et des commandes essentiels pour une gestion efficace de l'infrastructure cloud.
Les versions de CDK et leurs différences sont expliquées pour une meilleure compréhension des outils disponibles.

Protection des données sensibles dans Amazon Bedrock avec HashiCorp Vault

Utilisation de HashiCorp Vault

HashiCorp Vault est une solution puissante pour protéger les données sensibles. En utilisant le moteur de secrets transit de Vault, vous pouvez chiffrer et protéger les données avant de les envoyer à une base de connaissances Amazon Bedrock. Cela permet de garantir que les informations sensibles, comme les noms des hôtes dans une liste de locations de vacances, ne sont pas divulguées.

Encryptage des données

Le processus d'encryptage des données implique plusieurs étapes. Tout d'abord, un cluster HCP Vault est configuré avec le moteur de secrets transit activé. Ensuite, les noms des hôtes sont encryptés à l'aide d'une clé nommée listings avec l'encryptage convergent activé. Cela garantit que le même nom d'hôte produit toujours le même texte chiffré, permettant ainsi d'analyser les données sans révéler les noms réels.

Configuration de Terraform

La configuration de Terraform pour ce processus inclut la création de ressources telles que hcp_hvn, hcp_vault_cluster, et vault_mount. Ces ressources sont essentielles pour configurer l'environnement Vault et les clés de chiffrement nécessaires.

resource "hcp_hvn" "rental" {
  hvn_id         = var.name
  cloud_provider = "aws"
  region         = var.region
  cidr_block     = var.cidr_block
}

resource "hcp_vault_cluster" "rental" {
  cluster_id      = var.name
  hvn_id          = hcp_hvn.rental.hvn_id
  tier            = "plus_small"
  public_endpoint = true
}

resource "hcp_vault_cluster_admin_token" "rental" {
  cluster_id = hcp_vault_cluster.rental.cluster_id
}

resource "vault_mount" "transit_rental" {
  path                      = var.name
  type                      = "transit"
  description               = "Key ring for rental information"
  default_lease_ttl_seconds = 3600
  max_lease_ttl_seconds     = 86400
}

resource "vault_transit_secret_backend_key" "listings" {
  backend               = vault_mount.transit_rental.path
  name                  = "listings"
  derived               = true
  convergent_encryption = true
  deletion_allowed      = true
}

Script Python pour l'encryptage

Un script Python utilisant la bibliothèque HVAC est utilisé pour encrypter les noms des hôtes dans un fichier CSV. Ce script lit un fichier CSV contenant des locations de vacances, encrypte les noms des hôtes et enregistre les résultats dans un nouveau fichier CSV.

import base64
import json
import logging
import os
import boto3
import hvac
import pandas
from botocore.exceptions import ClientError
from langchain_community.document_loaders import CSVLoader

LISTINGS_FILE = "./data/raw/listings.csv"
ENCRYPTED_LISTINGS_FILE = "./data/listings.csv"
MOUNT_POINT = "rentals"
KEY_NAME = "listings"
CONTEXT = json.dumps({"location": "New York City", "field": "host_name"})

client = hvac.Client(
   url=os.environ["VAULT_ADDR"],
   token=os.environ["VAULT_TOKEN"],
   namespace=os.getenv("VAULT_NAMESPACE"),
)

def encrypt_payload(payload):
   try:
       encrypt_data_response = client.secrets.transit.encrypt_data(
           mount_point=MOUNT_POINT,
           name=KEY_NAME,
           plaintext=base64.b64encode(payload.encode()).decode(),
           context=base64.b64encode(CONTEXT.encode()).decode(),
       )
       ciphertext = encrypt_data_response["data"]["ciphertext"]
       return ciphertext
   except AttributeError:
       return ""

def encrypt_hostnames():
   dataframe = pandas.read_csv(LISTINGS_FILE)
   dataframe["host_name"] = dataframe["host_name"].apply(lambda x: encrypt_payload(x))
   dataframe.to_csv(ENCRYPTED_LISTINGS_FILE, index=False)

encrypt_hostnames()

Téléchargement des données encryptées

Les données encryptées sont ensuite téléchargées dans un bucket S3. Chaque entrée du fichier CSV est convertie en un document texte et téléchargée dans le bucket S3. Cela permet de préparer les données pour l'ingestion dans une base de connaissances Amazon Bedrock.

def create_documents():
   loader = CSVLoader(ENCRYPTED_LISTINGS_FILE)
   data = loader.load()
   return data

def upload_file(body, bucket, object):
   s3_client = boto3.client("s3")
   try:
       s3_client.put_object(Body=body, Bucket=bucket, Key=object)
   except ClientError as e:
       logging.error(e)
       return False
   return True

def main():
   encrypt_hostnames()
   docs = create_documents()
   for i, doc in enumerate(docs):
       upload_file(doc.page_content, S3_BUCKET_NAME, f"listings/{i}")

if __name__ == "__main__":
   main()

Configuration de la base de connaissances Amazon Bedrock

La base de connaissances Amazon Bedrock est configurée pour ingérer les documents à partir du bucket S3. Des politiques de sécurité sont également mises en place pour garantir que seules les entités autorisées peuvent accéder aux collections et aux index contenant les embeddings vectoriels.

resource "aws_opensearchserverless_security_policy" "rentals_encryption" {
  name = var.name
  type = "encryption"
  policy = jsonencode({
    Rules = [
      {
        Resource = ["collection/${var.name}"]
        ResourceType = "collection"
      },
    ],
    AWSOwnedKey = true
  })
}

resource "aws_opensearchserverless_security_policy" "rentals_network" {
  name = var.name
  type = "network"
  policy = jsonencode([
    {
      Rules = [
        {
          Resource = ["collection/${var.name}"]
          ResourceType = "collection"
        },
        {
          Resource = ["collection/${var.name}"]
          ResourceType = "dashboard"
        },
      ],
      AllowFromPublic = true,
    }
  ])
}

Configuration des politiques IAM

Des politiques IAM sont configurées pour permettre à Amazon Bedrock d'accéder au bucket S3, à la collection OpenSearch et au modèle d'embedding. Cela garantit que les données peuvent être ingérées et analysées de manière sécurisée.

resource "aws_iam_policy" "bedrock" {
  name        = "bedrock-${var.name}-s3"
  path        = "/"
  description = "Allow Bedrock Knowledge Base to access S3 bucket with rentals"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = [
          "s3:ListBucket",
        ]
        Effect   = "Allow"
        Resource = aws_s3_bucket.rentals.arn
        Condition = {
          StringEquals = {
            "aws:ResourceAccount" = data.aws_caller_identity.current.account_id
          }
        }
      },
      {
        Action = [
          "s3:GetObject",
        ]
        Effect   = "Allow"
        Resource = "${aws_s3_bucket.rentals.arn}/*"
        Condition = {
          StringEquals = {
            "aws:ResourceAccount" = data.aws_caller_identity.current.account_id
          }
        }
      },
      {
        Action = [
          "aoss:APIAccessAll"
        ]
        Effect   = "Allow"
        Resource = aws_opensearchserverless_collection.rentals.arn
      },
      {
        Action = [
          "bedrock:InvokeModel"
        ]
        Effect   = "Allow"
        Resource = data.aws_bedrock_foundation_model.embedding.model_arn
      }
    ]
  })
}

Mark Tinderholt: Stratégies Cloud et Outils IaC

Expérience et Expertise

Mark Tinderholt est un expert en technologie avec une vaste expérience dans le développement d'applications, l'automatisation et le DevOps. Il travaille actuellement chez Microsoft et contribue directement à la plateforme Azure. Mark partage également son savoir-faire via son canal YouTube, "The Azure Terraformer", et a écrit un livre intitulé "Mastering Terraform".

Préférence pour Terraform

Mark Tinderholt préfère Terraform pour les configurations multi-cloud en raison de sa flexibilité et de sa capacité à gérer des infrastructures complexes. Il compare Terraform à d'autres outils comme Bicep et ARM templates, soulignant les avantages de Terraform en termes de gestion des dépendances et de la réutilisabilité du code.

Podcast sur les Outils IaC

Dans un podcast, Mark Tinderholt discute des outils d'infrastructure as code (IaC) et des stratégies cloud. Il partage ses expériences pratiques et ses conseils pour les équipes de développement qui cherchent à adopter des pratiques DevOps et à automatiser leurs infrastructures.

KubeCon + CloudNativeCon Europe 2025: Keynotes du Premier Jour

Présentation des Keynotes

KubeCon + CloudNativeCon Europe 2025 a commencé avec des keynotes passionnantes. Chris Aniszczyk, CTO de la Cloud Native Computing Foundation, a célébré le dixième anniversaire du cloud computing et a discuté des efforts de formation et de partenariats.

Observabilité et LLMs

Christine Yen, CEO de Honeycomb, a parlé de l'observabilité dans l'ère des modèles de langage (LLMs). Elle a souligné l'importance de l'observabilité pour gérer l'imprévisibilité des LLMs et a proposé des solutions pour intégrer l'observabilité dans les pipelines de développement.

AI et Observabilité

Vijay Samuel, de eBay, a présenté des solutions d'observabilité basées sur l'IA pour gérer les microservices et les logs volumineux. Il a expliqué comment l'IA peut être utilisée pour analyser et expliquer les incidents, améliorant ainsi la qualité du service.

Rust dans le Kernel Linux

Greg Kroah-Hartman, mainteneur du noyau Linux, a discuté de l'intégration de Rust dans le noyau Linux, soulignant les avantages en termes de performance et de sécurité. Il a également partagé des statistiques sur la communauté du noyau Linux et les contributions des entreprises.

Accessibilité et Kubernetes

Rob Koch, de Slalom Build, a parlé de l'utilisation de Kubernetes pour la reconnaissance de la langue des signes, soulignant l'importance de l'accessibilité et de l'inclusion dans les technologies modernes.

Observabilité et Plateformes

Kasper Borg Nissen, de Dash0, a discuté de l'importance de l'observabilité dans les environnements cloud et a proposé des solutions pour intégrer l'observabilité dans les pipelines de développement.

Création d'un Répertoire de Gestion des Ressources GitHub avec Pulumi

Motivation

L'article explique comment utiliser Pulumi pour gérer les ressources GitHub, comme les dépôts, les organisations et les membres. L'auteur, ayant de nombreux dépôts et organisations, cherche à automatiser la gestion des accès et des licences.

Préparation du Projet

La première étape consiste à installer Pulumi et à configurer un projet en TypeScript. L'auteur utilise un template pour initialiser le projet et configure les fournisseurs nécessaires.

pulumi login file:$(pwd)
pulumi new typescript --force
npm install @pulumi/github
pulumi config set github:token <token> --secret
pulumi config set github:owner <owner>

Importation Dynamique des Ressources

Pour gérer dynamiquement les ressources, l'auteur crée un système de registre qui importe automatiquement les ressources en fonction de leur suffixe. Cela permet de gérer des ressources sans avoir à les importer manuellement.

import * as fs from "fs";
import * as path from "path";
import * as pulumi from "@pulumi/pulumi";

export interface RegistryBaseConstructor {
  new (): RegistryBase;
}

export class RegistryBase {
  constructor(suffix: string, directory: string) {
    this.init(suffix, directory)
      .then((ResourceRegistry) => {
        ResourceRegistry.forEach((ResourceClass) => {
          new ResourceClass();
        });
      })
      .catch((error) => {
        pulumi.log.error(`Critical error in init method: ${error}`);
        throw error;
      });
  }

  protected async init(suffix: string, directory: string) {
    const anyResourceRegistry = new Map<string, RegistryBaseConstructor>();
    const classesDir = path.join(directory, "./");
    const files = fs.readdirSync(classesDir);

    await Promise.all(
      files.map(async (file) => {
        if (file.endsWith(".ts") && file !== "index.ts") {
          const className = file.replace(".ts", "") + suffix;
          const modulePath = path.join(classesDir, file);

          try {
            const module = await import(modulePath);
            const Class = module[className];
            if (Class) {
              anyResourceRegistry.set(className, Class);
            }
          } catch (error) {
            console.error(`Failed to register ${className} class:`, error);
          }
        }
      }),
    );

    return anyResourceRegistry;
  }
}

Collecte des Données

Les données des ressources GitHub sont collectées via l'API GitHub et utilisées pour générer des fichiers de configuration Pulumi. Cela permet de garantir que les ressources sont à jour et conformes à leur état actuel.

export GITHUB_ACCESS_TOKEN=github_pat_...
export GITHUB_USER=...
make import-my-repos

Importation des Ressources

Les ressources sont importées dans Pulumi en utilisant des commandes spécifiques. Cela permet de synchroniser les ressources GitHub avec les configurations Pulumi.

pulumi import github:index/repository:Repository <resource_name> <repository>

AWS CDK en Pratique: Composants, Commandes et Versions

Composants de Base d'AWS CDK

AWS CDK est structuré autour de trois composants principaux: App, Stack et Construct. Ces composants permettent de définir et de gérer les infrastructures cloud de manière efficace.

App

L'App est le conteneur de niveau supérieur dans un projet CDK. Elle sert de point d'entrée pour définir les stacks et leurs dépendances.

const app = new cdk.App();

const stack1 = new Stack1(app, 'Stack1', {
  env: {
    account: process.env.CDK_DEFAULT_ACCOUNT,
    region: process.env.CDK_DEFAULT_REGION,
  }
});

const stack2 = new Stack2(app, 'Stack2', {
  env: {
    account: process.env.CDK_DEFAULT_ACCOUNT,
    region: "ap-northeast-1",
  }
});
stack2.addDependency(stack1);

const stack3 = new Stack2(app, 'Stack3', {
  env: {
    account: process.env.CDK_DEFAULT_ACCOUNT,
    region: "us-east-1",
  }
});
stack3.addDependency(stack1);

Stack

Une Stack correspond à un stack CloudFormation et contient les ressources à déployer ensemble. Chaque stack CDK devient un stack CloudFormation distinct dans le compte AWS.

export class Stack1 extends cdk.Stack {
  constructor(scope: Construct, id: string, props: Stack1Props) {
    super(scope, id, props);

    // Stack resources are defined here
    // ...
  }
}

Construct

Les Constructs sont des abstractions qui définissent les ressources AWS dans une Stack. Ils offrent trois niveaux d'abstraction: L1, L2 et L3.

const bucket = new s3.Bucket(this, "MyBucket", {
  versioned: true,
});

Commandes Essentielles

Les commandes CDK essentielles incluent cdk init, cdk bootstrap, cdk deploy, cdk diff, cdk synth et cdk destroy. Ces commandes permettent de gérer le cycle de vie des projets CDK.

cdk init app --language typescript
cdk bootstrap
cdk deploy --all
cdk diff --all
cdk synth
cdk destroy --all

Versions de CDK

CDK v2 a introduit des améliorations significatives par rapport à v1, notamment la consolidation des bibliothèques de constructs dans un seul package. La séparation récente de la CLI CDK et des bibliothèques de constructs permet une gestion plus flexible des dépendances.

// Avant la séparation
"devDependencies": {
  "aws-cdk": "2.174.0"
},
"dependencies": {
  "aws-cdk-lib": "2.174.0"
}

// Après la séparation
"devDependencies": {
  "aws-cdk": "2.1000.0"
},
"dependencies": {
  "aws-cdk-lib": "2.180.0"
}