Détecter les dérives d’infrastructure et les ressources non gérées avec Snyk IaC

En tant que développeur, vous faites probablement appel à un fournisseur d’infrastructure dans le cloud. Il y a également des chances que vous automatisiez certaines parties de votre infrastructure à l’aide de l’infrastructure en tant que code (IaC) pour que vos déploiements soient reproductibles, faciles à mettre en œuvre et globalement plus sécurisés, le code rendant les paramètres plus visibles.

Au final, nous finissons tous avec des ressources actives sur notre fournisseur de services cloud dont nous ne connaissons pas l’état. Quelqu’un a pu modifier manuellement la configuration d’un compartiment S3. Un collègue a pu créer un nouveau chemin dans le déploiement API Gateway. Une ressource par défaut est peut-être mal configurée. Comment le savoir ? Au final, vous vous retrouvez avec des ressources actives dans le compte de votre fournisseur cloud qui sont totalement absentes du déploiement Terraform, ont été modifiées ou ont été supprimées. L’écart entre la configuration supposée des ressources cloud et leur configuration réelle est appelé dérive d’infrastructure.

Snyk Infrastructure as Code (Snyk IaC) détecte désormais tous les types de dérives d’infrastructure et les signale sous forme de ressources Terraform afin que les développeurs bénéficient d’une visibilité totale sur les problèmes et puissent les corriger rapidement.Sont notamment détectées les modifications ou suppressions de ressources « gérées » (déployées à partir de l’IaC) et « non gérées » (qui ne sont pas encore contrôlées par l’IaC).  Les rapports de Snyk CLI peuvent être consultés directement depuis le terminal, intégrés dans un pipeline ou un contrôle récurrent, ou exportés au format HTML pour être partagés.

Snyk prend en charge tous les états Terraform et stocke ces fichiers en local dans du stockage blob comme Amazon S3, GCS, Azure, HTTPS, Terraform Cloud, etc. Le stockage peut être combiné pour reproduire la structure de votre IaC, que vous disposiez de plusieurs référentiels Terraform répartis dans vos différentes équipes ou suiviez un modèle plus classique.  Enfin, Snyk est compatible avec tous les grands fournisseurs de services cloud (AWS, GCP et Azure) et demande le moins de droits d’accès possible.

Dans cet article de blog, nous allons vous présenter quelques-uns des problèmes liés à la gestion des dérives que Snyk IaC peut vous aider à résoudre, notamment :

• Étendre la couverture par l’IaC dans vos environnements cloud

• Obtenir des informations sur les dérives de l’infrastructure au sein d’une fonction ou d’une application

• Détecter les dérives au sein d’un service cloud donné

Avantages de la gestion des dérives

La situation peut se résumer comme suit : un service pour de nombreuses ressources. Pour le comprendre facilement, prenons un déploiement API Gateway. Dans AWS, cette expérience est parfaitement intégrée dans la console Web. Dans Terraform, elle se décompose en 10 à 25 ressources selon la version d’API Gateway. Vos méthodes, vos réponses, les modèles, les routes, les étapes... tous ces éléments constituent des ressources distinctes.

Cela signifie que si vous commencez à écrire du code Terraform pour des services existants, le fait de disposer d’une liste complète des ressources Terraform non gérées catégorisées par service cloud et type de ressource rendra ces ressources parfaitement visibles et vous fera gagner un temps considérable. En effet, l’alternative consisterait à étudier la structure de chaque service cloud dans Terraform.

Si API Gateway est déjà sous contrôle dans Terraform, rien n’empêche qui que ce soit d’ajouter manuellement une route ou une réponse HTTP... sans que personne ne le sache. La détection des dérivesgarantit que ces modifications sont repérées et signalées pour limiter les incohérences ou problèmes de configuration.

Pour résumer, le fait de rendre les dérives visibles offre les avantages suivants :

• Amélioration de la couverture par le code permettant ensuite de rechercher les erreurs de configuration dans le code avant le déploiement.

• Action immédiate, par exemple supprimer la ressource ou annuler la modification avant que le mal ne soit fait.

Extension de la couverture par l’IaC

Comme de nombreuses autres équipes, toutes vos ressources ne sont pas encore couvertes dans les nombreux référentiels Terraform que vous utilisez et partagez. Comment fonctionne la détection des ressources non gérées dans Snyk IaC ?

Snyk IaC combine tous les états Terraform que vous lui fournissez en une carte agrégée et la compare à ce qu’il détectera sur votre compte AWS. Les différences sont des dérives, signalées sous forme de ressources Terraform.

La commande de Snyk IaC describe utilisée avec l’option --only-unmanaged permet d’obtenir le résultat suivant :

1$ snyk iac describe --only-unmanaged
2[...]
3Snyk Scanning Infrastructure As Code Discrepancies...
4
5  Info:    Resources under IaC, but different to terraform states.
6  Resolve: Reapply IaC resources or update into terraform.
7
8Unmanaged resources: 5
9
10Service: aws_iam [ Unmanaged Resources: 3 ]
11
12  Resource Type: aws_iam_policy_attachment
13    ID: user1-84i30k-arn:aws:iam::aws:policy/AdministratorAccess
14
15  Resource Type: aws_iam_user
16    ID: labs
17
18  Resource Type: aws_iam_user_policy
19    ID: dat-user:manuals3policy
20
21Service: aws_s3 [ Unmanaged Resources: 2 ]
22
23  Resource Type: aws_s3_bucket
24    ID: manual-bucket-2022
25    ID: test-resource-exposure-caxyxllsajfrzbwe
26
27Test Summary
28
29  Managed Resources: 4
30  Unmanaged Resources: 5
31
32  IaC Coverage: 44%

