OWASP Kubernetes Top 10 – DZone

L’une des plus grandes préoccupations lors de l’utilisation de Kubernetes est de savoir si nous nous conformons à la posture de sécurité et prenons en compte toutes les menaces possibles. Pour cette raison, l’OWASP a créé le Top 10 OWASP Kubernetes, qui aide à identifier les risques les plus probables.

Les 10 meilleurs projets de l’OWASP sont des ressources de sensibilisation et d’orientation utiles pour les praticiens et les ingénieurs de la sécurité. Ils peuvent également mapper vers d’autres cadres de sécurité qui aident les ingénieurs de réponse aux incidents à comprendre les menaces Kubernetes. Par exemple, les techniques MITRE ATT&CK sont également couramment utilisées pour enregistrer les techniques de l’attaquant et aider les équipes bleues à comprendre les meilleurs moyens de protéger un environnement. De plus, nous pouvons vérifier le modèle de menace Kubernetes pour comprendre toutes les surfaces d’attaque et les principaux vecteurs d’attaque.

Le Top 10 Kubernetes de l’OWASP place tous les risques possibles dans un ordre de similitude ou de probabilité globale. Dans cette recherche, nous modifions légèrement l’ordre. Nous regroupons certains d’entre eux dans une même catégorie, tels que les erreurs de configuration, la surveillance ou les vulnérabilités. Et nous recommandons certains outils ou techniques pour auditer votre configuration et vous assurer que votre posture de sécurité est la plus appropriée.

Qu’est-ce qu’OWASP Kubernetes ?

L’Open Web Application Security Project (OWASP) est une fondation à but non lucratif qui travaille à améliorer la sécurité des logiciels. L’OWASP se concentre sur la sécurité des applications Web (d’où son nom), mais au fil du temps, il a élargi sa portée en raison de la nature de la conception des systèmes modernes.

Alors que le développement d’applications passe d’architectures monolithiques exécutées traditionnellement sur des machines virtuelles cachées derrière des pare-feu à des charges de travail de microservices modernes exécutées sur une infrastructure cloud, il est important de mettre à jour les exigences de sécurité pour chaque environnement d’application.

C’est pourquoi la Fondation OWASP a créé le Top 10 OWASP Kubernetes – une liste des dix vecteurs d’attaque les plus courants spécifiquement pour l’environnement Kubernetes.

Dans le visuel ci-dessus, nous mettons en lumière quel composant ou partie est impacté par chacun des risques qui apparaissent dans OWASP Kubernetes mappé à un modèle de menace Kubernetes généralisé pour aider à la compréhension. Cette analyse plonge également dans chaque risque OWASP, fournissant des détails techniques sur les raisons pour lesquelles la menace est importante et les mesures d’atténuation courantes. Il est également utile de regrouper les risques en trois catégories par ordre de probabilité. Les catégories de risque sont :

Mauvaises configurations

Manque de visibilité

Gestion des vulnérabilités

Mauvaises configurations

Configurations de charges de travail non sécurisées

La sécurité est au premier plan de toutes les offres des fournisseurs de cloud. Les fournisseurs de services cloud tels qu’AWS, GCP et Azure mettent en œuvre un éventail de fonctionnalités de sandboxing, de fonctionnalités de pare-feu virtuel et de mises à jour automatiques des services sous-jacents pour garantir la sécurité de votre entreprise chaque fois que possible. Ces mesures allègent également certaines des charges de sécurité traditionnelles des environnements sur site. Cependant, les environnements cloud appliquent ce que l’on appelle un modèle de sécurité partagé, ce qui signifie qu’une partie de la responsabilité incombe au consommateur de services cloud pour mettre en œuvre ces garde-fous de sécurité dans son environnement de réponse. Les responsabilités varient également en fonction du modèle de consommation du cloud et du type d’offre.

Système opérateur

L’avantage des charges de travail conteneurisées est que les images que vous choisissez sont souvent préchargées avec les dépendances nécessaires pour fonctionner avec l’image de base de vos applications conçue pour un système d’exploitation particulier.

Ces images préemballent certaines bibliothèques système générales et d’autres composants tiers qui ne sont pas exactement requis pour la charge de travail. Et dans certains cas, comme dans l’architecture de microservices (MSA), une image de conteneur donnée peut être trop gonflée pour faciliter un conteneur performant qui exploite le microservice.

Nous vous recommandons d’exécuter des images minimales et simplifiées dans vos charges de travail conteneurisées, telles que les images Alpine Linux, qui sont beaucoup plus petites en taille de fichier. Ces images légères sont idéales dans la plupart des cas. Puisqu’il contient moins de composants, il y a également moins de possibilités de compromis. Si vous avez besoin de packages ou de bibliothèques supplémentaires, envisagez de commencer par l’image Alpine de base et d’ajouter progressivement des packages/bibliothèques si nécessaire pour maintenir le comportement/les performances attendus.

Charges de travail d’audit

Le Benchmark CIS pour Kubernetes peut être utilisé comme point de départ pour découvrir les erreurs de configuration. Le projet open source kube-bench, par exemple, peut vérifier votre cluster par rapport au benchmark Kubernetes (CIS) à l’aide de fichiers YAML pour configurer les tests.

Exemple de contrôle de référence CIS

Minimiser l’admission de conteneurs racine (5.2.6)

