Créer des règles IaC personnalisées avec Snyk

Dans un monde où le cloud natif prend une place toujours plus importante, l’infrastructure as code (IaC) est souvent le premier point d’entrée dans une application. Avec la popularité croissante de technologies comme Kubernetes et Terraform, la plupart des développeurs d’applications mettront à jour au moins une ressource Kubernetes ou Terraform au cours de leur carrière.

La mise à jour et la maintenance de l’infrastructure peuvent être aussi simples que la gestion de quelques fichiers de configuration ou aussi complexes que l’orchestration d’une architecture élaborée avec plusieurs stacks cloud natives. Mais une chose est sûre : la sécurité de l’infrastructure est essentielle à celle des applications. Et même si de nombreux fournisseurs cloud et outils d’analyse IaC proposent des ensembles de règles de configuration et de sécurité intégrés ou créés par la communauté, les infrastructures sont souvent trop diverses et complexes pour qu’une approche universelle puisse toutes les sécuriser.

Dans cet article, je vous explique comment sécuriser votre environnement d’infrastructure avec les règles personnalisées Snyk IaC. Grâce au SDK des règles Snyk IaC (snyk-iac-rules), vous pouvez désormais écrire, tester et regrouper des règles d’infrastructure personnalisées pour la Snyk CLI.

Gagnez en flexibilité avec Open Policy Agent (OPA)

En coulisses, Snyk IaC s’appuie sur Open Policy Agent (OPA), un agent généraliste open source, et sur son langage Rego pour définir des règles personnalisées. Comme OPA est indépendant des frameworks, les équipes peuvent facilement modifier et appliquer des politiques dans l’ensemble de leur stack cloud native, qu’il s’agisse d’infrastructure, d’autorisation des applications ou de contrôle d’admission Kubernetes.

Les règles étant écrites dans le langage de requête natif d’OPA, elles peuvent également être exportées et réutilisées en dehors de Snyk. Ainsi, tout investissement réalisé ici peut être exploité dans l’écosystème d’intégrations OPA.

Pour suivre ce guide, vous aurez besoin de connaissances de base sur OPA, ainsi que sur WebAssembly (Wasm) et les artefacts OCI, que nous utilisons pour regrouper et distribuer les règles.

Renforcez votre sécurité grâce aux règles personnalisées

Les règles personnalisées vous permettent de répondre à chaque besoin spécifique. Elles constituent donc un outil puissant lorsqu’elles sont associées à des ensembles de règles préconfigurés et modélisés contre les menaces par des experts en sécurité.

Prenons l’exemple d’une règle personnalisée. Imaginons que je sois architecte de sécurité et que mon entreprise impose une exigence interne précise : toutes les ressources Terraform aws_iam_role de notre application doivent comporter les tags owner, description et type.

Je souhaite donc exécuter une règle qui :

• Vérifie que toutes les ressources IAM Role existantes ou futures comportent les tags owner, description et type

• Alerte les développeurs d’applications lorsqu’ils oublient d’ajouter des tags.

Je souhaite également configurer notre CI/CD pour qu’elle échoue lorsqu’une modification du code ne respecte pas cette norme, afin qu’elle ne soit pas déployée dans nos environnements de production.

Comment faire ? En configurant la Snyk CLI pour qu’elle s’exécute dans ma CI/CD avec un ensemble de règles personnalisées que j’écris, regroupe et publie dans un emplacement sécurisé de mon choix.

Créer une règle IaC personnalisée avec Snyk

Avec le nouveau SDK des règles Snyk IaC, je peux précisément faire cela. Je l’installe sur ma machine et, grâce à la documentation sur les règles personnalisées, je peux rapidement faire appliquer ma nouvelle norme de tags dans la Snyk CLI.

Prenons l’exemple de la ressource Terraform suivante, à laquelle je souhaite ajouter nos tags owner, description et type :

1resource "aws_iam_role" "denied" {
2  name = "denied"
3  assume_role_policy = jsonencode({
4      Version   = "2012-10-17"
5      Statement = [
6        {
7          Action    = "sts:AssumeRole"
8          Effect    = "Allow"
9          Sid       = ""
10          Principal = {
11            Service = "ec2.amazonaws.com"
12          }
13        },
14      ]
15  })
16  tags = {
17    description = "a tag that describes something"
18  }
19}

