Installer plusieurs contrôleurs Snyk Kubernetes dans un même cluster Kubernetes

Kubernetes fournit une interface qui facilite l’exécution de systèmes distribués. Il prend en charge la mise à l’échelle et le basculement de vos applications, propose des modèles de déploiement et bien plus encore. En matière de sécurité, ce sont les équipes qui déploient des workloads dans le cluster Kubernetes qui doivent déterminer lesquels surveiller pour répondre aux exigences de sécurité de leurs applications.

Mais que se passerait-il si chaque équipe pouvait contrôler les images de conteneurs analysées et les workloads concernés ? Plusieurs équipes pourraient déployer des workloads dans Kubernetes, chacune ayant ses propres exigences en matière de surveillance. Pour répondre au mieux à ce besoin, chaque équipe peut configurer sa propre intégration Snyk Kubernetes et surveiller les workloads qui la concernent. Voyons comment procéder.

Présentation de l’intégration Snyk Kubernetes

Snyk s’intègre à Kubernetes pour vous permettre d’importer et de tester en continu vos workloads en cours d’exécution, afin d’identifier les vulnérabilités dans les images sous-jacentes ainsi que les configurations susceptibles de réduire leur niveau de sécurité. Une fois les workloads déployés, Snyk continue de les surveiller pour détecter les expositions à de nouvelles vulnérabilités et tout autre problème de sécurité, à mesure que de nouveaux conteneurs sont déployés ou que la configuration des workloads évolue.

Diagramme de l’architecture de l’intégration Kubernetes

Comment installer plusieurs contrôleurs Snyk dans un même cluster Kubernetes

Passons à la partie pratique ! Nous allons vous guider pas à pas pour configurer plusieurs contrôleurs Snyk dans un même cluster Kubernetes. Voici les étapes à suivre :

1. Configurer des espaces de noms distincts

2. Créer une organisation Snyk pour chaque espace de noms

3. Installer et configurer snyk monitor pour le premier espace de noms (apples)

4. Installer et configurer snyk monitor pour le deuxième espace de noms (bananas)

5. Vérifier que les workloads déployés sont automatiquement importés par le biais de la policy

6. Déployer des workloads dans bananas, qui seront importés automatiquement à l’aide d’un fichier de policy Rego

Prérequis

1. Vous devez disposer d’un compte Snyk Business ou Enterprise pour utiliser l’intégration Kubernetes. Si vous n’en avez pas, vous pouvez démarrer un essai gratuit de notre offre Business. Même si vous ne souhaitez pas essayer par vous-même, nous vous encourageons à poursuivre votre lecture (en passant les blocs de code) pour découvrir comment installer et gérer plusieurs contrôleurs Snyk dans un même cluster Kubernetes.

2. Un cluster Kubernetes, tel qu’AKS, EKS, GKE, Red Hat OpenShift ou toute autre distribution prise en charge.

Étape 1 : configurer des espaces de noms distincts

Pour cette démonstration, j’utilise un service Azure AKS comme cluster Kubernetes. Nous allons y installer deux contrôleurs Snyk, chacun dans son propre espace de noms : l’un dans l’espace de noms apples et l’autre dans l’espace de noms bananas, comme l’illustre le schéma ci-dessous.

Créez les espaces de noms comme indiqué ci-dessous :

1➜  kubectl create namespace apples
2namespace/apples created
3➜  kubectl create namespace bananas
4namespace/bananas created

Étape 2 : créer une organisation Snyk pour chaque espace de noms

En utilisant des organisations Snyk distinctes, nous séparons l’analyse des workloads. Les équipes produit peuvent ainsi disposer de leur propre organisation et mieux contrôler l’analyse de leurs workloads et de leurs images. Vous pouvez utiliser la même organisation avec chacun des contrôleurs Snyk déployés, mais nous allons ici les séparer. Dans les deux cas, les workloads apparaîtront avec un libellé que nous définirons lors de l’installation des contrôleurs Snyk.

Nos nouvelles organisations

 Une pour l’espace de noms apples :

Une pour l’espace de noms bananas :

Une fois créées, vous devriez voir deux organisations vides dans l’application Snyk. Nous les utiliserons bientôt.

Pour chaque organisation, activez l’intégration Kubernetes en sélectionnant l’onglet Integrations, puis Kubernetes et enfin Connect. Suivez ensuite les instructions Snyk sur Kubernetes pour terminer la configuration.

