Améliorer la couverture des ressources cloud pour réduire la dérive de l’infrastructure

En tant que développeurs, nous avons besoin d’une visibilité maximale sur ce qui s’exécute réellement dans nos environnements cloud afin de les sécuriser. L’infrastructure as code (IaC) aide les développeurs à automatiser leurs infrastructures cloud, pour que les déploiements dans le cloud soient contrôlés et faciles à auditer. Mais atteindre et maintenir une couverture IaC de 100 % de votre infrastructure présente de nombreux défis.

Notre sécurité dépend uniquement de ce qui est effectivement déployé et exécuté dans nos environnements cloud. Or, bien souvent, nous-mêmes, d’autres équipes ou des services authentifiés effectuons encore régulièrement de nombreuses actions manuelles. Ces modifications échappent à l’IaC et aux audits, et entraînent des problèmes tels que des erreurs de configuration et des risques de sécurité. C’est là que la gestion de la dérive devient importante : nous voulons obtenir des rapports sur les ressources qui ne sont pas encore gérées par l’IaC ou qui ont été modifiées pour une raison quelconque.

Dans cet article, nous allons montrer comment Snyk IaC aide les développeurs à détecter les ressources cloud qui ne sont pas gérées par l’infrastructure as code (IaC) (ressources non gérées), ou qui ont dérivé de leur état attendu (ressources gérées).

Configurer l’environnement

Snyk IaC répertorie les ressources détectées sous forme de ressources Terraform, ce qui vous permet de savoir facilement quelle partie du service cloud est concernée par la détection. Par exemple, un seul service Amazon API Gateway v2 se compose d’au moins 12 ressources Terraform. Grâce aux informations de détection fournies par Snyk, vous pourrez rapidement décider s’il faut annuler la modification, importer une nouvelle ressource ou simplement supprimer ce nouveau changement.

Pour suivre les étapes, vous pouvez utiliser le fichier Terraform ci-dessous afin de créer deux ressources AWS que nous utiliserons dans ce guide. Il crée un utilisateur IAM nommé « user1 » avec un suffixe aléatoire, une clé d’accès et une stratégie associée autorisant un accès en lecture seule.

Au moment de la rédaction de cet article, nous utilisions Terraform v1.1.7 avec le fournisseur AWS v3.74.2

Réutilisez la configuration HCL suivante :

main.tf

1resource "random_string" "prefix" {
2  length  = 6
3  upper   = false
4  special = false
5}
6
7resource "aws_iam_user" "user1" {
8  name = "user1-${random_string.prefix.result}"
9
10  tags = {
11    Name = "user1-${random_string.prefix.result}"
12    manual = "true"
13  }
14}
15
16resource "aws_iam_access_key" "user1" {
17  user = aws_iam_user.user1.name
18}
19
20resource "aws_iam_user_policy_attachment" "user1" {
21  user       = aws_iam_user.user1.name
22  policy_arn = "arn:aws:iam::aws:policy/ReadOnlyAccess"
23}

Appliquez cette configuration Terraform :

1$ terraform init
2[...]
3$ terraform apply
4[...]

Vérifiez que vous avez un fichier terraform.tfstate à la racine du répertoire :

1$ ls -al terraform.tfstate
2-rw-r--r--  1 sjourdan  staff  5049 Mar 16 18:31 terraform.tfstate

Vérifiez également que l’utilisateur IAM a bien été créé sur AWS.

Commencer sur une base vierge

Commençons par répertorier toutes les ressources cloud qui ne sont pas gérées par Terraform :

1$ snyk iac describe --only-unmanaged

Vous obtiendrez probablement une longue liste de ressources qui ne sont pas gérées par Terraform. Ces informations sont déjà très utiles, mais elles ne sont pas vraiment exploitables dans notre cas. Snyk IaC intègre une fonctionnalité permettant d’ignorer des ressources en bloc en ajoutant toutes les ressources détectées au fichier de stratégie .snyk.

Ignorons toutes ces ressources non gérées existantes afin de travailler plus précisément dans un environnement contrôlé, avec uniquement les deux ressources créées précédemment :

1$ snyk iac describe --only-unmanaged --json  | snyk iac update-exclude-policy

Effectuez un nouveau scan pour confirmer que votre environnement ignore désormais les dérives détectées (vous aurez tout le temps plus tard de planifier leur importation). 

1$ snyk iac describe --only-unmanaged
2
3Scanned states (1)
4Found 3 resource(s)
5 - 100% coverage
6Congrats! Your infrastructure is fully in sync.

Nous sommes maintenant prêts à repartir d’un état vierge.

Créons une dérive avec IAM !

Nous allons maintenant créer trois types de dérive pour simuler des situations réelles :

