# Renforcement de Kubernetes

{{#include ../../../banners/hacktricks-training.md}}

## Outils pour analyser un cluster

### [**Kubescape**](https://github.com/armosec/kubescape)

[**Kubescape**](https://github.com/armosec/kubescape) est un outil open-source K8s fournissant une vue unique multi-cloud K8s, incluant l'analyse des risques, la conformité de sécurité, un visualiseur RBAC et le scan des vulnérabilités d'image. Kubescape analyse les clusters K8s, les fichiers YAML et les charts HELM, détectant les erreurs de configuration selon plusieurs cadres (comme le [NSA-CISA](https://www.armosec.io/blog/kubernetes-hardening-guidance-summary-by-armo), [MITRE ATT\&CK®](https://www.microsoft.com/security/blog/2021/03/23/secure-containerized-environments-with-updated-threat-matrix-for-kubernetes/)), les vulnérabilités logicielles et les violations RBAC (contrôle d'accès basé sur les rôles) aux premières étapes du pipeline CI/CD, calcule instantanément le score de risque et montre les tendances de risque au fil du temps.
```bash
kubescape scan --verbose
```
### [**Kube-bench**](https://github.com/aquasecurity/kube-bench)

L'outil [**kube-bench**](https://github.com/aquasecurity/kube-bench) est un outil qui vérifie si Kubernetes est déployé de manière sécurisée en exécutant les vérifications documentées dans le [**CIS Kubernetes Benchmark**](https://www.cisecurity.org/benchmark/kubernetes/).\
Vous pouvez choisir de :

- exécuter kube-bench depuis un conteneur (partageant l'espace de noms PID avec l'hôte)
- exécuter un conteneur qui installe kube-bench sur l'hôte, puis exécuter kube-bench directement sur l'hôte
- installer les derniers binaires depuis la [page des Releases](https://github.com/aquasecurity/kube-bench/releases),
- le compiler à partir des sources.

### [**Kubeaudit**](https://github.com/Shopify/kubeaudit)

L'outil [**kubeaudit**](https://github.com/Shopify/kubeaudit) est un outil en ligne de commande et un package Go pour **auditer les clusters Kubernetes** pour diverses préoccupations de sécurité.

Kubeaudit peut détecter s'il s'exécute dans un conteneur dans un cluster. Si c'est le cas, il essaiera d'auditer toutes les ressources Kubernetes dans ce cluster :
```
kubeaudit all
```
Cet outil a également l'argument `autofix` pour **corriger automatiquement les problèmes détectés.**

### [**Kube-hunter**](https://github.com/aquasecurity/kube-hunter)

L'outil [**kube-hunter**](https://github.com/aquasecurity/kube-hunter) recherche des faiblesses de sécurité dans les clusters Kubernetes. L'outil a été développé pour accroître la sensibilisation et la visibilité des problèmes de sécurité dans les environnements Kubernetes.
```bash
kube-hunter --remote some.node.com
```
### [**Kubei**](https://github.com/Erezf-p/kubei)

[**Kubei**](https://github.com/Erezf-p/kubei) est un outil de scan de vulnérabilités et de référence CIS Docker qui permet aux utilisateurs d'obtenir une évaluation des risques précise et immédiate de leurs clusters Kubernetes. Kubei scanne toutes les images utilisées dans un cluster Kubernetes, y compris les images des pods d'application et des pods système.

### [**KubiScan**](https://github.com/cyberark/KubiScan)

[**KubiScan**](https://github.com/cyberark/KubiScan) est un outil pour scanner les clusters Kubernetes à la recherche de permissions risquées dans le modèle d'autorisation basé sur les rôles (RBAC) de Kubernetes.

### [Managed Kubernetes Auditing Toolkit](https://github.com/DataDog/managed-kubernetes-auditing-toolkit)

[**Mkat**](https://github.com/DataDog/managed-kubernetes-auditing-toolkit) est un outil conçu pour tester d'autres types de vérifications à haut risque par rapport aux autres outils. Il dispose principalement de 3 modes différents :

- **`find-role-relationships`** : Qui trouvera quels rôles AWS s'exécutent dans quels pods
- **`find-secrets`** : Qui essaie d'identifier des secrets dans les ressources K8s telles que les Pods, ConfigMaps et Secrets.
- **`test-imds-access`** : Qui essaiera d'exécuter des pods et d'accéder aux métadonnées v1 et v2. AVERTISSEMENT : Cela exécutera un pod dans le cluster, soyez très prudent car vous ne voudrez peut-être pas faire cela !

## **Audit IaC Code**

### [**Popeye**](https://github.com/derailed/popeye)

[**Popeye**](https://github.com/derailed/popeye) est un utilitaire qui scanne un cluster Kubernetes en direct et **signale les problèmes potentiels avec les ressources et configurations déployées**. Il assainit votre cluster en fonction de ce qui est déployé et non de ce qui est stocké sur le disque. En scannant votre cluster, il détecte les erreurs de configuration et vous aide à vous assurer que les meilleures pratiques sont en place, évitant ainsi de futurs maux de tête. Il vise à réduire la charge cognitive à laquelle on fait face lors de l'exploitation d'un cluster Kubernetes dans la nature. De plus, si votre cluster utilise un serveur de métriques, il signale les allocations de ressources excessives ou insuffisantes et tente de vous avertir si votre cluster manque de capacité.

### [**KICS**](https://github.com/Checkmarx/kics)

[**KICS**](https://github.com/Checkmarx/kics) trouve **des vulnérabilités de sécurité**, des problèmes de conformité et des erreurs de configuration d'infrastructure dans les **solutions Infrastructure as Code suivantes** : Terraform, Kubernetes, Docker, AWS CloudFormation, Ansible, Helm, Microsoft ARM et spécifications OpenAPI 3.0.

### [**Checkov**](https://github.com/bridgecrewio/checkov)

[**Checkov**](https://github.com/bridgecrewio/checkov) est un outil d'analyse de code statique pour l'infrastructure en tant que code.

Il scanne l'infrastructure cloud provisionnée à l'aide de [Terraform](https://terraform.io), du plan Terraform, de [Cloudformation](https://aws.amazon.com/cloudformation/), de [AWS SAM](https://aws.amazon.com/serverless/sam/), de [Kubernetes](https://kubernetes.io), de [Dockerfile](https://www.docker.com), de [Serverless](https://www.serverless.com) ou de [ARM Templates](https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/overview) et détecte les erreurs de configuration de sécurité et de conformité à l'aide d'un scan basé sur des graphes.

### [**Kube-score**](https://github.com/zegl/kube-score)

[**kube-score**](https://github.com/zegl/kube-score) est un outil qui effectue une analyse de code statique de vos définitions d'objets Kubernetes.

Pour installer :

| Distribution                                        | Commande / Lien                                                                          |
| --------------------------------------------------- | --------------------------------------------------------------------------------------- |
| Binaries préconstruits pour macOS, Linux et Windows | [GitHub releases](https://github.com/zegl/kube-score/releases)                          |
| Docker                                              | `docker pull zegl/kube-score` ([Docker Hub)](https://hub.docker.com/r/zegl/kube-score/) |
| Homebrew (macOS et Linux)                          | `brew install kube-score`                                                               |
| [Krew](https://krew.sigs.k8s.io/) (macOS et Linux) | `kubectl krew install score`                                                            |

## Conseils

### Kubernetes PodSecurityContext et SecurityContext

Vous pouvez configurer le **contexte de sécurité des Pods** (avec _PodSecurityContext_) et des **conteneurs** qui vont être exécutés (avec _SecurityContext_). Pour plus d'informations, lisez :

{{#ref}}
kubernetes-securitycontext-s.md
{{#endref}}

### Durcissement de l'API Kubernetes

Il est très important de **protéger l'accès au serveur API Kubernetes** car un acteur malveillant disposant de privilèges suffisants pourrait en abuser et endommager l'environnement de plusieurs manières.\
Il est important de sécuriser à la fois l'**accès** (**whitelist** des origines pour accéder au serveur API et refuser toute autre connexion) et l'**authentification** (suivant le principe du **moindre** **privilège**). Et surtout **ne jamais** **autoriser** **les** **requêtes** **anonymes**.

**Processus de demande commun :**\
Utilisateur ou K8s ServiceAccount –> Authentification –> Autorisation –> Contrôle d'admission.

**Conseils** :

- Fermez les ports.
- Évitez l'accès anonyme.
- NodeRestriction ; Pas d'accès depuis des nœuds spécifiques à l'API.
- [https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction)
- Cela empêche essentiellement les kubelets d'ajouter/supprimer/mettre à jour des étiquettes avec un préfixe node-restriction.kubernetes.io/. Ce préfixe d'étiquette est réservé aux administrateurs pour étiqueter leurs objets Node à des fins d'isolement des charges de travail, et les kubelets ne seront pas autorisés à modifier les étiquettes avec ce préfixe.
- Et aussi, permet aux kubelets d'ajouter/supprimer/mettre à jour ces étiquettes et préfixes d'étiquettes.
- Assurez-vous avec des étiquettes de l'isolement sécurisé des charges de travail.
- Évitez que des pods spécifiques n'accèdent à l'API.
- Évitez l'exposition de l'ApiServer à Internet.
- Évitez l'accès non autorisé RBAC.
- Port de l'ApiServer avec pare-feu et liste blanche d'IP.

### Durcissement de SecurityContext

Par défaut, l'utilisateur root sera utilisé lorsqu'un Pod est démarré si aucun autre utilisateur n'est spécifié. Vous pouvez exécuter votre application dans un contexte plus sécurisé en utilisant un modèle similaire à celui-ci :
```yaml
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
volumes:
- name: sec-ctx-vol
emptyDir: {}
containers:
- name: sec-ctx-demo
image: busybox
command: [ "sh", "-c", "sleep 1h" ]
securityContext:
runAsNonRoot: true
volumeMounts:
- name: sec-ctx-vol
mountPath: /data/demo
securityContext:
allowPrivilegeEscalation: true
```
- [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
- [https://kubernetes.io/docs/concepts/policy/pod-security-policy/](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)

### Renforcement Général

Vous devez mettre à jour votre environnement Kubernetes aussi souvent que nécessaire pour avoir :

- Dépendances à jour.
- Correctifs de bogues et de sécurité.

[**Cycles de publication**](https://kubernetes.io/docs/setup/release/version-skew-policy/) : Chaque 3 mois, il y a une nouvelle version mineure -- 1.20.3 = 1(Majeur).20(Minor).3(patch)

**La meilleure façon de mettre à jour un Cluster Kubernetes est (depuis** [**ici**](https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade/)**) :**

- Mettre à niveau les composants du nœud maître en suivant cette séquence :
- etcd (toutes les instances).
- kube-apiserver (tous les hôtes du plan de contrôle).
- kube-controller-manager.
- kube-scheduler.
- cloud controller manager, si vous en utilisez un.
- Mettre à niveau les composants du nœud de travail tels que kube-proxy, kubelet.

{{#include ../../../banners/hacktricks-training.md}}