Notez les Integration IDs de l’intégration Kubernetes de chaque organisation Snyk : vous en aurez bientôt besoin. Pour récupérer l’Integration ID Kubernetes, cliquez sur l’icône organization settings dans la barre de navigation supérieure de Snyk, puis accédez à Integrations dans la barre latérale et sélectionnez l’intégration Kubernetes, comme indiqué ci-dessous.

Étape 3 : installer et configurer snyk monitor pour l’espace de noms apples

Maintenant que nos organisations et nos intégrations sont configurées et connectées à notre cluster, nous pouvons configurer Snyk Monitor depuis un terminal.

Nous allons créer un fichier pour nous abonner aux événements de workloads, définir les critères de nos abonnements, installer le chart Helm de Snyk pour la surveillance Kubernetes, puis configurer et démarrer le moniteur.

Créer le fichier de registre

Dans un terminal, créez un répertoire pour l’organisation apples, puis accédez-y :

1➜  mkdir apples
2➜  cd apples

Créez un fichier nommé workload-events.rego contenant le texte suivant, en remplaçant <APPLES_INTEGRATION_ID> par l’Integration ID de l’intégration Kubernetes de l’organisation apples.

Dans la policy Rego ci-dessous, nous demandons au contrôleur Snyk d’importer ou de supprimer uniquement les workloads de l’espace de noms apples, à condition que leur type ne soit ni CronJob ni Service. Pour en savoir plus sur les différents types de workloads, consultez la documentation Snyk.

workload-events.rego

1package snyk
2orgs := ["<APPLES_INTEGRATION_ID>"]
3default workload_events = false
4workload_events {
5  input.metadata.namespace == "apples"
6  input.kind != "CronJob"
7  input.kind != "Service"
8}

Ajouter les charts Helm Snyk à votre dépôt

Accédez à votre environnement Kubernetes et exécutez la commande suivante pour ajouter le dépôt Snyk Charts à Helm. Nous en aurons besoin pour installer ce chart Helm.

1➜  helm repo add snyk-charts https://snyk.github.io/kubernetes-monitor --force-update
2"snyk-charts" has been added to your repositories

Créer la configuration de Snyk Monitor et déployer le chart Helm

Un secret Kubernetes nous permet d’exécuter le moniteur sans exposer d’identifiants en texte brut. Dans ces étapes, nous allons créer et utiliser ce secret lors du déploiement de la configuration de l’organisation apples.

Créez le secret snyk-monitor pour l’espace de noms apples, en remplaçant <APPLES_INTEGRATION_ID> par l’ID de l’intégration Kubernetes de l’application Snyk pour apples. Dans cette démonstration, nous utilisons Docker Hub public pour notre registre de conteneurs, qui ne nécessite pas d’identifiants pour accéder aux images publiques. Pour en savoir plus sur l’utilisation de registres de conteneurs privés, consultez la documentation du contrôleur Snyk.

1➜ kubectl create secret generic snyk-monitor -n apples \
2    --from-literal=dockercfg.json={} \
3    --from-literal=integrationId=<APPLES_INTEGRATION_ID>
4secret/snyk-monitor created

Créez ensuite une configmap pour stocker le fichier de policy Rego qui permettra à snyk-monitor de déterminer ce qu’il faut importer ou supprimer automatiquement de l’espace de noms apples :

1➜ kubectl create configmap snyk-monitor-custom-policies -n apples \       --from-file=./workload-events.rego
2configmap/snyk-monitor-custom-policies created

Installez ensuite snyk-monitor dans l’espace de noms apples, en remplaçant <APPLES_INTEGRATION_ID> par l’ID d’intégration de l’application Snyk pour apples dans la commande :

1➜ helm upgrade --install snyk-monitor-apples snyk-charts/snyk-monitor \
2        --namespace apples \
3        --set clusterName="AKS K8s - Apples" \
4        --set policyOrgs=<APPLES_INTEGRATION_ID> \
5        --set workloadPoliciesMap=snyk-monitor-custom-policies
6
7Release "snyk-monitor-apples" does not exist. Installing it now.
8LAST DEPLOYED: Thu Jul 14 19:29:28 2022
9NAMESPACE: apples
10STATUS: deployed
11REVISION: 1
12TEST SUITE: None

Remarque :Le libellé « AKS K8s - Apples » vous permettra de retrouver les workloads importés dans l’interface Snyk, comme vous le verrez bientôt.

