Connecter le réseau à ses utilisateurs

Introduction

Une application peut disposer d'une instance en cours d'exécution et d'une adresse publique tout en restant inaccessible. Vous allez définir la route manquante et une règle de groupe de sécurité à portée restreinte avec Terraform, puis tester les connexions autorisées et bloquées.

Vous devez connaître les références de ressources Terraform, les VPC, les sous-réseaux, les routes Internet et les groupes de sécurité. Cet environnement indépendant fournit une application cible, une application de référence opérationnelle distincte et des valeurs d'entrée Terraform préparées. Vous gérerez uniquement les nouvelles ressources de connexion.

Liens avec les certifications

Aperçu du lab

Créer la route Internet

Dans cette étape, vous allez attacher une passerelle Internet au VPC de l'application et associer explicitement une table de routage à son sous-réseau.

Ouvrez Terminal et AWS View. Les réseaux de l'application et de référence sont indépendants. application-server possède déjà une adresse publique, car son sous-réseau attribue des adresses IP publiques au lancement. Une adresse publique ne crée à elle seule ni route Internet ni autorisation entrante.

Dans AWS View, sélectionnez application-server, User · 198.51.100.10 et Application · 8081, puis cliquez sur Send request. Le résultat attendu est Blocked. Sélectionnez reference-server avec le même client et le même port d'application, envoyez une autre requête et confirmez que l'application de référence répond. Gardez cette application de référence opérationnelle pendant tout le lab.

Entrez dans le répertoire de travail préparé :

cd /home/labex/project/application-access

Le fichier terraform.tfvars.json fourni contient les identifiants du VPC, du sous-réseau et du groupe de sécurité de cet environnement neuf. Terraform charge automatiquement ces valeurs d'entrée. Lisez-les avant d'utiliser les variables correspondantes :

cat terraform.tfvars.json

La configuration préparée du fournisseur sélectionne l'environnement du cours. Vous n'avez pas besoin de copier des identifiants d'une VM précédente ni de saisir des identifiants personnels. Enregistrez et affichez l'identifiant de l'instance cible fournie pour l'inspecter plus tard. $(...) capture la sortie d'une commande et --output text renvoie l'identifiant en texte brut.

TARGET_ID=$(aws ec2 \
  describe-instances \
  --filters Name=tag:Name,Values=application-server Name=instance-state-name,Values=running \
  --query 'Reservations[0].Instances[0].InstanceId' \
  --output text)
echo "$TARGET_ID"

Une passerelle Internet s'attache à un VPC. Une table de routage envoie le trafic d'une destination vers sa passerelle, et une association de sous-réseau choisit la table qui régit ce sous-réseau. Sans association explicite, un sous-réseau utilise la table de routage principale de son VPC. Laissez cette table principale fournie inchangée. La destination 0.0.0.0/0 correspond aux adresses IPv4 pour lesquelles aucune route plus précise n'existe ; elle n'accorde pas d'autorisation à travers un groupe de sécurité.

Créez routing.tf. Le heredoc avec délimiteur entre guillemets écrit le HCL littéralement. Les références de ressources relient la route à sa table et à sa passerelle, et l'association de sous-réseau à la même table.

cat > routing.tf <<'HCL'
resource "aws_internet_gateway" "application" {
  vpc_id = var.vpc_id
}

resource "aws_route_table" "application" {
  vpc_id = var.vpc_id
}

resource "aws_route" "internet" {
  route_table_id         = aws_route_table.application.id
  destination_cidr_block = "0.0.0.0/0"
  gateway_id             = aws_internet_gateway.application.id
}

resource "aws_route_table_association" "application" {
  subnet_id      = var.subnet_id
  route_table_id = aws_route_table.application.id
}

output "route_table_id" {
  value = aws_route_table.application.id
}

output "subnet_id" {
  value = var.subnet_id
}
HCL

Initialisez, formatez et validez la configuration :

terraform init
terraform fmt
terraform validate

Si init affiche Incomplete lock file information for providers, ce message concerne les sommes de contrôle pour d'autres plateformes. Cette VM préparée utilise linux_amd64 ; poursuivez une fois l'initialisation et la validation réussies.

Examinez les quatre ajouts : la passerelle, la table, la route et l'association. L'instance fournie et le réseau de référence ne doivent pas apparaître comme des ressources à remplacer ou à supprimer.

terraform plan

Appliquez et saisissez yes à la demande de confirmation :

terraform apply

Enregistrez et affichez le nouvel identifiant de table et l'identifiant du sous-réseau fourni :

TABLE_ID=$(terraform output -raw route_table_id)
echo "$TABLE_ID"
SUBNET_ID=$(terraform output -raw subnet_id)
echo "$SUBNET_ID"

Interrogez la table de routage indépendamment. Repérez la destination par défaut, la passerelle igw-... et l'association avec l'identifiant de votre sous-réseau. La route locale du VPC est également conservée.

aws ec2 \
  describe-route-tables \
  --route-table-ids "$TABLE_ID" \
  --query 'RouteTables[].{Routes:Routes[].{Destination:DestinationCidrBlock,Gateway:GatewayId},Subnets:Associations[].SubnetId}'

Confirmez l'attribution d'adresses publiques sur le sous-réseau fourni :

