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.
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 :
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 :
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:
Avant tout, il vous faudra activer les API pour “container security” et Kubernetes Engine sur GCP. Pour cela:
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
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 :
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… :
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.