Pour les développeurs, ce résultat est facilement exploitable :

• Nous savons que la couverture du code est de 44 %, ce qui simplifie le suivi de la progression de l’IaC.

• Nous apprenons que deux compartiments S3 (du type : aws_s3_bucket) ne sont pas dans Terraform, et nous connaissons leurs noms. Nous pouvons très facilement choisir de les importer ou de les supprimer.

• Nous constatons que notre configuration IAM présente quelques incohérences : 

Comprendre ce qui a changé depuis votre dernier déploiement

Autre cas d’utilisation fréquent de Sny IaC par les développeurs : la gestion des dérives dans un périmètre donné. Bien souvent, les développeurs sont responsables d’une fonction donnée sur un périmètre bien défini de l’infrastructure. Nous devons détecter ce qui a changé dans le périmètre défini et non recevoir des informations sur l’ensemble du compte cloud.

Pour ce faire, nous pouvons simplement communiquer à Snyk IaC tous les états Terraform pour détecter les ressources manquantes ou modifiées :

1$ snyk iac describe --only-managed
2Snyk Scanning Infrastructure As Code Discrepancies...
3
4  Info:    Resources under IaC, but different to terraform states.
5  Resolve: Reapply IaC resources or update into terraform.
6
7Changed resources: 1
8
9State: tfstate://terraform.tfstate [ Changed Resources: 1 ]
10
11  Resource Type: aws_s3_bucket
12    ID: somebucket-84i30k
13    ~ versioning.0.enabled: false => true
14
15Missing resources: 1
16
17State: Generated [ Missing Resources: 1 ]
18
19  Resource Type: aws_iam_policy_attachment
20    ID: user1-84i30k-arn:aws:iam::aws:policy/ReadOnlyAccess
21
22Test Summary
23
24  Managed Resources: 3
25  Changed Resources: 1
26  Missing Resources: 1
27
28  IaC Coverage: 75%

Ce rapport nous fournit des informations intéressantes :

• Nous pouvons agréger tous les états Terraform que nous utilisons, mais n’obtenir des informations de dérive que pour ce périmètre.

• Le rapport indique dans quel état Terraform se trouve chaque dérive ou modification.

• Cette fonction est légère, car elle demande seulement des droits d’accès limités au compte cloud. N’utilisez plus les identifiants de déploiement Terraform du pipeline de CI/CD !

Détecter les ressources manquantes au sein d’un service cloud

Les développeurs peuvent n’avoir qu’un seul service cloud à vérifier en profondeur, par exemple « S3 » ou « IAM ». Nous pouvons utiliser les filtres de ressources Snyk IaC pour le faire (--filter="aws_resource_name"), mais cela nous impose de tous les connaître et les répertorier, puis de tenir à jour la liste. Un peu compliqué ! L’option --service nous permet d’inclure un service entier sans savoir combien de ressources sont concernées.

1$ snyk iac describe --only-managed --service=aws_iam
2Snyk Scanning Infrastructure As Code Discrepancies...
3
4  Info:    Resources under IaC, but different to terraform states.
5  Resolve: Reapply IaC resources or update into terraform.
6
7Missing resources: 1
8
9State: Generated [ Missing Resources: 1 ]
10
11  Resource Type: aws_iam_policy_attachment
12    ID: user1-84i30k-arn:aws:iam::aws:policy/ReadOnlyAccess
13
14Test Summary
15
16  Managed Resources: 2
17  Missing Resources: 1
18
19  IaC Coverage: 66%
20  Info: To reach full coverage, remove resources or move it to Terraform.

Nous obtiendrons alors un rapport reprenant toutes les ressources détectées dans le service IAM AWS. Cela nous permet de couvrir en toute simplicité des dizaines de ressources Terraform en une seule fois (clés d’accès, groupes, pièces jointes, politiques, rôles, etc.).

La gestion des dérives est désormais disponible dans Snyk IaC

Développeur débutant dans l’IaC ou membre d’une équipe expérimentée disposant de workflows éprouvés et complexes, la gestion des dérives dans Snyk IaC peut vous permettre de gagner en visibilité sur les ressources qui s’exécutent réellement dans vos comptes cloud et vous aider à agir rapidement en utilisant les droits d’accès les plus limités possibles.

L’outil de gestion des dérives de Snyk IaC peut s’exécuter en local sur un ordinateur à l’aide de la CLI, sur les pipelines de CI/CD ou sous forme de tâches CRON programmées pour générer des rapports dédiés (à partir de la version 1.918.0).

La gestion des dérives est disponible avec tous les plans Snyk, y compris le plan gratuit. N’hésitez plus et commencez à sécuriser votre infrastructure en tant que code dès maintenant.