Français - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Kubernetes Basics

Bases de Kubernetes

Soutenez HackTricks

L'auteur original de cette page est Jorge (lisez son post original ici)

Architecture et bases

Que fait Kubernetes ?

  • Permet d'exécuter un ou des conteneurs dans un moteur de conteneurs.

  • La planification permet d'optimiser les missions des conteneurs.

  • Garde les conteneurs en vie.

  • Permet les communications entre les conteneurs.

  • Permet les techniques de déploiement.

  • Gère des volumes d'informations.

Architecture

  • Node : système d'exploitation avec un pod ou des pods.

  • Pod : Enveloppe autour d'un conteneur ou de plusieurs conteneurs. Un pod ne devrait contenir qu'une seule application (donc généralement, un pod exécute juste 1 conteneur). Le pod est la façon dont Kubernetes abstrait la technologie des conteneurs en cours d'exécution.

  • Service : Chaque pod a une adresse IP interne 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é dans 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. Lorsqu'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 l'apiserver 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 provenant d'autres fournisseurs.

  • Conteneur Sidecar : Les conteneurs Sidecar sont les conteneurs qui doivent s'exécuter aux côtés du 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 encapsuler toutes les dépendances nécessaires à l'exécution de l'application n'importe où. Un conteneur ne fait qu'une seule chose et le fait très bien.

  • Processus maître :

  • Serveur API : C'est la façon dont les utilisateurs et les pods communiquent avec le processus maître. Seules les demandes authentifiées doivent être autorisées.

  • Ordonnanceur : L'ordonnancement consiste à s'assurer que les Pods sont associés à des nœuds pour que Kubelet puisse les exécuter. Il a suffisamment d'intelligence pour décider quel nœud a plus de ressources disponibles et attribuer le nouveau pod à celui-ci. Notez que l'ordonnanceur ne démarre pas de nouveaux pods, il communique simplement avec le processus Kubelet s'exécutant à l'intérieur du nœud, qui lancera le nouveau pod.

  • Gestionnaire de contrôleur Kube : Il vérifie les ressources comme les ensembles de réplicas ou les déploiements pour vérifier si, par exemple, le bon nombre de pods ou de nœuds est en cours d'exécution. En cas de pod manquant, il communiquera avec l'ordonnanceur pour en démarrer un nouveau. Il contrôle la réplication, les jetons et les services de compte vers 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 consigné ici). Des composants comme l'Ordonnanceur ou le Gestionnaire de contrôle dépendent de ces données pour savoir quels changements se sont produits (ressources disponibles des nœuds, nombre de pods en cours d'exécution...)

  • Gestionnaire de contrôleur Cloud : C'est le contrôleur spécifique pour les contrôles de flux et les applications, par exemple : si vous avez des clusters sur 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 à l'apiserver 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 de joindre 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 devriez utiliser un stockage distant pour que tous les pods puissent y accéder.

Autres configurations :

  • ConfigMap : Vous pouvez configurer des URL 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 informations d'identification !

  • Secret : C'est l'endroit pour stocker des données secrètes comme des mots de passe, des clés API... encodés en B64. Le pod pourra accéder à ces données pour utiliser les informations d'identification requises.

  • Déploiements : C'est là 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 Répliques (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 qui est 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 bonne façon d'exposer l'application.

  • Si vous implémentez un Ingress, vous devrez créer des Contrôleurs Ingress. Le Contrôleur Ingress est un pod qui sera le point de terminaison qui recevra les demandes, les vérifiera et les équilibrera vers les services. le contrôleur Ingress enverra la demande en fonction des règles Ingress configurées. Notez que les règles Ingress peuvent pointer vers différents chemins ou même sous-domaines vers différents services internes de Kubernetes.

  • 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 exposer une partie du cluster Kubernetes.

  • Lorsqu'une demande qui ne correspond à aucune règle Ingress est reçue, le contrôleur Ingress la dirigera vers le "Backend par défaut". Vous pouvez décrire le contrôleur Ingress pour obtenir l'adresse de ce paramètre.

  • minikube addons enable ingress

Infrastructure PKI - Autorité de certification CA :

  • 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.

Actions de base

Minikube

Minikube peut être utilisé pour effectuer certains tests rapides sur Kubernetes sans avoir besoin de déployer tout un environnement Kubernetes. 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.

