Comment le cluster Kubernetes de production de Cybernetics répond à l'OWASP Kubernetes Security Cheat Sheet : chaque recommandation qui s'applique à notre cluster, son statut et le mécanisme qui l'applique.

Bon à savoir

Cette page est une autoévaluation de Cybernetics au regard de l'OWASP Kubernetes Security Cheat Sheet. Elle ne constitue ni une certification ni une déclaration de conformité intégrale. Elle couvre les 57 recommandations qui relèvent de Cybernetics ; les composants du plan de contrôle sont gérés par OVHcloud (voir la section 8). La colonne Mécanisme nomme la règle qui applique la recommandation : une policy Kyverno en mode Enforce, qui refuse à l'admission toute ressource non conforme, ou l'outil indiqué. Les écarts connus sont listés en fin de page.

Aller à · Couverture par thème · 1. Sécurité des conteneurs · 2. Images et chaîne d'approvisionnement · 3. Réseau · 4. Secrets et identifiants · 5. RBAC et authentification · 6. Pod Security Admission et namespaces · 7. Observabilité et exécution · 8. Plan de contrôle et nœuds · Écarts connus

Couverture par thème

Thème	Points	En place	Pas encore
Sécurité des conteneurs	12	12	0
Images et chaîne d'approvisionnement	8	8	0
Réseau	7	7	0
Secrets et identifiants	7	5	2
RBAC et authentification	10	10	0
Pod Security Admission et namespaces	4	4	0
Observabilité et exécution	5	3	2
Plan de contrôle et nœuds	4	4	0
Total	57	53	4

1. Sécurité des conteneurs

Recommandation OWASP	Statut	Mécanisme (enforce)
`runAsNonRoot: true`	✅	`require-nonroot-user`
`allowPrivilegeEscalation: false`	✅	`disallow-privilege-escalation`
`readOnlyRootFilesystem: true`	✅	`require-readonly-rootfs`
`capabilities.drop: [ALL]`	✅	`require-drop-all-capabilities`
Capabilities dangereuses bloquées	✅	`audit-dangerous-capabilities`
`privileged: false`	✅	`disallow-privileged-containers`
Pas de `hostPID` / `hostIPC` / `hostNetwork`	✅	`disallow-host-namespaces`
Pas de volumes `hostPath`	✅	`disallow-hostpath-volumes`
Seccomp `RuntimeDefault`	✅	`require-seccomp-profile`
Resource limits (anti-DoS)	✅	`require-resource-limits`
Profil AppArmor	✅	`require-apparmor-profile`
Pas de workload dans le namespace default	✅	`disallow-default-namespace`

Quelques composants système (maintenance des nœuds, composants éditeurs) bénéficient de dérogations documentées, justifiées et revues périodiquement.

2. Images et chaîne d'approvisionnement

Recommandation OWASP	Statut	Mécanisme (enforce)
Images depuis un registry de confiance	✅	`restrict-image-registry`
Immutabilité des images (digest SHA-256)	✅	`require-image-digest`
Scan des dépendances	✅	Dependabot et Datadog
Secrets scanning (CI/CD)	✅	Gitleaks
Signature des images (Cosign)	✅	verify-image-signatures : signature keyless par GitHub Actions (OIDC), vérifiée par Kyverno en Enforce sur toutes les images du registry miroir. L'attestation de provenance SLSA est produite et vérifiable hors cluster.
Images de base minimales, sans shell ni gestionnaire de paquets	✅	Docker Hardened Images, utilisateur non root
Scan des images avant déploiement, blocage sur CVE critique	✅	Grype dans le pipeline de mirroring, nouveau scan chaque semaine
Scan continu des images en production	✅	Datadog SBOM et SCA

3. Réseau

