Service Mesh et politique de trafic

1) Pourquoi avez-vous besoin de Service Mesh

• Sécurité par défaut : mTLS, émission/rotation automatique des certificats, identité des services.
• Politique de trafic : routage L7, tests Canaries/AV, dégradation et résilience.
• Observabilité : métriques, logs, traces, signaux dorés à chaque appel.
• Opérations : règles uniques pour toutes les langues/cadres.

Différence avec la passerelle API : la passerelle est le périmètre nord-sud ; mesh - est-ouest au sein du cluster/de l'organisation. Ils travaillent souvent ensemble.

2) Architecture : Plans et modèles

Data Plane : un proxy sidecar (Envoy/Linkerd-proxy/haproxy) interceptant le trafic pod/VM.
Control Plane : distribue les configurations (itinéraires, politiques, certificats), stocke l'état, publie le service-discovery.
Identité : généralement SPIFFE ID et certificats automatiques X.509 (SPIRE/CA intégré).
Points d'entrée/sortie : ingress/egress-gateway pour contrôler les flux frontaliers.
Modes de mise en œuvre : sidecar pour chaque sous ; Mode nœud/ambient dans les nouvelles implémentations.

3) Politique de sécurité et zero-trust

1. mTLS by default : chiffrement et authentification mutuelle des servis↔servis.

• AuthN : nous ne faisons confiance qu'aux identités délivrées par CA mesh'a (SPIFFE).
• AuthZ : règles déclaratives « qui peut vers qui et comment » (RBAC/ABAC).

3. Isolation et contrôle egress :

• Domaines/sous-réseaux autorisés ; sortie forcée via egress-gateway.
• Verrouillage des sorties directes des pods.

4. Rotation des secrets : certificats à courte durée de vie, reconfiguration automatique du proxy.

yaml apiVersion: security. istio. io/v1beta1 kind: PeerAuthentication metadata: { name: default, namespace: istio-system }
spec:
mtls: { mode: STRICT }

yaml apiVersion: security. istio. io/v1beta1 kind: AuthorizationPolicy metadata: { name: billing-allow, namespace: prod }
spec:
selector: { matchLabels: { app: billing } }
rules:
- from:
- source: { principals: ["spiffe://corp. local/ns/prod/sa/inventory"] }
to:
- operation: { ports: ["8080"], methods: ["POST"], paths: ["/proto. Billing/"] }

4) Politique de trafic : résilience et routage

4. 1 Temps et retraits

Timeouts : ils sont obligatoirement appelés (connect/read/overall).
Retries : uniquement pour les opérations idempotentes ; backoff + gitter ; limites per-try timeout.

yaml apiVersion: networking. istio. io/v1beta1 kind: VirtualService metadata: { name: orders }
spec:
hosts: ["orders"]
http:
- route:
- destination: { host: orders, subset: v1, port: { number: 8080 } }
timeout: 5s retries:
attempts: 2 perTryTimeout: 2s retryOn: "5xx,connect-failure,reset"

4. 2 Circuit Breaker и outlier detection

CB : limite les requêtes/connexions simultanées en protégeant les aptrimes.
Outlier : jette les « mauvaises » instances sur les erreurs/latence.

yaml apiVersion: networking. istio. io/v1beta1 kind: DestinationRule metadata: { name: orders }
spec:
host: orders trafficPolicy:
connectionPool:
http: { http1MaxPendingRequests: 1024, maxRequestsPerConnection: 100 }
outlierDetection:
consecutive5xxErrors: 5 interval: 5s baseEjectionTime: 30s maxEjectionPercent: 50

4. 3 Canaries et conditions

Weighted : répartition du trafic en poids v1/v2.
Header-based : les drapeaux/cookies/tenant → être redirigés vers une nouvelle version.
Affinity Session : hachage par clé (soigneusement avec mise à l'échelle).

yaml http:
- match: [{ headers: { "x-experiment": { exact: "new" } } }]
route: [{ destination: { host: orders, subset: v2 } }]
- route:
- destination: { host: orders, subset: v1, weight: 90 }
- destination: { host: orders, subset: v2, weight: 10 }

4. 4 Fault Injection et dégradation

Injection de retard/erreur pour le test de résistance et le SLO.

yaml fault:
delay: { fixedDelay: 300ms, percentage: { value: 10 } }
abort: { httpStatus: 503, percentage: { value: 1 } }

5) Frontières réseau : ingress/egress et services externes

Ingress-gateway : le seul point d'entrée pour les clients externes dans mesh ; intégration avec WAF/OIDC/ratelimits.
Egress-gateway : sortie centrale avec liste des hôtes autorisés, inspection TLS, enregistrement de télémétrie.
ServiceEntry : déclare les SNI/host externes dans le cadre du mesh (les politiques et mTLS-origine sont applicables).

yaml apiVersion: networking. istio. io/v1beta1 kind: ServiceEntry metadata: { name: payments-external }
spec:
hosts: ["api. payments. com"]
ports: [{ number: 443, name: https, protocol: TLS }]
resolution: DNS location: MESH_EXTERNAL

6) Multi-cluster, multi-réseau et hybride

ICP/domaine fiduciaire commun : identités SPIFFE uniques entre les grappes.
Endpoint discovery : boules de services entre les régions ; priorité locale et échec.
Isolement zonal : politiques, limites et priorités per-régionales.
VM dans mesh : connectez les systèmes legacy/Stateful au proxy et aux mêmes politiques.

7) Observabilité, SLO et fonctionnement