$ minikube start
😄  minikube v1.19.0 on Ubuntu 20.04
✨  Automatically selected the virtualbox driver. Other choices: none, ssh
💿  Downloading VM boot image ...
> minikube-v1.19.0.iso.sha256: 65 B / 65 B [-------------] 100.00% ? p/s 0s
> minikube-v1.19.0.iso: 244.49 MiB / 244.49 MiB  100.00% 1.78 MiB p/s 2m17.
👍  Starting control plane node minikube in cluster minikube
💾  Downloading Kubernetes v1.20.2 preload ...
> preloaded-images-k8s-v10-v1...: 491.71 MiB / 491.71 MiB  100.00% 2.59 MiB
🔥  Creating virtualbox VM (CPUs=2, Memory=3900MB, Disk=20000MB) ...
🐳  Preparing Kubernetes v1.20.2 on Docker 20.10.4 ...
▪ Generating certificates and keys ...
▪ Booting up control plane ...
▪ Configuring RBAC rules ...
🔎  Verifying Kubernetes components...
▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  Enabled addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by defaul

$ minikube status
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

---- ONCE YOU HAVE A K8 SERVICE RUNNING WITH AN EXTERNAL SERVICE -----
$ minikube service mongo-express-service
(This will open your browser to access the service exposed port)

$ minikube delete
🔥  Deleting "minikube" in virtualbox ...
💀  Removed all traces of the "minikube" cluster

Bases de Kubectl

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 demander des données.

kubectl version #Get client and server version
kubectl get pod
kubectl get services
kubectl get deployment
kubectl get replicaset
kubectl get secret
kubectl get all
kubectl get ingress
kubectl get endpoints

#kubectl create deployment <deployment-name> --image=<docker image>
kubectl create deployment nginx-deployment --image=nginx
#Access the configuration of the deployment and modify it
#kubectl edit deployment <deployment-name>
kubectl edit deployment nginx-deployment
#Get the logs of the pod for debbugging (the output of the docker container running)
#kubectl logs <replicaset-id/pod-id>
kubectl logs nginx-deployment-84cd76b964
#kubectl describe pod <pod-id>
kubectl describe pod mongo-depl-5fd6b7d4b4-kkt9q
#kubectl exec -it <pod-id> -- bash
kubectl exec -it mongo-depl-5fd6b7d4b4-kkt9q -- bash
#kubectl describe service <service-name>
kubectl describe service mongodb-service
#kubectl delete deployment <deployment-name>
kubectl delete deployment mongo-depl
#Deploy from config file
kubectl apply -f deployment.yml

Tableau de bord Minikube

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 :

minikube dashboard --url


🔌  Enabling dashboard ...
▪ Using image kubernetesui/dashboard:v2.3.1
▪ Using image kubernetesui/metrics-scraper:v1.0.7
🤔  Verifying dashboard health ...
🚀  Launching proxy ...
🤔  Verifying proxy health ...
http://127.0.0.1:50034/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/

Exemples de fichiers de configuration YAML

Chaque fichier de configuration a 3 parties : métadonnées, spécification (ce qui doit être lancé), état (état souhaité). À 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é dans le même fichier de configuration (à partir 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 configuration n'est accessible qu'en interne) :

apiVersion: apps/v1
kind: Deployment
metadata:
name: mongodb-deployment
labels:
app: mongodb
spec:
replicas: 1
selector:
matchLabels:
app: mongodb
template:
metadata:
labels:
app: mongodb
spec:
containers:
- name: mongodb
image: mongo
ports:
- containerPort: 27017
env:
- name: MONGO_INITDB_ROOT_USERNAME
valueFrom:
secretKeyRef:
name: mongodb-secret
key: mongo-root-username
- name: MONGO_INITDB_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: mongodb-secret
key: mongo-root-password
---
apiVersion: v1
kind: Service
metadata:
name: mongodb-service
spec:
selector:
app: mongodb
ports:
- protocol: TCP
port: 27017
targetPort: 27017

Exemple de configuration de service externe

Ce service sera accessible de l'extérieur (vérifiez les attributs nodePort et type: LoadBalancer):

---
apiVersion: v1
kind: Service
metadata:
name: mongo-express-service
spec:
selector:
app: mongo-express
type: LoadBalancer
ports:
- protocol: TCP
port: 8081
targetPort: 8081
nodePort: 30000