1. Une modification de l’utilisateur IAM existant (que nous voudrons annuler)

2. L’ajout manuel d’une nouvelle stratégie IAM (que nous voudrons supprimer)

3. Un nouvel utilisateur IAM (que nous voudrons améliorer)

Pour cela, accédez à la console AWS pour IAM.

Modifier l’utilisateur IAM existant en lui ajoutant une balise

1. Sur la page des utilisateurs IAM, cliquez sur « user1 »

2. Cliquez sur l’onglet Tags

3. Cliquez sur le bouton Edit Tags

4. Ajoutez une nouvelle clé (« environment ») et une nouvelle valeur (« production »)

5. Cliquez sur Save

Associer une stratégie puissante à l’utilisateur IAM existant

1. Sur la page des utilisateurs IAM, cliquez sur « user1 »

2. Cliquez sur l’onglet Permissions

3. Cliquez sur le bouton Add permissions

4. Cliquez sur Attach existing policies directly

5. Sélectionnez Administrator Access

6. Cliquez sur Next: Review

7. Confirmez en cliquant sur Add permissions

Créer manuellement un autre utilisateur IAM

1. Sur la page des utilisateurs IAM, cliquez sur le bouton Add Users

2. Saisissez « user2 » dans le champ User name:

3. Sélectionnez Access key

4. Cliquez sur le bouton Next: Permissions

5. Ne définissez aucune autorisation ni balise

6. Cliquez sur Create user (les identifiants affichés ne nous intéressent pas, vous pouvez donc les ignorer).

Nous sommes maintenant prêts à traiter ces différents types de modifications manuelles à l’aide de la détection de dérive de Snyk IaC.

Dérive de l’infrastructure gérée et non gérée

Voyons maintenant comment Snyk IaC détecte ces modifications, en commençant par les ressources qui ne sont tout simplement pas gérées par Terraform.

1$ snyk iac describe --only-unmanaged
2
3Scanned states (1)
4Found resources not covered by IaC:
5  aws_iam_access_key:
6    - AKIASBXWQ3AYQETE6OFR
7        User: user2
8  aws_iam_policy_attachment:
9    - user1-84i30k-arn:aws:iam::aws:policy/AdministratorAccess
10  aws_iam_user:
11    - user2
12Found 6 resource(s)
13 - 50% coverage
14 - 3 resource(s) managed by Terraform
15 - 3 resource(s) not managed by Terraform
16 - 0 resource(s) found in a Terraform state but missing on the cloud provider

Ce scan a signalé les éléments suivants, en utilisant la terminologie des ressources Terraform :

• L’utilisateur IAM « user2 » créé manuellement, avec sa clé d’accès IAM

• La stratégie IAM associée manuellement à l’utilisateur IAM « user1 » géré par Terraform.

Vérifions maintenant les modifications apportées uniquement aux ressources gérées par Terraform et présentes dans les différents états Terraform :

1$ snyk iac describe –only-managed
2Scanned states (1)
3Found changed resources:
4  From tfstate://terraform.tfstate
5    - user1-84i30k (aws_iam_user.user1):
6        + tags.environment: <nil> => "production"
7Found 5 resource(s)
8 - 100% coverage
9 - 5 resource(s) managed by Terraform
10     - 1/5 resource(s) out of sync with Terraform state
11 - 0 resource(s) found in a Terraform state but missing on the cloud provider

Ce scan a produit un résultat très différent et a pris beaucoup plus de temps (36 s contre 9 s pour le mode de scan « non géré »).

Ce résultat nous apprend que l’utilisateur IAM nommé « user1-84i30k », que nous trouvons dans le HCL (en tant que ressource) sous le nom « user1 », comporte une balise nommée « environment » dont la valeur est « production ».

Plan d’action

L’outil de détection de dérive de Snyk nous a aidés à découvrir quatre écarts inattendus entre nos attentes et la réalité. Pour les besoins de cet article, supposons que l’équipe décide ce qui suit :

• L’utilisateur IAM « user2 » est utilisé en production et doit être importé dans Terraform.

• La clé d’accès IAM de « user2 » doit être renouvelée pour des raisons de sécurité.

• « user1 » ne doit en aucun cas être administrateur.

• La nouvelle balise de « user1 » répond à un besoin et doit être importée dans Terraform.

Les pipelines de déploiement ne sont pas une solution de remédiation

Nous avons mis en place un excellent pipeline de déploiement Terraform. Au prochain déclenchement de terraform apply, nous pourrions nous attendre à ce que tout revienne à la normale.

Dans ce cas, que fera Terraform ? Une tâche de déploiement :

