Détectez la dérive de configuration et les ressources non gérées avec Snyk IaC

En tant que développeur, vous utilisez probablement un fournisseur cloud pour votre infrastructure. Et il y a de fortes chances que vous en automatisiez certaines parties avec l’infrastructure as code (IaC), afin de rendre les déploiements reproductibles, cohérents, faciles à déployer et, dans l’ensemble, plus sécurisés, car le code rend les paramètres plus visibles.

Au final, nous avons tous des ressources actives chez notre fournisseur cloud, mais nous ne connaissons pas nécessairement leur état actuel à toutes. Quelqu’un a-t-il modifié manuellement la configuration d’un compartiment S3 ? Un collègue a-t-il créé un nouveau chemin dans notre déploiement API Gateway ? Comment savoir si certaines ressources par défaut sont mal configurées ? Et, tôt ou tard, des ressources se retrouvent dans le compte de notre fournisseur cloud sans figurer dans aucun déploiement Terraform, après avoir été modifiées ou même supprimées. Cet écart entre la configuration que nous attribuons à nos ressources cloud et leur configuration réelle est appelé dérive de configuration de l’infrastructure.

Snyk Infrastructure as Code (Snyk IaC) détecte désormais tous les types de dérive de configuration de l’infrastructure et les signale sous forme de ressources Terraform, offrant ainsi aux développeurs une visibilité complète pour intervenir rapidement.Cela inclut les modifications ou suppressions des ressources « gérées » (celles effectivement déployées à partir de l’IaC) et « non gérées » (celles qui ne sont pas encore sous le contrôle de l’IaC). Les rapports générés par l’interface de ligne de commande Snyk peuvent ensuite être consultés directement dans le terminal, intégrés à un pipeline ou à une vérification récurrente, ou exportés au format HTML pour être partagés.

Snyk prend en charge tous les états Terraform et stocke ces fichiers localement sur tous les types de stockage d’objets, notamment Amazon S3, GCS, Azure, HTTPS, Terraform Cloud et bien d’autres. Vous pouvez combiner les stockages pour refléter la structure de votre IaC, que vous ayez plusieurs dépôts Terraform répartis entre différentes équipes ou un modèle plus centralisé. Enfin, la solution fonctionne avec tous les principaux fournisseurs cloud — AWS, GCP et Azure — et requiert le moins de droits d’accès possible.

Dans cet article, nous allons passer en revue quelques problèmes que la gestion de la dérive avec Snyk IaC peut résoudre, notamment :

• Étendre la couverture IaC de vos environnements cloud

• Repérer la dérive de configuration de l’infrastructure dans une fonctionnalité ou une application

• Détecter la dérive au sein d’un service cloud spécifique

Les avantages de la gestion de la dérive

Voici l’histoire d’un service et de nombreuses ressources. Prenons le déploiement d’API Gateway comme exemple simple. Dans AWS, l’expérience est parfaitement intégrée à la console Web. Dans Terraform, il se compose de 10 à 25 ressources, selon la version d’API Gateway. Vos méthodes, vos réponses, les modèles, les routes, les étapes… ce sont toutes des ressources distinctes.

Si vous commencez à écrire du code Terraform à partir de services existants, une liste complète des ressources Terraform non gérées, classées par service cloud et par type de ressource, vous permettra de les repérer facilement et vous fera gagner énormément de temps, au lieu de devoir examiner la structure Terraform de chaque fonctionnalité de chaque service cloud.

Même si notre API Gateway est déjà gérée dans Terraform, rien n’empêche qui que ce soit d’ajouter manuellement une route ou une réponse HTTP — sans que personne ne s’en aperçoive ! La détection de la dérive permet de repérer ces modifications et de les signaler afin d’atténuer les incohérences ou les problèmes de configuration potentiels.

En bref, nous voulons rendre les dérives visibles pour :

• Améliorer la couverture de notre code afin de pouvoir analyser le code et détecter les erreurs de configuration avant le déploiement.

• Agir immédiatement, par exemple en supprimant la ressource ou en annulant la modification avant qu’elle ne cause des dommages.

Étendre votre couverture IaC