Recommandation OWASP	Statut	Mécanisme (enforce)
NetworkPolicy deny-all par défaut	✅	`generate-default-deny-netpol`
Vérifier l'existence de NetworkPolicies	✅	`require-network-policy`
Pas de NodePort / LoadBalancer (hors point d'entrée unique, restreint aux adresses Cloudflare)	✅	`disallow-nodeport-loadbalancer`
TLS obligatoire sur les Ingress	✅	`require-ingress-tls`
WAF / exposition contrôlée	✅	Cloudflare Zero Trust Tunnel + WAF
Reverse proxy unique	✅	Traefik
mTLS Cloudflare vers l'origine sur tout Ingress public	✅	`require-cloudflare-origin-pull`

4. Secrets et identifiants

Recommandation OWASP	Statut	Mécanisme (enforce)
Gestionnaire de secrets externe	✅	ESO, OKMS OVHcloud
Pas de Secrets K8s manuels	✅	`disallow-secret-without-eso`
Pas de secrets dans les ConfigMaps	✅	`detect-configmap-sensitive-data`
`automountServiceAccountToken: false`	✅	`require-automount-false`
Un namespace ne lit que ses propres clés OKMS	✅	`restrict-eso-keys`
Chiffrement au repos (etcd)	❌	OVHcloud MKS avec chiffrement etcd (à planifier)
Secrets montés en volume plutôt qu'en variables d'environnement	❌	Les secrets applicatifs sont injectés en variables d'environnement depuis ESO (à planifier)

5. RBAC et authentification

Recommandation OWASP	Statut	Mécanisme (enforce)
Pas de `cluster-admin` pour les workloads	✅	`disallow-cluster-admin-binding`
Pas de permissions wildcard (`*`)	✅	`disallow-wildcard-roles`
Pas d'accès anonyme	✅	`disallow-anonymous-access`
Moindre privilège (RBAC granulaire)	✅	Policies RBAC et ServiceAccounts dédiés par namespace
Pas de verbe proxy (pods, services, nodes)	✅	`disallow-proxy-verb`
Pas d'exec / attach / port-forward par RBAC	✅	`disallow-interactive-pod-access-rbac`
CI/CD limitée à ses propres ressources	✅	`restrict-ci-cd-web-scope`
Dérogations tracées (propriétaire, date de revue)	✅	`require-policy-exception-review`
Authentification externe (OIDC), MFA anti-hameçonnage pour les administrateurs	✅	OIDC Entra ID sur OVHcloud MKS, accès conditionnel Entra ID
Tableau de bord non exposé directement, authentifié et en lecture seule	✅	Headlamp derrière Cloudflare Tunnel et Access (Entra ID), ServiceAccount en lecture sans accès aux Secrets

6. Pod Security Admission et namespaces

Recommandation OWASP	Statut	Mécanisme
Labels PSA `restricted` sur les namespaces	✅	`mutate-namespace-labels` (Mutate)
PSS niveau restricted sur les namespaces applicatifs et d'infrastructure	✅	Labels PSA injectés automatiquement. La sauvegarde (Kasten) reste en baseline, dérogation documentée.
StorageClass restreinte	✅	`restrict-pvc-storageclass`
Quotas de ressources par namespace (ResourceQuota, LimitRange)	✅	Budgets de ressources par namespace applicatif

7. Observabilité et exécution

Recommandation OWASP	Statut	Mécanisme
Runtime threat detection	✅	Datadog ASM (threats + IAST + SCA) + CWS
Logs des conteneurs centralisés	✅	Datadog Log Management
Supervision du trafic réseau entre pods	✅	Datadog Network Performance Monitoring
Audit logs kube-apiserver	❌	Non activé à ce jour : les journaux d'audit du plan de contrôle sont gérés par OVHcloud MKS et leur transfert n'est pas encore configuré
Container sandboxing	❌	Non implémenté : les nœuds MKS standard utilisent containerd sans runtime d'isolation renforcée

8. Plan de contrôle et nœuds

Recommandation OWASP	Statut	Mécanisme
Accès à l'API Kubernetes restreint à des adresses de confiance	✅	Restriction IP OVHcloud MKS
Version de Kubernetes maintenue à jour	✅	OVHcloud MKS 1.35
Durcissement des nœuds (CIS, modules noyau inutiles désactivés)	✅	DaemonSet node-hardening
Correctifs système des nœuds appliqués automatiquement	✅	unattended-upgrades et Kured (redémarrage orchestré)

Responsabilité partagée

Le plan de contrôle est géré par OVHcloud : etcd et son chiffrement en transit, ports du plan de contrôle, authentification des kubelets et rotation de leurs certificats. Ces points ne sont pas comptés ci-dessus.

Écarts connus

4 recommandations ne sont pas encore en place :

Chiffrement au repos (etcd) : à planifier, avec le chiffrement etcd proposé par OVHcloud MKS ;
Audit logs kube-apiserver : les journaux d'audit du plan de contrôle sont gérés par OVHcloud MKS et leur transfert n'est pas encore configuré ;
Container sandboxing : les nœuds MKS standard utilisent containerd, sans runtime d'isolation renforcée ;
Secrets en variables d'environnement : les secrets applicatifs sont injectés en variables d'environnement ; le passage en volumes montés en lecture seule est à planifier.

Les trois premiers points dépendent en partie de l'offre Kubernetes managée d'OVHcloud ; ils sont suivis et cette page est mise à jour à chaque évolution.

Articles liés

Une question ? Nous contacter.