Google vient de mettre à disposition en pre-GA (General Availability) un nouveau moyen de sécuriser et de contrôler les conteneurs qui tournent dans vos clusters Google Kubernetes Engine (GKE).

Attention ! Les fonctionnalités proposées avant la mise à disposition générale peuvent être limitées, et les modifications apportées à ces fonctionnalités peuvent ne pas être compatibles avec d'autres versions pré-disponibles).

La nouvelle fonctionnalité de sécurité s’appelle “Protect pour GKE” et inclut actuellement une solution de scan automatique des problèmes de configuration des charges de travail. Cette solution n’a pas de coût supplémentaire et les scans n'utilisent pas de ressources de calcul de vos nœuds.

Qu’est ce que fait le scan automatique des workloads ?

Les charges de travail que vous déployez sur GKE doivent idéalement disposer d'une configuration renforcée qui limite leur surface d'attaque. Il peut être difficile de vérifier manuellement les charges de travail des clusters pour détecter les problèmes de configuration à grande échelle. Il existe cependant des solutions comme Kyverno ou Open Policy Agent (OPA) pour faire des modifications sur chacune des configurations qui sont appliquées au cluster dès le déploiement des charges de travail. On peut aussi comparer cette solution avec “Pod Security admission” qui remplace les “Pod security policy” qui sont dépréciées depuis la 1.21 et sera complètement supprimées à la version 1.25 de Kubernetes, même si “Pod Security” ne fera pas que de la sensibilisation et pourra intervenir selon tel ou tel cas.

GKE analyse automatiquement la configuration de toutes les charges de travail en cours d'exécution sur plusieurs clusters de façon centralisée et renvoie des résultats exploitables et notés, ainsi que des recommandations pour améliorer votre stratégie de sécurité.

L'analyse automatique vérifie chacune des configuration des charges de travail déployées selon les bonnes pratiques, telles que celles définies dans les normes de sécurité des pods de Kubernetes.

Avantages de l'analyse de la configuration des charges de travail :

  • Automatisez la détection des problèmes de configuration connus dans toutes les charges de travail.
  • Obtenez des recommandations exploitables pour améliorer la sécurité.
  • Utilisez Cloud Console pour obtenir une vue d'ensemble des problèmes de configuration.

Fonctionnement de l'analyse de la configuration de la charge de travail

Pour chaque charge de travail déployée, GKE analyse en continu la spécification de la charge de travail et compare les champs et les valeurs aux contrôles définis dans les normes de sécurité des pods. Par exemple, un pod avec spec.containers.securityContext.privileged=true ne respecte pas la norme Baseline et un pod avec le champ spec.securityContext.runAsNonRoot défini sur false ne respecte pas la norme restreinte.

GKE évalue ensuite la gravité des problèmes de configuration détectés en fonction du renforcement de la sécurité intégré à GKE. La console Google Cloud affiche les résultats et les actions recommandées pour résoudre le problème. GKE ajoute également des entrées à Cloud Logging pour le traçage et l'audit.

L’analyse de la configuration de la charge de travail va effectuer des vérifications sur tous les éléments suivants :

  • Espaces de noms d’hôte
  • conteneurs privilégiés
  • Accès au port hôte
  • Fonctionnalités autres que celles par défaut
  • Installer des volumes de chemins d’accès à l’hôte
  • Élévation des privilèges
  • etc…

Avec la définition des types de problèmes, les champs impactés dans les charges de travail, les valeurs autorisées et la gravité de ce problème.

Et pour chaque analyse il vas nous afficher selon les problèmes les informations suivantes:

  • Gravité: note de gravité GKE pour la préoccupation, qui peut être l'une des suivantes :
  • Critique: agissez immédiatement. Une attaque conduit à une fuite de conteneur.
  • Élevée: agissez rapidement. Une attaque entraînera très probablement une fuite de conteneur.
  • Moyenne: agir dans un futur proche. Une attaque entraînera probablement une fuite de conteneur.
  • Low (Faible) : agissez si besoin. Une attaque peut entraîner l'échappement d'un conteneur.
  • Catégorie: brève description de la préoccupation, basée sur la norme de sécurité du pod associée.
  • Clusters concernés: nombre de clusters contenant des charges de travail ayant le problème détecté.
  • Charges de travail concernées: nombre de charges de travail concernées par les problèmes de configuration de vos clusters.

