Applique un socle de sécurité Kubernetes et cloud workload

L’idée reçue

« Un namespace et une NetworkPolicy suffisent à sécuriser un workload Kubernetes. »

Admission, identité, Pod, image, réseau, secret, API et rollback doivent être cohérents.

01Applique le profil Restricted

column -s, -t "$lab/source/kubernetes/namespaces.csv"

Les namespaces applicatifs déclarent restricted pour enforce, audit et warn. Le profil réduit les escalades connues, mais ne remplace pas les contrôles d’image, réseau ou identité.

02Durcis le Pod

column -s, -t "$lab/source/kubernetes/workloads.csv"

Les workloads exigent non-root, aucune élévation, aucune capacité, seccomp RuntimeDefault, filesystem en lecture seule, aucun namespace hôte, aucun hostPath et des ressources définies.

03Réduis l’identité

column -s, -t "$lab/source/kubernetes/service-accounts.csv"

Chaque application utilise un service account dédié. Le token n’est pas monté automatiquement. Le RBAC représenté reste borné au besoin.

04Commence par default deny

column -s, -t "$lab/source/kubernetes/network-policies.csv"

Chaque namespace possède un refus ingress et egress, puis des règles explicites pour DNS et les flux métier.

Une politique restrictive qui casse DNS ou le chemin web–API–base reste invalide.

05Référence les secrets

column -s, -t "$lab/source/kubernetes/secret-references.csv"

Les fixtures contiennent seulement des références. value_present=false est obligatoire. La CI ne démontre pas le chiffrement, la rotation ou le contrôle d’accès réel.

06Analyse les refus

awk -F, '$1=="NEG-08" || $1=="NEG-09" || $1=="NEG-10"' "$lab/output/negative-test-report.csv"

Les cas bloquent Pod privilégié, namespace incompatible, absence de default deny, DNS cassé, service account trop large, valeur de secret inline ou rollback manquant.

07Vérifie la fonction représentée

column -s, -t "$lab/output/kubernetes-hardening-review.csv"
column -s, -t "$lab/output/network-policy-review.csv"

La CI prouve la cohérence des déclarations. Un cluster autorisé doit encore vérifier admission, création des Pods, connexions permises et refusées, DNS, API et restauration.

08Rends la décision

cat "$lab/output/final-decision.txt"

La décision reste NETWORK_WORKLOAD_HARDENING_WITH_ACTIONS tant qu’OPNsense, WireGuard, endpoints, runtime et Kubernetes n’ont pas été observés réellement.

09Vérifie le rollback synthétique

cmp "$lab/output/rollback-manifest-before.csv" \
    "$lab/output/rollback-manifest-restored.csv"
cat "$lab/output/rollback-report.txt"

L’égalité démontre seulement le retour des fixtures.

10Nettoie

bash module5-opnsense-wireguard-workloads.sh validate "$lab"
bash module5-opnsense-wireguard-workloads.sh reset "$lab"
test ! -e "$lab"

Évaluation du Lot 5

Défends le socle réseau et workload

Présente matrice de flux, politique OPNsense, management WireGuard, endpoints, conteneurs, Kubernetes, dix refus, tests fonctionnels, exceptions et rollback. Indique précisément les preuves manquantes.

✓Lot 5 terminé

Tu sais construire un socle cohérent du pare-feu au workload, avec flux minimaux, administration séparée, privilèges réduits, politiques réseau et preuve réversible.