En suivant le guide de démarrage de la documentation sur les règles personnalisées, j’exécute la commande template pour générer une règle de base :

1$ snyk-iac-rules template --rule CUSTOM-RULE-8

Je souhaite que cette norme de tags corresponde à une règle de gravité moyenne. Je modifie donc le modèle en conséquence et personnalise le titre et le message :

1package rules
2
3aws_iam_role_tags_missing(resource) {
4    not resource.tags.owner
5}
6
7aws_iam_role_tags_missing(resource) {
8    not resource.tags.description
9}
10
11aws_iam_role_tags_missing(resource) {
12    not resource.tags.type
13}
14
15deny[msg] {
16    resource := input.resource.aws_iam_role[name]
17    aws_iam_role_tags_missing(resource)
18
19    msg := {
20        "publicId": "CUSTOM-RULE-8",
21        "title": "IAM Role missing one of the required tags: owner, description or type",
22        "severity": "medium",
23        "msg": sprintf("input.resource.aws_iam_role[%s].tags", [name]),
24        "issue": "",
25        "impact": "",
26        "remediation": "",
27        "references": [],
28    }
29}

Avant de regrouper et de publier la règle, j’écris des tests unitaires pour en vérifier le comportement et place mon fichier Terraform de test dans le fichier généré ./rules/CUSTOM-RULE-8/fixtures/denied2.tf :

1package rules
2
3import data.lib
4import data.lib.testing
5
6test_CUSTOM_RULE_8 {
7        # array containing test cases where the rule is allowed
8        allowed_test_cases := []
9
10        # array containing cases where the rule is denied
11        denied_test_cases := [{
12            "want_msgs": ["input.resource.aws_iam_role[denied].tags"],
13            "fixture": "denied2.tf",
14        }]
15
16        test_cases := array.concat(allowed_test_cases, denied_test_cases)
17        testing.evaluate_test_cases("CUSTOM-RULE-8", "./rules/CUSTOM-RULE-8/fixtures", test_cases)
18}

Vous trouverez cette règle et d’autres encore dans notre dépôt GitHub public.

1$ snyk-iac-rules test
2PASS: 1/1

Une fois les tests exécutés et validés, je regroupe la règle à l’aide du SDK et peux même la tester localement avec la Snyk CLI en utilisant l’option --rules. Pour commencer, je vérifie que je suis authentifié auprès d’une organisation test-org, où je mènerai désormais toutes mes expérimentations avec des règles personnalisées :

1$ snyk auth

Je crée ensuite mon ensemble de règles personnalisées et le transmets à l’option --rules pour vérifier que les problèmes IaC sont bien détectés :

1$ snyk-iac-rules build .
2Generated bundle: bundle.tar.gz
3
4$ snyk iac test --rules=bundle.tar.gz ./fixtures/custom-rules/rules/CUSTOM-RULE-8/fixtures/denied2.tf
5
6Testing ./fixtures/custom-rules/rules/CUSTOM-RULE-8/fixtures/denied2.tf...
7
8Infrastructure as code issues:
9  ✗ IAM Role missing one of the required tags: owner, description or type [Medium Severity] [CUSTOM-RULE-8]
10    introduced by input > resource > aws_iam_role[denied] > tags
11
12Organization:      test-org
13Type:              Terraform
14Target file:       ./fixtures/custom-rules/rules/CUSTOM-RULE-8/fixtures/denied2.tf
15Project name:      fixtures
16Open source:       no
17Project path:      ./fixtures/custom-rules/rules/CUSTOM-RULE-8/fixtures/denied2.tf
18
19Tested ./fixtures/custom-rules/rules/CUSTOM-RULE-8/fixtures/denied2.tf for known issues, found 1 issues

Maintenant que je sais que la Snyk CLI peut interpréter ma règle, je la publie dans un registre OCI, en l’occurrence DockerHub, et lui attribue le tag de première version de mes règles personnalisées. Ainsi, si je publie ultérieurement des modifications incompatibles, je pourrai déployer progressivement les règles en utilisant un nouveau tag :

1$ snyk-iac-rules push --r docker.io/snykgoof/oci-example:v1 bundle.tar.gz

Enfin, j’impose l’utilisation de ma nouvelle règle personnalisée à toutes les équipes de mon service en configurant les paramètres IaC de mon groupe Snyk via l’API publique des paramètres IaC de groupe.