Comme beaucoup d’équipes, vous n’avez probablement pas encore tout couvert dans les nombreux dépôts Terraform que vous utilisez et partagez entre équipes. Alors, comment fonctionne la détection des ressources non gérées dans Snyk IaC ?

Snyk IaC rassemble tous les états Terraform que vous lui fournissez dans une grande carte agrégée, puis la compare aux ressources trouvées dans votre compte AWS. Les différences correspondent aux dérives, signalées sous forme de ressources Terraform.

Utiliser describe avec l’option --only-unmanaged de Snyk IaC nous permettra d’obtenir exactement ce résultat :

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%

En tant que développeurs, nous pouvons facilement tirer parti de ce résultat :

• Nous savons d’abord que notre couverture de code est de 44 %, ce qui facilite le suivi des progrès vers l’adoption de l’IaC.

• Deux compartiments S3 (type : aws_s3_bucket) ne figurent pas dans Terraform, et leurs noms nous sont indiqués. Nous pouvons facilement choisir de les importer ou de les supprimer.

• Notre configuration IAM présente quelques incohérences :

  • Un utilisateur IAM « labs » a été créé manuellement (type : aws_iam_user_policy). Que fait cet utilisateur ?

  • Une stratégie d’accès « Administrator » a été associée manuellement à un utilisateur IAM géré nommé « user1-84i30k » (type :aws_iam_policy_attachment). Nos équipes comprennent-elles les conséquences ?

  • Une stratégie IAM complète a été ajoutée manuellement (type aws_iam_user_policy). Qui contrôle son contenu si quelqu’un le modifie ?

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

La gestion de la dérive dans un périmètre spécifique est un autre cas d’usage courant pour les développeurs. Souvent, les développeurs sont responsables d’une fonctionnalité dont le périmètre d’infrastructure est clairement défini. Nous devons détecter les modifications dans le périmètre défini, et non recevoir des alertes concernant l’ensemble du compte cloud.

Une première approche consiste à fournir simplement à Snyk IaC tous les états Terraform, pour découvrir les ressources manquantes et, pour certaines d’entre elles, celles qui ont été 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, tout en obtenant des informations sur la dérive uniquement pour ce périmètre.

• Le rapport indique dans quel état Terraform chaque dérive ou modification a été détectée.

• Cette fonctionnalité est légère, car elle ne nécessite que les droits d’accès les plus limités sur le compte cloud. Surtout, n’utilisez plus les identifiants de déploiement Terraform de votre pipeline CI/CD !

Détecter les ressources manquantes dans un service cloud

En tant que développeurs, nous pouvons vouloir examiner de plus près un seul service cloud, par exemple « S3 » ou « IAM ». Nous pouvons utiliser les filtres de ressources de Snyk IaC pour cela (--filter="aws_resource_name"), mais il faudrait connaître et répertorier toutes les ressources, puis tenir la liste à jour. Fastidieux ! C’est là que l’option --service entre en jeu : elle permet d’inclure un service entier sans avoir à connaître le nombre de ressources 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.

Dans ce cas d’usage, nous obtenons un rapport sur tout ce qui se trouve dans le service AWS IAM. Cela permet de couvrir d’un coup des dizaines de ressources Terraform (clés d’accès, groupes, associations, stratégies, rôles, etc.).

La gestion de la dérive est désormais disponible dans Snyk IaC

Que vous débutiez avec l’IaC ou que vous fassiez partie d’une équipe chevronnée dotée de workflows IaC établis et sophistiqués, la gestion de la dérive dans Snyk IaC vous aide à mieux voir ce qui s’exécute réellement dans vos comptes cloud et à agir rapidement, avec les droits d’accès les plus limités possible.

La gestion de la dérive avec Snyk IaC peut être exécutée localement à la demande sur les ordinateurs des développeurs via l’interface de ligne de commande, dans des pipelines CI/CD ou sous forme de tâches cron planifiées pour obtenir des rapports ciblés (à partir de la version v1.918.0).

La gestion de la dérive est disponible avec toutes les offres Snyk, y compris notre offre gratuite. Commencez dès aujourd’hui à sécuriser votre infrastructure as code.