Enfin, vérifiez que tout fonctionne (cette commande suppose que jq est installé ; sinon, omettez la partie | jq de l’instruction) :

1➜ helm ls -A -o json | jq
2[
3  {
4"name": "snyk-monitor-apples",
5"namespace": "apples",
6"revision": "1",
7"updated": "2022-07-14 19:45:56.681028 +1000 AEST",
8"status": "deployed",
9"chart": "snyk-monitor-1.92.10",
10"app_version": ""
11  }
12]
13
14➜ kubectl get pods -n apples
15NAME                             READY   STATUS RESTARTS   AGE
16snyk-monitor-apples-797cd64c-sqvj4   1/1 Running   0      16m

À ce stade, un contrôleur Snyk portant un nom unique est installé dans l’espace de noms apples. Nous verrons plus loin comment ce contrôleur importe automatiquement les workloads en fonction de notre configuration, au fur et à mesure de leur déploiement dans l’espace de noms apples du cluster Kubernetes. Pour l’instant, si vous actualisez la page des projets de l’organisation apples, vous remarquerez peut-être que Snyk Monitor lui-même a été analysé : c’est parce que nous lui avons demandé d’analyser les workloads de type Deployment dans l’espace de noms apples.

Étape 4 : installer et configurer snyk monitor pour l’espace de noms bananas

Créez un répertoire nommé bananas, puis accédez-y :

1➜ cd ..
2➜ mkdir bananas
3➜ cd bananas

Créez ensuite un fichier nommé workload-events.rego contenant le texte suivant, et remplacez <BANANAS_INTEGRATION_ID> par l’ID de l’intégration Kubernetes de l’application Snyk pour bananas :

1package snyk
2orgs := ["<BANANAS_INTEGRATION_ID>"]
3default workload_events = false
4workload_events {
5      input.metadata.namespace == "bananas"
6      input.kind != "CronJob"
7      input.kind != "Service"
8}

Créez ensuite le secret snyk-monitor pour l’espace de noms bananas, en remplaçant BANANAS_INTEGRATION_ID par l’ID de l’intégration Kubernetes de l’application Snyk pour bananas :

1➜  ~/snyk/SE/blogs/snyk-multi-namespace-controllers/bananas kubectl create secret generic snyk-monitor -n bananas \
2  --from-literal=dockercfg.json={} \
3  --from-literal=integrationId=BANANAS_INTEGRATION_ID
4secret/snyk-monitor created

Créez ensuite une configmap pour stocker le fichier de policy Rego qui permettra à snyk-monitor de déterminer ce qu’il faut importer ou supprimer automatiquement de l’espace de noms bananas :

1➜ kubectl create configmap snyk-monitor-custom-policies -n bananas --from-file=./workload-events.rego
2configmap/snyk-monitor-custom-policies created

Installez snyk-monitor dans l’espace de noms bananas, en remplaçant ‰¤BANANAS_INTEGRATION_ID> par l’ID de l’intégration Kubernetes de l’application Snyk pour bananas :

1➜ helm upgrade --install snyk-monitor-bananas snyk-charts/snyk-monitor \
2      --namespace bananas \
3      --set clusterName="K8s - Bananas" \
4      --set policyOrgs=<BANANAS_INTEGRATION_ID> \
5      --set workloadPoliciesMap=snyk-monitor-custom-policies
6Release "snyk-monitor-bananas" does not exist. Installing it now.
7NAME: snyk-monitor-bananas
8LAST DEPLOYED: Thu Jul 14 20:19:36 2022
9NAMESPACE: bananas
10STATUS: deployed
11REVISION: 1
12TEST SUITE: None

Enfin, vérifiez que tout fonctionne :

1➜ helm ls -A -o json | jq .
2[
3  {
4"name": "snyk-monitor-apples",
5"namespace": "apples",
6"revision": "1",
7"updated": "2022-07-14 19:45:56.681028 +1000 AEST",
8"status": "deployed",
9"chart": "snyk-monitor-1.92.10",
10"app_version": ""
11  },
12  {
13"name": "snyk-monitor-bananas",
14"namespace": "bananas",
15"revision": "1",
16"updated": "2022-07-14 20:19:36.563328 +1000 AEST",
17"status": "deployed",
18"chart": "snyk-monitor-1.92.10",
19"app_version": ""
20  }
21]
22
23➜ kubectl get pods -n bananas
24NAME                                  READY   STATUS   RESTARTS  AGE
25Snyk-monitor-bananas-54b8c4bf89-r6tf2   1/1 Running   0      3m38s

