Introduction
L'architecture Zero Trust repose sur le principe « ne jamais faire confiance, toujours vérifier ». Contrairement aux modèles périmétriques, chaque requête est authentifiée et autorisée, même en interne. Ce tutoriel avancé vous guide à travers l'implémentation concrète avec Terraform, OPA et Kubernetes. Vous apprendrez à déployer des contrôles d'identité forts, du chiffrement mTLS et des politiques dynamiques. L'objectif est une posture de sécurité mesurable et automatisée, essentielle face aux menaces modernes.
Prérequis
- Kubernetes 1.28+ avec cluster géré
- Terraform 1.6+
- Connaissances solides en RBAC et identité
- Outil OPA installé
- Accès à un fournisseur OIDC (ex: Keycloak ou Auth0)
Provisionnement infrastructure sécurisée
resource "aws_vpc" "zero_trust" {
cidr_block = "10.0.0.0/16"
tags = { Name = "zero-trust-vpc" }
}
resource "aws_security_group" "zt_sg" {
vpc_id = aws_vpc.zero_trust.id
ingress {
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
}Ce code Terraform crée un VPC isolé avec un security group qui n'autorise que le trafic HTTPS entrant. Il applique le principe de moindre privilège dès la couche réseau.
Politique OPA pour autorisation stricte
package zero_trust
default allow = false
allow {
input.request.method == "GET"
input.request.path == "/api/sensitive"
token := input.request.headers["Authorization"]
jwt.verify(token, "public-key")
claims := jwt.decode(token)
claims.role == "admin"
claims.mfa_verified == true
}Cette politique Rego vérifie systématiquement le JWT, le rôle et la présence de MFA. Toute requête non conforme est rejetée par défaut.
NetworkPolicy Kubernetes
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: zero-trust-deny-all
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
ingress:
- from:
- namespaceSelector:
matchLabels:
name: kube-system
egress:
- to:
- namespaceSelector:
matchLabels:
name: monitoringCette NetworkPolicy bloque tout trafic par défaut sauf les flux explicites vers le système et le monitoring, incarnant le modèle Zero Trust au niveau du cluster.
Configuration mTLS avec Istio
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: default
spec:
mtls:
mode: STRICT
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: require-jwt
spec:
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/app-sa"]Le mode STRICT force le mTLS entre tous les pods. L'AuthorizationPolicy ajoute une couche d'identité de service, vérifiant le ServiceAccount source.
Validation de jeton en Go
package main
import (
"fmt"
"github.com/golang-jwt/jwt/v5"
)
func ValidateToken(tokenString string) (bool, error) {
key := []byte("your-secret")
token, err := jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {
return key, nil
})
if err != nil || !token.Valid {
return false, err
}
claims := token.Claims.(jwt.MapClaims)
return claims["mfa"] == true, nil
}Ce code Go valide le JWT et vérifie explicitement la revendication MFA. Il constitue le point d'entrée obligatoire pour toute requête entrante.
Bonnes pratiques
- Toujours chiffrer le trafic interne avec mTLS STRICT
- Centraliser les politiques dans OPA ou Cedar
- Journaliser chaque décision d'autorisation avec traçabilité
- Automatiser la rotation des certificats et clés
- Tester régulièrement les scénarios de compromission d'identité
Erreurs courantes à éviter
- Laisser des NetworkPolicies trop permissives (allow-all)
- Oublier de vérifier l'attribut MFA dans les tokens
- Utiliser des certificats auto-signés en production
- Ignorer la journalisation des refus d'accès
Pour aller plus loin
Approfondissez ces concepts avec nos formations expertes sur la sécurité cloud et l'architecture Zero Trust : https://learni-group.com/formations