Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
L'auteur original de cette page est Jorge (lisez son post original ici)
Permet d'exécuter des conteneurs dans un moteur de conteneurs.
La planification permet une mission efficace des conteneurs.
Maintient les conteneurs en vie.
Permet les communications entre conteneurs.
Permet des techniques de déploiement.
Gère des volumes d'informations.
Node : système d'exploitation avec pod ou pods.
Pod : Enveloppe autour d'un conteneur ou de plusieurs conteneurs. Un pod ne doit contenir qu'une seule application (donc généralement, un pod exécute juste 1 conteneur). Le pod est la manière dont Kubernetes abstrait la technologie des conteneurs en cours d'exécution.
Service : Chaque pod a 1 adresse IP interne provenant de la plage interne du nœud. Cependant, il peut également être exposé via un service. Le service a également une adresse IP et son objectif est de maintenir la communication entre les pods, donc si l'un meurt, le nouveau remplacement (avec une adresse IP interne différente) sera accessible exposé à la même IP du service. Il peut être configuré comme interne ou externe. Le service agit également comme un équilibreur de charge lorsque 2 pods sont connectés au même service.
Lorsque un service est créé, vous pouvez trouver les points de terminaison de chaque service en exécutant kubectl get endpoints
Kubelet : Agent principal du nœud. Le composant qui établit la communication entre le nœud et kubectl, et ne peut exécuter que des pods (via le serveur API). Le kubelet ne gère pas les conteneurs qui n'ont pas été créés par Kubernetes.
Kube-proxy : est le service chargé des communications (services) entre le serveur API et le nœud. La base est un IPtables pour les nœuds. Les utilisateurs les plus expérimentés pourraient installer d'autres kube-proxies d'autres fournisseurs.
Sidecar container : Les conteneurs sidecar sont les conteneurs qui doivent s'exécuter avec le conteneur principal dans le pod. Ce modèle sidecar étend et améliore la fonctionnalité des conteneurs actuels sans les modifier. De nos jours, nous savons que nous utilisons la technologie des conteneurs pour envelopper toutes les dépendances nécessaires au fonctionnement de l'application n'importe où. Un conteneur ne fait qu'une seule chose et le fait très bien.
Master process :
Api Server : C'est la manière dont les utilisateurs et les pods communiquent avec le processus maître. Seules les requêtes authentifiées doivent être autorisées.
Scheduler : La planification fait référence à s'assurer que les Pods sont associés aux Nœuds afin que Kubelet puisse les exécuter. Il a suffisamment d'intelligence pour décider quel nœud a le plus de ressources disponibles et attribuer le nouveau pod à celui-ci. Notez que le planificateur ne démarre pas de nouveaux pods, il communique simplement avec le processus Kubelet en cours d'exécution à l'intérieur du nœud, qui lancera le nouveau pod.
Kube Controller manager : Il vérifie les ressources comme les ensembles de réplicas ou les déploiements pour vérifier si, par exemple, le nombre correct de pods ou de nœuds est en cours d'exécution. En cas de pod manquant, il communiquera avec le planificateur pour en démarrer un nouveau. Il contrôle la réplication, les jetons et les services de compte à l'API.
etcd : Stockage de données, persistant, cohérent et distribué. C'est la base de données de Kubernetes et le stockage clé-valeur où il conserve l'état complet des clusters (chaque changement est enregistré ici). Des composants comme le Scheduler ou le Controller manager dépendent de ces données pour savoir quels changements ont eu lieu (ressources disponibles des nœuds, nombre de pods en cours d'exécution...)
Cloud controller manager : C'est le contrôleur spécifique pour les contrôles de flux et les applications, c'est-à-dire : si vous avez des clusters dans AWS ou OpenStack.
Notez qu'il peut y avoir plusieurs nœuds (exécutant plusieurs pods), il peut également y avoir plusieurs processus maîtres dont l'accès au serveur API est équilibré et leur etcd synchronisé.
Volumes :
Lorsqu'un pod crée des données qui ne doivent pas être perdues lorsque le pod disparaît, elles doivent être stockées dans un volume physique. Kubernetes permet d'attacher un volume à un pod pour persister les données. Le volume peut être sur la machine locale ou dans un stockage distant. Si vous exécutez des pods sur différents nœuds physiques, vous devez utiliser un stockage distant afin que tous les pods puissent y accéder.
Autres configurations :
ConfigMap : Vous pouvez configurer des URLs pour accéder aux services. Le pod obtiendra des données d'ici pour savoir comment communiquer avec le reste des services (pods). Notez que ce n'est pas l'endroit recommandé pour enregistrer des identifiants !
Secret : C'est l'endroit pour stocker des données secrètes comme des mots de passe, des clés API... encodées en B64. Le pod pourra accéder à ces données pour utiliser les identifiants requis.
Deployments : C'est ici que les composants à exécuter par Kubernetes sont indiqués. Un utilisateur ne travaillera généralement pas directement avec des pods, les pods sont abstraits dans des ReplicaSets (nombre de mêmes pods répliqués), qui sont exécutés via des déploiements. Notez que les déploiements sont pour des applications sans état. La configuration minimale pour un déploiement est le nom et l'image à exécuter.
StatefulSet : Ce composant est spécifiquement destiné aux applications comme les bases de données qui ont besoin d'accéder au même stockage.
Ingress : C'est la configuration utilisée pour exposer l'application publiquement avec une URL. Notez que cela peut également être fait en utilisant des services externes, mais c'est la manière correcte d'exposer l'application.
Si vous implémentez un Ingress, vous devrez créer des Ingress Controllers. L'Ingress Controller est un pod qui sera le point de terminaison qui recevra les requêtes et les vérifiera et les équilibrera vers les services. L'Ingress Controller enverra la requête en fonction des règles d'ingress configurées. Notez que les règles d'ingress peuvent pointer vers différents chemins ou même des sous-domaines vers différents services Kubernetes internes.
Une meilleure pratique de sécurité serait d'utiliser un équilibreur de charge cloud ou un serveur proxy comme point d'entrée pour ne pas avoir de partie du cluster Kubernetes exposée.
Lorsque une requête qui ne correspond à aucune règle d'ingress est reçue, l'Ingress Controller la dirigera vers le "Default backend". Vous pouvez describe l'Ingress Controller pour obtenir l'adresse de ce paramètre.
minikube addons enable ingress
CA est la racine de confiance pour tous les certificats à l'intérieur du cluster.
Permet aux composants de se valider mutuellement.
Tous les certificats du cluster sont signés par la CA.
ETCd a son propre certificat.
types :
certificat apiserver.
certificat kubelet.
certificat scheduler.
Minikube peut être utilisé pour effectuer des tests rapides sur Kubernetes sans avoir besoin de déployer un environnement Kubernetes complet. Il exécutera les processus maître et nœud sur une seule machine. Minikube utilisera VirtualBox pour exécuter le nœud. Voir ici comment l'installer.
Kubectl est l'outil en ligne de commande pour les clusters kubernetes. Il communique avec le serveur Api du processus maître pour effectuer des actions dans kubernetes ou pour demander des données.
Le tableau de bord vous permet de voir plus facilement ce que minikube exécute, vous pouvez trouver l'URL pour y accéder dans :
Chaque fichier de configuration a 3 parties : métadonnées, spécification (ce qui doit être lancé), état (état désiré). À l'intérieur de la spécification du fichier de configuration de déploiement, vous pouvez trouver le modèle défini avec une nouvelle structure de configuration définissant l'image à exécuter :
Exemple de Déploiement + Service déclarés dans le même fichier de configuration (de ici)
Comme un service est généralement lié à un déploiement, il est possible de déclarer les deux dans le même fichier de configuration (le service déclaré dans cette config n'est accessible qu'en interne) :
Exemple de configuration de service externe
Ce service sera accessible de l'extérieur (vérifiez les attributs nodePort et type: LoadBlancer) :
Ceci est utile pour les tests, mais pour la production, vous ne devriez avoir que des services internes et un Ingress pour exposer l'application.
Exemple de fichier de configuration Ingress
Cela exposera l'application à http://dashboard.com.
Exemple de fichier de configuration des secrets
Notez comment les mots de passe sont encodés en B64 (ce qui n'est pas sécurisé !)
Exemple de ConfigMap
Un ConfigMap est la configuration qui est donnée aux pods afin qu'ils sachent comment localiser et accéder à d'autres services. Dans ce cas, chaque pod saura que le nom mongodb-service est l'adresse d'un pod avec lequel ils peuvent communiquer (ce pod exécutera un mongodb) :
Ensuite, à l'intérieur d'une deployment config, cette adresse peut être spécifiée de la manière suivante afin qu'elle soit chargée dans l'env du pod :
Exemple de configuration de volume
Vous pouvez trouver différents exemples de fichiers de configuration de stockage yaml sur https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes. Notez que les volumes ne sont pas à l'intérieur des namespaces
Kubernetes prend en charge plusieurs clusters virtuels soutenus par le même cluster physique. Ces clusters virtuels sont appelés namespaces. Ils sont destinés à être utilisés dans des environnements avec de nombreux utilisateurs répartis sur plusieurs équipes ou projets. Pour les clusters avec quelques à des dizaines d'utilisateurs, vous ne devriez pas avoir besoin de créer ou de penser aux namespaces. Vous devriez commencer à utiliser les namespaces pour avoir un meilleur contrôle et une meilleure organisation de chaque partie de l'application déployée dans kubernetes.
Les namespaces fournissent un champ d'application pour les noms. Les noms des ressources doivent être uniques au sein d'un namespace, mais pas entre les namespaces. Les namespaces ne peuvent pas être imbriqués les uns dans les autres et chaque ressource Kubernetes ne peut être dans qu'un seul namespace.
Il y a 4 namespaces par défaut si vous utilisez minikube :
kube-system : Ce n'est pas destiné à l'utilisation des utilisateurs et vous ne devriez pas y toucher. C'est pour les processus master et kubectl.
kube-public : Données accessibles publiquement. Contient un configmap qui contient des informations sur le cluster.
kube-node-lease : Détermine la disponibilité d'un nœud.
default : L'espace de noms que l'utilisateur utilisera pour créer des ressources.
Notez que la plupart des ressources Kubernetes (par exemple, les pods, les services, les contrôleurs de réplication, et d'autres) se trouvent dans des espaces de noms. Cependant, d'autres ressources comme les ressources d'espace de noms et les ressources de bas niveau, telles que les nœuds et les persistenVolumes, ne se trouvent pas dans un espace de noms. Pour voir quelles ressources Kubernetes sont et ne sont pas dans un espace de noms :
Vous pouvez enregistrer l'espace de noms pour toutes les commandes kubectl suivantes dans ce contexte.
Helm est le gestionnaire de paquets pour Kubernetes. Il permet de regrouper des fichiers YAML et de les distribuer dans des dépôts publics et privés. Ces paquets sont appelés Helm Charts.
Helm est également un moteur de modèles qui permet de générer des fichiers de configuration avec des variables :
Un Secret est un objet qui contient des données sensibles telles qu'un mot de passe, un jeton ou une clé. De telles informations pourraient autrement être mises dans une spécification de Pod ou dans une image. Les utilisateurs peuvent créer des Secrets et le système crée également des Secrets. Le nom d'un objet Secret doit être un nom de sous-domaine DNS valide. Lisez ici la documentation officielle.
Les Secrets peuvent être des choses comme :
Clés API, SSH.
Jetons OAuth.
Identifiants, Mots de passe (texte brut ou b64 + chiffrement).
Informations ou commentaires.
Code de connexion à la base de données, chaînes… .
Il existe différents types de secrets dans Kubernetes
| Type intégré | Utilisation |
|---|---|
Opaque | données arbitraires définies par l'utilisateur (par défaut) |
kubernetes.io/service-account-token | jeton de compte de service |
kubernetes.io/dockercfg | fichier ~/.dockercfg sérialisé |
kubernetes.io/dockerconfigjson | fichier ~/.docker/config.json sérialisé |
kubernetes.io/basic-auth | identifiants pour l'authentification de base |
kubernetes.io/ssh-auth | identifiants pour l'authentification SSH |
kubernetes.io/tls | données pour un client ou un serveur TLS |
bootstrap.kubernetes.io/token | données de jeton de démarrage |
Le type Opaque est le type par défaut, la paire clé-valeur typique définie par les utilisateurs.
Comment fonctionnent les secrets :
Le fichier de configuration suivant définit un secret appelé mysecret avec 2 paires clé-valeur username: YWRtaW4= et password: MWYyZDFlMmU2N2Rm. Il définit également un pod appelé secretpod qui aura le username et le password définis dans mysecret exposés dans les variables d'environnement SECRET_USERNAME __ et __ SECRET_PASSWOR. Il montera également le secret username à l'intérieur de mysecret dans le chemin /etc/foo/my-group/my-username avec des permissions 0640.
etcd est un magasin de valeurs-clés cohérent et hautement disponible utilisé comme magasin de support Kubernetes pour toutes les données du cluster. Accédons aux secrets stockés dans etcd :
Vous verrez où se trouvent les certs, les clés et les URL dans le FS. Une fois que vous les aurez, vous pourrez vous connecter à etcd.
Une fois que vous avez établi la communication, vous serez en mesure d'obtenir les secrets :
Ajout de l'encryption à l'ETCD
Par défaut, tous les secrets sont stockés en texte clair à l'intérieur d'etcd, à moins que vous n'appliquiez une couche d'encryption. L'exemple suivant est basé sur https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
Après cela, vous devez définir le drapeau --encryption-provider-config sur le kube-apiserver pour pointer vers l'emplacement du fichier de configuration créé. Vous pouvez modifier /etc/kubernetes/manifest/kube-apiserver.yaml et ajouter les lignes suivantes :
Faites défiler vers le bas dans les volumeMounts :
Faites défiler vers le bas dans les volumeMounts jusqu'à hostPath :
Vérification que les données sont chiffrées
Les données sont chiffrées lorsqu'elles sont écrites dans etcd. Après avoir redémarré votre kube-apiserver, tout secret nouvellement créé ou mis à jour devrait être chiffré lors de son stockage. Pour vérifier, vous pouvez utiliser le programme en ligne de commande etcdctl pour récupérer le contenu de votre secret.
Créez un nouveau secret appelé secret1 dans l'espace de noms default :
En utilisant la ligne de commande etcdctl, lisez ce secret à partir d'etcd :
ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C
où [...] doit être les arguments supplémentaires pour se connecter au serveur etcd. 3. Vérifiez que le secret stocké est préfixé par k8s:enc:aescbc:v1: ce qui indique que le fournisseur aescbc a chiffré les données résultantes. 4. Vérifiez que le secret est correctement déchiffré lorsqu'il est récupéré via l'API :
devrait correspondre à mykey: bXlkYXRh, mydata est encodé, consultez décoder un secret pour décoder complètement le secret.
Puisque les secrets sont chiffrés à l'écriture, effectuer une mise à jour sur un secret chiffrera ce contenu :
Conseils finaux :
Essayez de ne pas garder de secrets dans le FS, obtenez-les d'autres endroits.
Consultez https://www.vaultproject.io/ pour ajouter plus de protection à vos secrets.
Apprenez et pratiquez le Hacking AWS :HackTricks Training AWS Red Team Expert (ARTE) Apprenez et pratiquez le Hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)