Étape 5 : vérifier que les workloads déployés sont automatiquement importés par le biais de la policy

Nous allons maintenant déployer des workloads dans l’espace de noms apples pour vérifier qu’ils sont importés automatiquement. Commençons par une application Spring Boot que nous allons déployer dans Kubernetes comme indiqué ci-dessous.

Créez un fichier nommé springbootemployee-K8s.yaml contenant les éléments suivants :

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: springboot-employee-api-apples
5  namespace: apples
6spec:
7  selector:
8matchLabels:
9  app: springboot-employee-api-apples
10  replicas: 1
11  template:
12metadata:
13  labels:
14    app: springboot-employee-api-apples
15spec:
16  containers:
17    - name: springboot-employee-api-apples
18      image: pasapples/springbootemployee:multi-stage-add-layers
19      imagePullPolicy: Always
20      ports:
21        - containerPort: 8080

Déployez-le ensuite :

1➜ kubectl apply -f springbootemployee-K8s.yaml
2deployment.apps/springboot-employee-api-apples created

Après quelques minutes, vérifiez que le workload a été analysé et automatiquement importé dans l’organisation Snyk apples, comme demandé au contrôleur Snyk dans l’espace de noms apples.

Étape 6 : déployer des workloads dans bananas — importation automatique à l’aide du fichier de policy Rego

Créez un fichier nommé snyk-boot-web-deployment.yaml contenant les éléments suivants :

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: snyk-boot-web
5  namespace: bananas
6spec:
7  selector:
8    matchLabels:
9      app: snyk-boot-web
10  replicas: 1
11  template:
12    metadata:
13      labels:
14        app: snyk-boot-web
15    spec:
16      containers:
17        - name: snyk-boot-web
18          image: pasapples/snyk-boot-web:v1
19          imagePullPolicy: Always
20          ports:
21            - containerPort: 5000

Déployez-le comme suit :

1➜ kubectl apply -f snyk-boot-web-deployment.yaml
2deployment.apps/snyk-boot-web created

Après environ 3 minutes, vérifiez que le workload a été analysé et automatiquement importé dans l’organisation Snyk bananas de l’application Snyk, comme demandé au contrôleur Snyk dans l’espace de noms bananas.

Bonus : consulter les journaux des contrôleurs Snyk

La configuration Kubernetes et les fichiers YAML peuvent être délicats. Si vous rencontrez des problèmes lors de la configuration de vos moniteurs, il peut être utile de consulter les journaux de chaque contrôleur Snyk, comme dans les exemples de commandes ci-dessous :

Contrôleur Snyk Apples

1export APPLES_POD=`kubectl get pods --namespace apples -l "app.kubernetes.io/name=snyk-monitor-apples" -o jsonpath="{.items[0].metadata.name}"`
2
3kubectl logs -n apples $APPLES_POD -f

Contrôleur Snyk Bananas

1export BANANAS_POD=`kubectl get pods --namespace bananas -l "app.kubernetes.io/name=snyk-monitor-bananas" -o jsonpath="{.items[0].metadata.name}"`
2
3kubectl logs -n bananas $BANANAS_POD -f

Récapitulatif

Dans cet article, nous avons montré comment déployer plusieurs contrôleurs Snyk dans un même cluster Kubernetes, chacun surveillant son propre espace de noms. Les contrôleurs communiquent avec l’API Kubernetes pour déterminer quels workloads (par exemple Deployment, ReplicationController, CronJob, etc., comme indiqué dans le fichier de policy Rego) sont exécutés sur le cluster, trouver les images qui leur sont associées et les analyser directement sur le cluster pour détecter les vulnérabilités.

N’hésitez pas à essayer ces étapes sur votre propre cluster Kubernetes. Pour cela, démarrez un essai gratuit de l’offre Snyk Business.

Ressources pour en savoir plus

Maintenant que vous savez à quel point il est facile de configurer l’intégration Kubernetes avec Snyk, voici quelques liens utiles pour vous lancer dans la sécurisation de vos conteneurs.

• Sécurité des conteneurs et de Kubernetes avec Snyk

• Présentation de l’intégration Kubernetes

• Comment configurer Snyk Container pour importer ou supprimer automatiquement des projets de workloads Kubernetes

• Apprenez Rego avec l’excellent cours de formation de Styra