Quelques limites

Cette fonctionnalité à quand même quelques Limites qui sont :

  • Les conteneurs Windows Server ne sont pas compatibles.
  • Protection pour GKE n'analyse pas les charges de travail gérées par GKE, telles que les charges de travail de l'espace de noms kube-system.
  • L'analyse de la configuration des charges de travail n'est disponible que pour les clusters de moins de 100 nœuds.

Passons à la pratique

Avant tout, il vous faudra activer les API pour “container security” et Kubernetes Engine sur GCP. Pour cela:

  1. allez dans le menu de GCP
  2. sélectionnez “API et services”
  3. allez sur “+ ACTIVER DES API ET DES SERVICES”.

Il ne vous restera plus qu’à chercher “Kubernetes Engine API“ et “Container Security API” afin de les activer.

Si vous voulez activer l’api via la cli Gcloud, exécutez la commande suivante:

gcloud config set project YOUR_PROJECT_ID
gcloud services enable containersecurity.googleapis.com

Création du cluster GKE avec le service de sauvegarde de GKE

La première étape consiste à disposer d’un cluster GKE, pour cela allez dans le menu de GCP et allez dans Kubernetes Engine :

Cliquez sur “Configurer” sur “GKE Standard” afin de pouvoir arriver sur la page de configuration de votre cluster. Pour la création du cluster, dans notre cas, nous allons laisser les différentes valeurs par défaut.

Si vous voulez créer un cluster GKE rapidement avec l’activation de l’analyse de la configuration de la charge de travail sur le cluster GKE, vous pouvez utiliser la commande Gcloud suivante :

gcloud beta container clusters create-auto CLUSTER_NAME \
--region=COMPUTE_REGION \
--enable-workload-config-audit

Si vous avez déjà un cluster existant il vous suffira d’exécuter la commande gcloud suivant :

gcloud beta container clusters update CLUSTER_NAME \
--region=COMPUTE_REGION \
--enable-workload-config-audit

Si vous voulez activer via la console ce service il vous faudra :

  • Aller dans “Kubernetes Engine”
  • Cliquer sur protection

et vous obtiendrez le résultat suivant (si vous avez bien activé l’API de container security, sinon il vous renverra sur la fenêtre d’activation de cette dite API).

Cliquer sur la partie surlignée ci-dessus (dans la partie paramètre de protection et choisissez “Sélectionner des clusters) ce qui vous ramènera sur la page suivante :

Maintenant que nous avons choisi les clusters sur lesquels nous voulions activer le scan automatique, nous pouvons retrouver le tableau de bord suivant avec le résumé de toutes les informations que ce soit le nombre de problèmes détectés, sur combien de charge de travail, etc…

Pour notre exemple je vais déployer l’application suivante :

apiVersion: "apps/v1"
kind: "Deployment"
metadata:
  name: "nginx-1"
  namespace: "default"
  labels:
    app: "nginx-1"
spec:
  replicas: 3
  selector:
    matchLabels:
      app: "nginx-1"
  template:
    metadata:
      labels:
        app: "nginx-1"
  spec:
    containers:
    - name: "nginx-1"
      image: "nginx:latest"
      securityContext:
        runAsNonRoot: false

Vu que nous précisons rien dans la partie sécurité context et qu’il n’y a aucun mécanisme qui est ajouté sur notre cluster pour la sécurité comme du mutating avec Kyverno ou de l’OPA, nous pourrons voir que notre container que nous avons déployé peut tourner en root va nous être affiché sur le tableau de bord après son analyse :


Dans  la partie problème sélectionnez n’importe quel problème afin d’avoir plus amples informations sur le problème en question, les actions recommandées, quelle charge de travail est affectée, etc… :

Le mot de la fin

Cet outil apporte une solution de sécurité pour toutes les charges de travail dans un cluster GKE.

Afin d’appliquer et de vérifier si nos clusters respectent bien les recommandations de sécurité, même s’il faut garder à l’esprit que cet outil ne fait que de l’audit, il n’y a pas d’auto remédiation sur les problèmes.

On peut clairement comparer cet outil au Pod Security Admission de Kubernetes mais avec une UI et en mode Audit.

Nous pourrons compléter cette solution avec des outils de mutating qui peuvent appliquer des recommandations en sécurité en enforce policy, mais cela rajoute sur chaque cluster une brique supplémentaire à gérer.