aws ec2 \
  describe-subnets \
  --subnet-ids "$SUBNET_ID" \
  --query 'Subnets[].{CIDR:CidrBlock,PublicIPOnLaunch:MapPublicIpOnLaunch}'

PublicIPOnLaunch vaut true. Ce paramètre contrôle les instances nouvellement lancées ; le modifier ne permet pas d'attribuer rétroactivement une adresse à une instance existante. AWS View affiche désormais la passerelle réelle et la table de routage effective. Envoyez à nouveau la requête User/8081 de l'application : elle reste Blocked, car aucune règle entrante ne l'autorise encore.

Autoriser le client prévu et tester la limite d'accès

Dans cette étape, vous allez permettre au client User d'atteindre le port de l'application et vérifier qu'un autre client et un autre port restent bloqués.

Un groupe de sécurité constitue une frontière réseau avec suivi d'état, attachée à l'interface réseau d'une instance. Le routage rend un chemin disponible ; le groupe décide toujours quelles connexions entrantes sont autorisées. Le groupe fourni pour l'application ne possède actuellement aucune règle entrante.

Créez une ressource de règle entrante indépendante pour ce groupe. cidr_ipv4 = "198.51.100.10/32" sélectionne l'unique adresse IPv4 du client User. Définir les deux ports à 8081 autorise uniquement le service à l'écoute de l'application. L'application de référence utilise son propre groupe de sécurité.

cat > access.tf <<'HCL'
resource "aws_vpc_security_group_ingress_rule" "application" {
  security_group_id = var.security_group_id
  ip_protocol       = "tcp"
  from_port         = 8081
  to_port           = 8081
  cidr_ipv4         = "198.51.100.10/32"
}

output "security_group_id" {
  value = var.security_group_id
}
HCL

Formatez et validez, puis examinez le plan. Il doit prévoir l'ajout d'une règle entrante et aucun remplacement d'instance.

terraform fmt
terraform validate
terraform plan

Appliquez la règle et confirmez avec yes :

terraform apply

Enregistrez et affichez l'identifiant du groupe existant, puis lisez son autorisation entrante effective :

GROUP_ID=$(terraform output -raw security_group_id)
echo "$GROUP_ID"

aws ec2 \
  describe-security-groups \
  --group-ids "$GROUP_ID" \
  --query 'SecurityGroups[].{Group:GroupId,Ingress:IpPermissions}'

L'autorisation doit décrire le port TCP 8081 depuis 198.51.100.10/32. Confirmez que Terraform a convergé :

terraform plan

Le résultat attendu est No changes. Effectuez maintenant les trois tests dans AWS View, en choisissant application-server à chaque fois :

Sélectionnez User · 198.51.100.10 et Application · 8081. Cliquez sur Send request. Les résultats attendus sont Connected · 200 et le message Application network connected.

Changez la source pour Unrelated · 198.51.100.20, gardez le port 8081 et envoyez une autre requête. Le résultat attendu est Blocked. Revenez à la source User, choisissez SSH · 22 et envoyez une autre requête. Le résultat attendu est Blocked. Une requête applicative réussie n'autorise pas l'accès au service SSH distinct de la machine invitée.

Le résultat identifie la source réelle, l'instance cible et le port. Request service unavailable est une erreur d'environnement, pas la preuve d'un rejet réseau attendu. Évitez d'élargir la règle à 0.0.0.0/0 : cela exposerait le même service applicatif au client sans lien avec l'application.

La documentation des règles entrantes du fournisseur AWS décrit les champs de cette ressource. Votre CLI, la correspondance Terraform et les résultats réels des requêtes doivent être cohérents.

Supprimer les ressources de connexion et préserver les applications

Dans cette étape, vous allez supprimer uniquement les ressources de connexion gérées par Terraform et confirmer que les applications fournies restent intactes.

Ce répertoire de travail possède cinq ressources : une passerelle Internet, une table de routage, une route par défaut, une association de sous-réseau et une règle entrante. Le VPC, le sous-réseau, la table de routage principale, l'instance cible et l'application de référence ont été fournis indépendamment. Ils sont en dehors de cet état et doivent être conservés.

Examinez le plan de destruction :

terraform plan -destroy

Cinq ressources doivent être à détruire. Lancez ensuite la suppression et saisissez yes :

terraform destroy

Confirmez que l'état ne contient aucune adresse de ressource gérée :

terraform state list

La cible fournie doit toujours être en cours d'exécution avec le même identifiant :

aws ec2 \
  describe-instances \
  --instance-ids "$TARGET_ID" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name,Subnet:SubnetId}'

Dans AWS View, envoyez à nouveau la requête User/8081 de la cible. Le résultat doit être Blocked, car vous avez supprimé ses ressources de connexion. Sélectionnez ensuite reference-server, User et le port 8081, puis envoyez une requête. L'application de référence doit toujours renvoyer Connected · 200 et Reference application.

Vos fichiers HCL restent disponibles pour examen. Un plan ordinaire ultérieur proposerait de recréer les ressources supprimées ; conserver cette configuration est normal après terraform destroy.

Résumé

Vous avez utilisé des références Terraform pour attacher une passerelle Internet, définir une route par défaut et associer une table de routage à un sous-réseau d'application. Vous avez ensuite ajouté une règle entrante à portée restreinte, testé les limites réelles de source et de port, confirmé la convergence et supprimé uniquement vos ressources de connexion tout en préservant les applications fournies.