1$ terraform apply
2Terraform will perform the following actions:
3
4  # aws_iam_user.user1 will be updated in-place
5  ~ resource "aws_iam_user" "user1" {
6        id            = "user1-84i30k"
7        name          = "user1-84i30k"
8      ~ tags          = {
9          - "environment" = "production" -> null
10            # (1 unchanged element hidden)
11        }
12[...]
13
14Plan: 0 to add, 1 to change, 0 to destroy.

Terraform n’a jamais été conçu pour détecter les ressources créées ou associées manuellement. Il rétablira simplement les ressources modifiées à leur état initial (ce que nous ne souhaitons pas dans cette situation).

Dans aucun de ces cas, nous n’obtenons l’aide attendue :

• L’utilisateur IAM créé manuellement et sa clé d’accès ne sont pas signalés (inutile)

• La stratégie Administrator associée manuellement à un utilisateur géré n’est pas signalée (inutile)

• La balise importante ajoutée manuellement à un utilisateur géré sera supprimée (préjudiciable)

Ce type de détection et de travail nécessite un autre type d’outil.

Améliorer notre couverture

Nous commençons avec une couverture de 50 % des ressources non gérées :

1$ snyk iac describe --only-unmanaged
2
3Scanned states (1)
4Found resources not covered by IaC:
5  aws_iam_access_key:
6    - AKIASBXWQ3AYQETE6OFR
7        User: user2
8  aws_iam_policy_attachment:
9    - user1-84i30k-arn:aws:iam::aws:policy/AdministratorAccess
10  aws_iam_user:
11    - user2
12Found 6 resource(s)
13 - 50% coverage
14 - 3 resource(s) managed by Terraform
15 - 3 resource(s) not managed by Terraform
16 - 0 resource(s) found in a Terraform state but missing on the cloud provider

Améliorons-la en suivant le plan de l’équipe.

Supprimer la stratégie IAM de « user1 »

Commençons par l’action la plus urgente et la plus simple : supprimer la stratégie « Administrator » de l’utilisateur IAM géré « user1 » :

• Accédez à IAM > Users > « user1 »

• Cliquez sur Permissions > supprimez « AdministratorAccess »

1$ snyk iac describe --only-unmanaged
2Scanned states (1)
3Found resources not covered by IaC:
4  aws_iam_access_key:
5    - AKIASBXWQ3AYQETE6OFR
6        User: user2
7  aws_iam_user:
8    - user2
9Found 5 resource(s)
10 - 60% coverage
11 - 3 resource(s) managed by Terraform
12 - 2 resource(s) not managed by Terraform

Nous couvrons désormais 60 % de nos ressources AWS, contre 50 % auparavant.

Continuons.

Débloquer le pipeline de déploiement Terraform

Le pipeline est actuellement bloqué par cette modification manuelle des balises de aws_iam_user.user1. Si un déploiement est effectué, les balises reviendront à celles définies dans le HCL. Quelle est donc la solution ? Utiliser le résultat de détection de dérive de Snyk IaC pour adapter notre configuration Terraform.

Voici les informations dont nous disposons :

1Found changed resources:
2  From tfstate://terraform.tfstate
3    - user1-84i30k (aws_iam_user.user1):
4        + tags.environment: <nil> => "production"

Ce résultat nous apprend que :

• Nous recherchons une ressource nommée « user1 » de type aws_iam_user

• Cette ressource se trouve dans terraform.tfstate (très utile lorsque vous avez des dizaines ou des centaines d’états)

• Une nouvelle clé de balise nommée environment a pour valeur « production ».

Mettons à jour la ressource de notre utilisateur IAM en ajoutant simplement environment = "production", afin qu’elle ressemble désormais à ceci :

1resource "aws_iam_user" "user1" {
2 name = "user1-${random_string.prefix.result}"
3
4 tags = {
5   Name = "user1-${random_string.prefix.result}"
6   environment = "production"
7 }
8}

Nous pouvons maintenant débloquer sans risque notre pipeline de déploiement Terraform :

1$ terraform apply
2No changes. Your infrastructure matches the configuration.
3Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Nous avons corrigé nos dérives « gérées » pour le moment :

1$ snyk iac describe --only-managed
2Scanned states (1)
3Found 3 resource(s)
4 - 100% coverage
5Congrats! Your infrastructure is fully in sync.

Importer et renouveler la clé IAM de user2

Occupons-nous maintenant du cas de « user2 ». Nous voulons :

• L’importer dans Terraform

• Renouveler la clé

Commençons par importer l’utilisateur IAM dans Terraform. Voici une méthode simple pour le faire.

Commencez par recueillir les informations fournies par Snyk IaC :

Comment importer une aws_iam_user resource ? Selon la documentation officielle de Terraform : les utilisateurs IAM peuvent être importés à l’aide de leurnom, par exemple : $ terraform import aws_iam_user.lb loadbalancer.

Nous pouvons également lire que le seul argument obligatoire est name. Ajoutons donc cette structure de base à notre fichier HCL :

1resource "aws_iam_user" "user2" {
2 name = "user2" # required
3}

Importons maintenant cet utilisateur dans Terraform :

1$ terraform import aws_iam_user.user2 user2
2aws_iam_user.user2: Importing from ID "user2"...
3aws_iam_user.user2: Import prepared!
4  Prepared aws_iam_user for import
5aws_iam_user.user2: Refreshing state... [id=user2]
6
7Import successful!

Comment notre couverture a-t-elle évolué ? Voyons cela :

1$ snyk iac describe --only-unmanaged
2Scanned states (1)
3Found resources not covered by IaC:
4  aws_iam_access_key:
5    - AKIASBXWQ3AYQETE6OFR
6        User: user2
7Found 5 resource(s)
8 - 80% coverage
9 - 4 resource(s) managed by Terraform
10 - 1 resource(s) not managed by Terraform

Nous atteignons désormais une couverture de 80 % (contre 60 % auparavant) et il ne reste qu’une seule ressource.

Renouveler la clé

Occupons-nous maintenant de cette tâche. Nous voulons renouveler la clé tout en l’ajoutant à Terraform. Commençons par ajouter la nouvelle clé au HCL pour en créer une (afin de pouvoir la transmettre à l’équipe concernée, par exemple), puis supprimons simplement l’ancienne clé d’AWS.

La documentation Terraform pour aws_iam_access_key est très claire : il suffit de créer une ressource en indiquant le nom de user2 comme argument :

1resource "aws_iam_access_key" "user2" {
2 user = aws_iam_user.user2.name
3}

Le pipeline de déploiement ayant été débloqué, nous pouvons appliquer sans risque cette configuration avec Terraform afin de créer une nouvelle clé :

1$ terraform apply 
2[...]
3Terraform will perform the following actions:
4
5  # aws_iam_access_key.user2 will be created
6  + resource "aws_iam_access_key" "user2" {
7      + create_date          = (known after apply)
8      + encrypted_secret     = (known after apply)
9      + id                   = (known after apply)
10      + key_fingerprint      = (known after apply)
11      + secret               = (sensitive value)
12      + ses_smtp_password_v4 = (sensitive value)
13      + status               = "Active"
14      + user                 = "user2"
15    }
16
17Plan: 1 to add, 0 to change, 0 to destroy.
18
19aws_iam_access_key.user2: Creating...
20aws_iam_access_key.user2: Creation complete after 1s [id=AKIASBXWQ3AY4KPUNIHZ]
21
22Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Il nous reste l’ancienne clé à supprimer. D’après les informations du résultat Snyk IaC, le nom de la clé est AKIASBXWQ3AYQETE6OFR.

La méthode la plus simple pour supprimer cette clé consiste à :

• Accéder à IAM > Users > user2 > Security Credentials

• Supprimez la clé nommée AKIASBXWQ3AYQETE6OFR, signalée par Snyk IaC, en la désactivant puis en la supprimant.

À quoi ressemble maintenant notre couverture ?

1$ snyk iac describe --only-unmanaged
2Scanned states (1)
3Found 5 resource(s)
4 - 100% coverage
5Congrats! Your infrastructure is fully in sync.

Félicitations ! Tout est de nouveau sous contrôle grâce à la détection de dérive de Snyk IaC !

Pour conclure

Dans cet article, nous avons montré comment la détection de dérive de Snyk IaC permet de découvrir les ressources AWS créées manuellement et de présenter les résultats selon la terminologie Terraform, avec les informations nécessaires pour aider les développeurs à importer ces ressources dans leur code HCL Terraform. Nous avons également vu brièvement que le rétablissement automatique des modifications n’est pas toujours souhaitable et qu’un système léger d’alertes de détection de dérive doit compléter le pipeline de déploiement.

Nous sommes convaincus que toute l’infrastructure devrait être définie sous forme de code, afin que les ingénieurs puissent obtenir rapidement des retours de sécurité et une visibilité sur les problèmes.

C’est pourquoi Snyk IaC aide les équipes à réintégrer rapidement dans le code Terraform toutes les ressources réellement utilisées dans leur compte AWS, afin d’accroître la couverture IaC globale et de réduire les problèmes de sécurité. Snyk IaC accélère les corrections en bouclant la boucle de rétroaction entre les équipes de sécurité cloud et d’ingénierie, et en transmettant directement aux ingénieurs des correctifs exploitables, dans des termes qui leur parlent.