Ceci est utile pour les tests mais pour la production, vous devriez avoir uniquement des services internes et un Ingress pour exposer l'application.

Exemple de fichier de configuration Ingress

Cela exposera l'application sur http://dashboard.com.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: dashboard-ingress
namespace: kubernetes-dashboard
spec:
rules:
- host: dashboard.com
http:
paths:
- backend:
serviceName: kubernetes-dashboard
servicePort: 80

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é !)

apiVersion: v1
kind: Secret
metadata:
name: mongodb-secret
type: Opaque
data:
mongo-root-username: dXNlcm5hbWU=
mongo-root-password: cGFzc3dvcmQ=

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) :

apiVersion: v1
kind: ConfigMap
metadata:
name: mongodb-configmap
data:
database_url: mongodb-service

Ensuite, à l'intérieur d'une configuration de déploiement, cette adresse peut être spécifiée de la manière suivante pour être chargée à l'intérieur de l'environnement de la capsule :

[...]
spec:
[...]
template:
[...]
spec:
containers:
- name: mongo-express
image: mongo-express
ports:
- containerPort: 8081
env:
- name: ME_CONFIG_MONGODB_SERVER
valueFrom:
configMapKeyRef:
name: mongodb-configmap
key: database_url
[...]

Exemple de configuration de volume

Vous pouvez trouver différents exemples de fichiers de configuration yaml de stockage sur https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes. Notez que les volumes ne sont pas à l'intérieur des espaces de noms

Espaces de noms

Kubernetes prend en charge plusieurs clusters virtuels pris en charge par le même cluster physique. Ces clusters virtuels sont appelés espaces de noms. 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 dizaines d'utilisateurs, vous ne devriez pas avoir besoin de créer ou de penser aux espaces de noms du tout. Vous devriez commencer à utiliser les espaces de noms pour avoir un meilleur contrôle et une meilleure organisation de chaque partie de l'application déployée dans Kubernetes.

Les espaces de noms fournissent une portée pour les noms. Les noms des ressources doivent être uniques dans un espace de noms, mais pas à travers les espaces de noms. Les espaces de noms ne peuvent pas être imbriqués les uns dans les autres et chaque ressource Kubernetes ne peut être que dans un espace de noms.

Il y a 4 espaces de noms par défaut si vous utilisez minikube:

kubectl get namespace
NAME              STATUS   AGE
default           Active   1d
kube-node-lease   Active   1d
kube-public       Active   1d
kube-system       Active   1d

  • kube-system: Ce n'est pas destiné à être utilisé par les 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.

#Create namespace
kubectl create namespace my-namespace

Notez que la plupart des ressources Kubernetes (par exemple, pods, services, contrôleurs de réplication, et autres) sont dans certains espaces de noms. Cependant, d'autres ressources comme les ressources de namespace et les ressources de bas niveau, telles que les nœuds et les volumes persistants, ne sont pas dans un espace de noms. Pour voir quelles ressources Kubernetes sont et ne sont pas dans un espace de noms :

kubectl api-resources --namespaced=true #In a namespace
kubectl api-resources --namespaced=false #Not in a namespace

Vous pouvez enregistrer l'espace de noms pour toutes les commandes kubectl ultérieures dans ce contexte.

kubectl config set-context --current --namespace=<insert-namespace-name-here>

Helm

Helm est le gestionnaire de packages pour Kubernetes. Il permet de regrouper des fichiers YAML et de les distribuer dans des dépôts publics et privés. Ces packages sont appelés Helm Charts.

helm search <keyword>

Secrets Kubernetes

Un Secret est un objet qui contient des données sensibles telles qu'un mot de passe, un jeton ou une clé. Ces informations pourraient autrement être placées 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.

  • Informations d'identification, mots de passe (en texte clair ou en base64 + chiffrement).

  • Informations ou commentaires.

  • Code de connexion à une base de données, chaînes… .

Il existe différents types de secrets dans Kubernetes

Type intégréUtilisation

Opaque

données 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

informations d'identification pour l'authentification de base

kubernetes.io/ssh-auth

informations d'identification pour l'authentification SSH

kubernetes.io/tls

données pour un client ou serveur TLS

bootstrap.kubernetes.io/token