Les charges de travail de conteneur Linux peuvent être exécutées par n’importe quel utilisateur Linux. Cependant, les conteneurs qui s’exécutent en tant qu’utilisateur root augmentent la possibilité d’évasion du conteneur (élévation des privilèges puis mouvement latéral dans l’hôte Linux). Le benchmark CIS recommande que tous les conteneurs s’exécutent en tant qu’utilisateur non UID 0 défini.

Un exemple d’outil d’audit Kubernetes qui peut aider à minimiser l’admission de conteneurs racine est kube-admission-webhook. Il s’agit d’un webhook de contrôleur d’admission Kubernetes qui vous permet de valider et de muter les demandes d’API Kubernetes entrantes. En outre, vous pouvez l’utiliser pour appliquer des politiques de sécurité, telles que l’interdiction de la création de conteneurs racine dans votre cluster.

Comment éviter les erreurs de configuration de la charge de travail avec OPA

Des outils tels que Open Policy Agent (OPA) peuvent être utilisés comme moteur de politique pour détecter ces erreurs de configuration courantes. Le contrôleur d’admission OPA vous donne un langage déclaratif de haut niveau à l’auteur et applique des politiques à travers votre pile.

Supposons que vous souhaitiez créer un contrôleur d’admission pour l’image alpine mentionnée précédemment. Cependant, l’un des utilisateurs de Kubernetes souhaite définir le securityContext sur privilege=true.

apiVersion: v1
kind: Pod
metadata:
  name: alpine
  namespace: default
spec:
  containers:
  - image: alpine:3.2
    command:
      - /bin/sh
      - "-c"
      - "sleep 60m"
    imagePullPolicy: IfNotPresent
    name: alpine
    securityContext:
      privileged: true
  restartPolicy: AlwaysCode language: YAML (yaml)

Voici un exemple de pod privilégié dans Kubernetes. L’exécution d’un pod en mode privilégié signifie que le pod peut accéder aux ressources et aux capacités du noyau de l’hôte. Pour empêcher les pods privilégiés, le .rego Le fichier du contrôleur d’admission OPA Gatekeeper devrait ressembler à ceci :

package kubernetes.admission
deny[msg] {
    c := input_containers[_]
    c.securityContext.privileged
    msg := sprintf("Privileged container is not allowed: %v, securityContext: %v",
[c.name, c.securityContext])
}Code language: CSS (css)

Dans ce cas, la sortie devrait ressembler à ce qui suit :

Error from server (Privileged container is not allowed: alpine, securityContext: {"privileged": true}): error when creating "STDIN": admission webhook "validating-webhook.openpolicyagent.org"Code language: Perl (perl)

Composants de cluster mal configurés

Les erreurs de configuration dans les composants principaux de Kubernetes sont beaucoup plus courantes que prévu. Pour éviter cela, un audit continu et automatique des manifestes IaC et K8s (YAML) au lieu de devoir les vérifier manuellement réduira les erreurs de configuration.

Lors de l’audit des charges de travail, il est important de garder à l’esprit qu’il existe différentes manières de déployer une application. Avec le fichier de configuration des différents composants du cluster, vous pouvez autoriser des autorisations spécifiques en lecture/écriture sur ces composants. Dans le cas de Kubelet, par défaut, toutes les requêtes au point de terminaison HTTPS du kubelet qui ne sont pas rejetées par d’autres méthodes d’authentification configurées sont traitées comme des requêtes anonymes et reçoivent un nom d’utilisateur de system:anonymous et un groupe de system:unauthenticated.

Pour désactiver cet accès anonyme pour ces requêtes non authentifiées, démarrez simplement kubelet avec la fonctionnalité drapeau –anonymous-auth=false. Lors de l’audit de composants de cluster comme kubelet, nous pouvons voir que kubelet autorise les requêtes API en utilisant la même approche d’attributs de requête que le serveur API. En conséquence, nous pouvons définir les autorisations telles que :

• POSTE
• OBTENIR
• METTRE
• CORRECTIF
• SUPPRIMER

Cependant, il existe de nombreux autres composants de cluster sur lesquels se concentrer, pas seulement kubelet. Par exemple, les plugins kubectl s’exécutent avec les mêmes privilèges que la commande kubectl elle-même, donc si un plugin est compromis, il pourrait potentiellement être utilisé pour élever les privilèges et accéder aux ressources sensibles de votre cluster.

Sur la base du rapport CIS Benchmark pour Kubernetes, nous vous recommandons d’activer les paramètres suivants pour tous les composants du cluster.

etc.

La base de données etcd offre un magasin clé/valeur hautement disponible que Kubernetes utilise pour héberger de manière centralisée toutes les données du cluster. Il est important de garder etcd en sécurité, car il stocke les données de configuration ainsi que les secrets K8. Nous recommandons vivement régulièrement sauvegarde des données etcd pour éviter la perte de données.

Heureusement, etcd prend en charge une fonction d’instantané intégrée. L’instantané peut être pris à partir d’un membre actif du cluster avec le sauvegarde de l’instantané etcdctl commande. La prise de l’instantané n’aura aucun impact sur les performances. Vous trouverez ci-dessous un exemple de prise d’un instantané de l’espace de clés servi par $ENDPOINT au fichier snapshotdb :

ETCDCTL_API=3 etcdctl --endpoints $ENDPOINT snapshot save snapshotdbCode language: Perl (perl)

C’était apiserver

Le…