https://teknolabs.net/courses/devops-cloud/partie-6-securite-plateforme/index.html Chiffrer les échanges, gérer les identités, durcir le cluster et sortir les secrets des manifests. TP Outil(s) Approche TP16 cert-manager, Keycloak HTTPS avec une CA de lab, IAM : OIDC, rôles, oauth2-proxy TP17 RBAC, PSS, NetworkPolicy, Kyverno, Falco Sécurité Kubernetes en profondeur, Policy as Code, analyse continue et détection à l’exécution TP18 Vault, External Secrets, Sealed Secrets Gestion des secrets : coffre-fort, synchronisation, chiffrement pour Git, rotation Prérequis : Cluster du TP14 et chart du TP15 ; le TP18 utilise aussi Floci (TP13). Hugo en-us https://teknolabs.net/courses/devops-cloud/partie-6-securite-plateforme/tp16-https-keycloak/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://teknolabs.net/courses/devops-cloud/partie-6-securite-plateforme/tp16-https-keycloak/index.html Deux briques transverses de toute plateforme : le chiffrement des échanges (HTTPS, certificats renouvelés automatiquement par cert-manager) et la gestion des identités et des accès (IAM) avec Keycloak, fournisseur d’identité open source qui implémente OAuth 2.0 et OpenID Connect. Sans nom de domaine public, Let’s Encrypt est impossible : vous créez votre propre autorité de certification de lab, comme le font les entreprises pour leurs services internes. Fichiers de départ : manifests.zip https://teknolabs.net/courses/devops-cloud/partie-6-securite-plateforme/tp17-kubernetes-security/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://teknolabs.net/courses/devops-cloud/partie-6-securite-plateforme/tp17-kubernetes-security/index.html Un cluster Kubernetes installé « par défaut » est permissif : tout Pod peut joindre tous les autres, un conteneur peut tourner en root ou en mode privileged, n’importe quelle image peut être déployée. Ce TP applique la défense en profondeur à une petite application volontairement mal configurée : identité et permissions (RBAC), durcissement des Pods (securityContext, Pod Security Standards), segmentation réseau (NetworkPolicy), règles d’admission (Policy as Code avec Kyverno), puis surveillance continue (Trivy Operator, Kubescape, Falco). https://teknolabs.net/courses/devops-cloud/partie-6-securite-plateforme/tp18-secrets-vault/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://teknolabs.net/courses/devops-cloud/partie-6-securite-plateforme/tp18-secrets-vault/index.html Un Secret Kubernetes n’est qu’un objet encodé en base64 : quiconque peut lire les Secrets du namespace ou accéder à etcd voit les valeurs, et on ne peut pas le versionner dans Git. Ce TP présente les trois approches courantes pour faire mieux : un coffre-fort central (HashiCorp Vault) synchronisé vers Kubernetes par External Secrets Operator, des secrets chiffrés versionnables (Sealed Secrets), et la rotation des secrets sans redéploiement manuel.