Cas pratique sur la sécurisation d'un cluster Kubernetes

Magazine
Marque
MISC
Numéro
112
Mois de parution
novembre 2020
Domaines


Résumé

Cet article présente trois exemples de problèmes de sécurité rencontrés sur des clusters Kubernetes, causés par un manque de maîtrise des applications déployées sur un cluster par ses administrateurs ou par les développeurs des applications s’y exécutant. Nous donnons ensuite des pistes afin de mieux maîtriser et sécuriser ces applications.


1. Présentation de la machinerie Kubernetes

Kubernetes est un orchestrateur de conteneurs, qui exécute des applications – typiquement distribuées sous forme d'images Docker – sur un ensemble de machines appelées cluster. Nous présenterons d'abord les objets contenant les données qui définissent entièrement la configuration du cluster, accessibles via des API. Ces objets sont créés et consommés par la machinerie (extensible) de Kubernetes, que nous présenterons ensuite. Pour terminer cette présentation de Kubernetes, nous présenterons différents modes d'installation et leurs impacts sur la sécurité.

1.1 API Server et Custom Resource Definitions

La pierre angulaire de Kubernetes est son API server, qui offre l'accès aux objets décrivant la configuration du cluster. Ces données sont stockées dans une base de données distribuée clef-valeur etcd [1].

Les principaux types d'objets qui seront utilisés dans cet article sont :

  • Les Pods, qui...
Cet article est réservé aux abonnés. Il vous reste 96% à découvrir.
à partir de 21,65€ HT/mois/lecteur pour un accès 5 lecteurs à toute la plateforme
J'en profite
Références

[1] Stockage clef-valeur distribué etcd : https://etcd.io/

[2] Documentation Kubernetes : https://kubernetes.io/docs

[3] Opérateur Prometheus : https://github.com/prometheus-operator/prometheus-operator

[4] Collecte de métriques Prometheus : https://prometheus.io/

[5] Documentation RBAC : https://kubernetes.io/docs/reference/access-authn-authz/rbac/

[6] Cluster de développement et test minikube : https://minikube.sigs.k8s.io/docs/

[7] Définition de politiques de sécurité avec Open Policy Agent : https://www.openpolicyagent.org/

[8] Intégration continue / déploiement continu avec Jenkins : https://www.jenkins.io/

[9] Intégration continue / déploiement continu avec ArgoCD : https://argoproj.github.io/argo-cd/

[10] Webshell GoTTY : https://github.com/yudai/gotty

[11] Dépôt d'images Docker open source Harbor : https://goharbor.io/

[12] Tracing distribué Jaeger : https://www.jaegertracing.io/

[13] Service mesh Istio : https://istio.io/

[14] Console d’administration Kubernetes : https://github.com/kubernetes/dashboard

[15] Overlay network Flannel : https://github.com/coreos/flannel

[16] Exemples de NetworkPolicies : https://github.com/ahmetb/kubernetes-network-policy-recipes

[17] Analyse statique d'images Docker avec Clair : https://github.com/quay/clair

[18] Client en ligne de commandes pour Clair, Klar : https://github.com/optiopay/klar/

[19] Revue de configuration d'un Pod avec kubesec : https://github.com/controlplaneio/kubesec

[20] Analyse de configuration d'un cluster avec kube-bench : https://github.com/aquasecurity/kube-bench

[21] Écosystème « cloud-native » : https://landscape.cncf.io/

[22] Environnement Kubernetes vulnérable kubernetes-goat : https://github.com/madhuakula/kubernetes-goat



Articles qui pourraient vous intéresser...

Sûreté mémoire : le temps des cerises

Magazine
Marque
MISC
Numéro
113
Mois de parution
janvier 2021
Domaines
Résumé

L’étude et la compréhension des buffer overflow datent de 1972, et leurs premiers usages documentés de 1988 [1]. Près de 50 ans plus tard, où en sommes-nous ? Il nous faut bien admettre que la situation est déprimante : Microsoft et Google reconnaissent chacun ([2], [3]) que près de 2/3 des attaques utilisent à un moment ou un autre une vulnérabilité mémoire. Le ver Morris, qui n’était au départ qu’une preuve de concept, avait quand même coûté la bagatelle de quelques millions de dollars à l’époque… Aujourd’hui, les coûts sont abyssaux : sur le plan financier bien sûr, mais aussi pour nos vies privées, voire nos vies tout court. Face à ce problème, de nombreuses approches sont possibles : analyse statique du code, instrumentation et vérification à l’exécution, langages « sûrs »… Je vous propose d’explorer dans cet article un vieux concept remis au goût du jour, les capabilities, et tout ce qu’elles pourraient nous permettre de faire.

Zerologon pour les (mots de passe) nuls

Magazine
Marque
MISC
Numéro
113
Mois de parution
janvier 2021
Domaines
Résumé

ZeroLogon est LA vulnérabilité de septembre 2020 qui expose de nombreux domaines Windows à une compromission totale via un scénario d’exploitation réaliste et fiable. Mais ce qui donne à Zerologon ses lettres de noblesse c’est qu’elle repose essentiellement sur la mauvaise utilisation d’un algorithme cryptographique permettant de réaliser une attaque à clair choisi particulièrement astucieuse. Zoom sur la vulnérabilité la plus passionnante de la rentrée 2020 !

Sécurité avancée des services Serverless (FaaS)

Magazine
Marque
MISC
Numéro
113
Mois de parution
janvier 2021
Domaines
Résumé

Les fonctions Serverless sont aujourd’hui une nouvelle tendance du cloud. Rapides et peu onéreuses, elles ne requièrent aucun entretien des infrastructures sous-jacentes par le client. Cependant, ce service entraîne un changement de modèle d’architecture, rendant les solutions de protection classiques inadaptées. Ce papier sensibilise aux nouvelles menaces du cloud et suggère différentes règles à suivre pour s’en prémunir.