données de jeton d'amorçage

Le type Opaque est celui par défaut, la paire clé-valeur typique définie par les utilisateurs.

Fonctionnement des 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 les username et 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.

secretpod.yaml
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
---
apiVersion: v1
kind: Pod
metadata:
name: secretpod
spec:
containers:
- name: secretpod
image: nginx
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: mysecret
key: username
- name: SECRET_PASSWORD
valueFrom:
secretKeyRef:
name: mysecret
key: password
volumeMounts:
- name: foo
mountPath: "/etc/foo"
restartPolicy: Never
volumes:
- name: foo
secret:
secretName: mysecret
items:
- key: username
path: my-group/my-username
mode: 0640
kubectl apply -f <secretpod.yaml>
kubectl get pods #Wait until the pod secretpod is running
kubectl exec -it  secretpod -- bash
env | grep SECRET && cat /etc/foo/my-group/my-username && echo

Secrets in etcd

etcd est un magasin de clés-valeurs cohérent et hautement disponible utilisé comme support de stockage Kubernetes pour toutes les données du cluster. Accédons aux secrets stockés dans etcd :

cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep etcd

Vous verrez que les certificats, clés et URL sont situés dans le système de fichiers. Une fois que vous les aurez obtenus, vous pourrez vous connecter à etcd.

#ETCDCTL_API=3 etcdctl --cert <path to client.crt> --key <path to client.ket> --cacert <path to CA.cert> endpoint=[<ip:port>] health

ETCDCTL_API=3 etcdctl --cert /etc/kubernetes/pki/apiserver-etcd-client.crt --key /etc/kubernetes/pki/apiserver-etcd-client.key --cacert /etc/kubernetes/pki/etcd/etcd/ca.cert endpoint=[127.0.0.1:1234] health

Une fois que vous avez établi la communication, vous pourriez obtenir les secrets :

#ETCDCTL_API=3 etcdctl --cert <path to client.crt> --key <path to client.ket> --cacert <path to CA.cert> endpoint=[<ip:port>] get <path/to/secret>

ETCDCTL_API=3 etcdctl --cert /etc/kubernetes/pki/apiserver-etcd-client.crt --key /etc/kubernetes/pki/apiserver-etcd-client.key --cacert /etc/kubernetes/pki/etcd/etcd/ca.cert endpoint=[127.0.0.1:1234] get /registry/secrets/default/secret_02

Ajout de chiffrement à l'ETCD

Par défaut, tous les secrets sont stockés en clair à l'intérieur de etcd à moins que vous n'appliquiez une couche de chiffrement. L'exemple suivant est basé sur https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/

encryption.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
providers:
- aescbc:
keys:
- name: key1
secret: cjjPMcWpTPKhAdieVtd+KhG4NN+N6e3NmBPMXJvbfrY= #Any random key
- identity: {}

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:

containers:
- command:
- kube-apiserver
- --encriyption-provider-config=/etc/kubernetes/etcd/<configFile.yaml>

Faites défiler vers le bas dans les volumeMounts :

- mountPath: /etc/kubernetes/etcd
name: etcd
readOnly: true

Faites défiler vers le bas dans les volumeMounts vers hostPath:

- hostPath:
path: /etc/kubernetes/etcd
type: DirectoryOrCreate
name: etcd

Vérification de l'encryption des donné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é lorsqu'il est stocké. Pour vérifier, vous pouvez utiliser le programme en ligne de commande etcdctl pour récupérer le contenu de votre secret.

  1. Créez un nouveau secret appelé secret1 dans l'espace de noms default :

kubectl create secret generic secret1 -n default --from-literal=mykey=mydata

  1. En utilisant la ligne de commande etcdctl, lisez ce secret depuis etcd :

ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C

où [...] doivent ê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 :

kubectl describe secret secret1 -n default

devrait correspondre à mykey: bXlkYXRh, mydata est encodé, consultez le décodage d'un secret pour décoder complètement le secret.

Étant donné que les secrets sont chiffrés à l'écriture, toute mise à jour d'un secret chiffrera ce contenu :

kubectl get secrets --all-namespaces -o json | kubectl replace -f -

Conseils finaux :

Références

Soutenez HackTricks
PreviousKubernetes PentestingNextPentesting Kubernetes Services

Last updated