1curl --location --request PATCH 'https://api.snyk.io/v3/groups/<group_id>/settings/iac/?version=2021-11-03~beta' \
2--header 'Content-Type: application/vnd.api+json' \
3--header 'Authorization: token <API key from Snyk>' \
4--data-raw '{
5   "data": {
6         "type": "iac_settings",
7         "attributes": {
8           "custom_rules": {
9             "oci_registry_url": "https://registry-1.docker.io/snykgoof/oci-example",
10             "oci_registry_tag": "v1",
11             "is_enabled": true
12           }
13       }
14   }
15}'

J’ai automatisé toutes ces étapes à l’aide d’un workflow GitHub Actions, comme vous pouvez le voir dans notre dépôt GitHub public. Désormais, tout développeur d’applications ou pipeline CI/CD authentifié auprès d’une organisation de mon groupe utilisera ma règle personnalisée. Pour en savoir plus sur l’intégration de la Snyk CLI et du SDK des règles Snyk IaC avec GitHub, consultez notre documentation.

Si nous décidons d’appliquer des règles personnalisées différentes selon les services de l’entreprise, nous pouvons également remplacer les paramètres de règles personnalisées au niveau de l’organisation et exécuter ainsi un ensemble distinct pour cette organisation uniquement. Par exemple, pour continuer à utiliser l’option --rules afin de tester mes règles personnalisées avec la Snyk CLI, j’ai désactivé les paramètres de règles personnalisées pour mon organisation test-org. Je peux ainsi fournir mes propres règles personnalisées en local :

À l’avenir, je pourrais décider que l’équipe Platform a besoin d’un ensemble de règles personnalisées plus strict. Je configurerai alors son organisation pour utiliser un autre ensemble de règles personnalisées, stocké dans un artefact OCI différent.

Tirez parti des règles personnalisées Snyk IaC

Nous avons vu comment, en tant qu’architecte de sécurité, j’ai utilisé le SDK des règles Snyk IaC pour définir de nouvelles normes de sécurité pour mon service. Voyons maintenant comment, en tant que développeur d’applications, je bénéficie de cette fonctionnalité pendant le développement.

Imaginons que j’ajoute une nouvelle ressource aws_iam_role à l’infrastructure Terraform de notre application afin de configurer un nouveau rôle IAM :

1resource "aws_iam_role" "new_role" {
2  name               = "new_role"
3  assume_role_policy = jsonencode({
4    Version   = "2021-11-18"
5    Statement = [
6      {
7        Action    = "sts:AssumeRole"
8        Effect    = "Allow"
9        Sid       = ""
10        Principal = {
11          Service = "ec2.amazonaws.com"
12        }
13      },
14    ]
15  })
16}

J’ai effectué des tests en local et vérifié que mon rôle IAM était correctement configuré. Cependant, j’ai oublié que mon service impose des règles de tag très strictes pour toutes nos ressources. Au moment d’ouvrir une PR, je constate que le dépôt vers lequel je pousse mon code est configuré pour exécuter Snyk IaC GitHub Action, et que la vérification échoue.

J’examine les résultats et remarque que mon nouveau fichier fait échouer la vérification de la PR. Plus précisément, il manque à ma ressource les tags owner, description et type.

Je retourne à mon code pour ajouter les tags manquants. Après avoir poussé ma modification et relancé la vérification de la PR, je peux déployer en toute sécurité et en toute confiance la nouvelle ressource dans notre environnement de production !

Sécurisez vos applications avec Snyk IaC

Snyk Infrastructure as Code (Snyk IaC) vous aide à accélérer votre développement sans compromettre la sécurité. La solution fournit aux développeurs des informations de sécurité et des correctifs intégrés au code pour Terraform, CloudFormation, les configurations Kubernetes et les modèles ARM, prêts à être fusionnés directement dans le code.

Snyk IaC s’intègre aux outils utilisés par les développeurs : des systèmes comme Terraform Cloud et des outils CI/CD, mais aussi des outils de développement comme les systèmes de gestion du code source (GitHub, GitLab, Bitbucket) et les IDE.

Commencez gratuitement dès maintenant avec Snyk IaC sur notre plateforme ou en téléchargeant la dernière version de la Snyk CLI.