Метрики: `requests_total`, `request_duration_ms{p50,p95,p99}`, `5xx_rate`, `retry_attempts`, `cb_state`, `mTLS_authz_denied`.
Logs d'accès : structural, avec 'traceparent', 'user/tenant', 'response _ flags'.
Tracing : Auto-injection des titres (W3C Trace Context), sample, dormant au niveau hop.
SLO : cibles pour p99/erreurs sur l'itinéraire (service→service).
Alerts : sursaut de '5xx', taille de 'reset', 'outlier _ ecriptions', dégradation de mTLS (failures de handshake).

8) Performance et coût

• Grain : inclure la politique là où elle est nécessaire ; ne pas allumer les filtres lourds partout.
• Pools : diviser les chemins (critiques/arrière-plan) en différents itinéraires et limites.
• Profilage : p99 sur les itinéraires « froids », volume de télémétrie (rate-limit logs/trajets).
• Considérez les modes ambient/sidecarless si les exigences sont prises en charge et adaptées.

9) Sécurité et conformité

Accès minimum nécessaire : autoriser explicitement les directions et les méthodes.
Polices de neimspace/tenants : limites de réseau/d'autorisation.
Rotation des clés/SA : planifiée et d'urgence ; Certificats TTL courts.
PII/secrets : masquage dans les loges/remorques ; cryptage sur fil/au repos.
Vérification : qui, quand et quelles politiques ont changé ; les aprouves en deux temps.

10) Intégration avec le niveau K8s

Les politiques mesh complètent et ne remplacent pas NetworkPolicy.
Dans ingress/egress-gateway, vous pouvez accrocher PodSecurity/PSA à un niveau inférieur.
NRA/auto-skyling : tenez compte des retraits/SV - ils changent la charge.
Plans de sortie : poids canaris via VirtualService + promotion automatique sur SLO.

11) Chèque de mise en œuvre

• Les limites de confiance sont définies et le STRICT mTLS est inclus.
• Y compris les politiques AuthZ : qui est à qui, sur quels ports/méthodes.
• Timeouts/retries et outlier detection sont configurés, les chemins idempotent sont définis.
• Les itinéraires canariens et le plan de rollback sont prescrits ; fault-injection - seulement dans le non-prod.
• Les dépendances externes par l'intermédiaire d'egress-gateway et de ServiceEntry ont été établies.
• Les métriques, les logs, les pistes sont configurés ; Dashboards et alertes sur le p99/5xx/CB.
• Des quotas/limites per-tenant/namespace sont prévus.
• runbooks préparés : fuite du certificat, défaillance du CA, dégradation de l'apstream, 503/RESET de masse.
• Plan multi-cluster (ICP commune, priorités locales, scénarios DR).
• Jours de test (game days) : chute de control plane, stop sidecar, rupture du réseau, apstrym « toxique ».

12) Anti-modèles

Mesh « partout et à la fois » sans inventaire des itinéraires et SLO → une complexité coûteuse.
Retraits par défaut pour toutes les méthodes de → des effets et avalanche de trafic.
Le mTLS désactivé « temporairement » reste → pour toujours.
Egress sans passerelle → fuite de données/dépendances non comptabilisées.
Une politique mondiale pour tous les services → la fausse sécurité et les faux positifs.
Zéro observabilité : ont inclus mesh, mais ne collectons pas de métriques/tracés - nous perdons tout sens.

13) Recettes rapides

Linkerd : activer mTLS et politique par serveur

yaml apiVersion: policy. linkerd. io/v1beta1 kind: Server metadata: { name: billing, namespace: prod }
spec:
podSelector: { matchLabels: { app: billing } }
port: 8080 apiVersion: policy. linkerd. io/v1beta1 kind: ServerAuthorization metadata: { name: billing-allow-inventory, namespace: prod }
spec:
server: { name: billing }
client:
meshTLS:
identities: ["inventory. prod. serviceaccount. identity. linkerd. cluster. local"]

Consul (L7 intent + splitter)

hcl
Kind = "service-router"
Name = "orders"
Routes = [{
Match { HTTP { PathPrefix = "/v1" } }
Destination { Service = "orders" }
}]
Kind = "service-splitter"
Name = "orders"
Splits = [
{ Weight = 90, ServiceSubset = "v1" },
{ Weight = 10, ServiceSubset = "v2" }
]

14) FAQ

Une petite équipe a-t-elle besoin d'un mesh ?
Si 3-5 services - plus souvent pas. Commencez par une bonne ingress et des bibliothèques de durabilité. Connectez mesh lorsque vous avez besoin de mTLS par défaut, de stratégies uniques et de traçage sans modifier le code.

Comment contrôler le coût ?
Mesurez les bordereaux de voiture (CPU/RAM/latency) sur les chemins critiques, désactivez les filtres superflus, réduisez le volume de trajets, utilisez les modes sans sidecar là où c'est sûr.

Puis-je interférer avec des proxy configurés manuellement et mesh ?
Oui, mais éviter le double routage/retraits en double. Un seul endroit est vrai - control plane.

Qu'est-ce qui est plus important : sécurité ou performance ?
La sécurité par défaut est la sécurité (mTLS, AuthZ). Les performances sont obtenues en tuning connection pools, outlier detection, les itinéraires cibles.

15) Résultats

Service Mesh transforme le réseau entre les services en une couche programmable avec des politiques uniques : cryptage et identités, routage fin et résilience, télémétrie et quotas. Commencez par les chemins critiques, activez STRICT mTLS et AuthZ explicite, définissez les délais/retraits/SV, contrôlez l'egress, mesurez p99 et 5xx, passez les jours de jeu. Alors mesh deviendra un amplificateur de la fiabilité et de la vitesse des sorties, pas une source de surprise.