NutriFlow — Guía mTLS Zero-Trust

🔐 1 · Flujo TLS Handshake

TLS Mutual Authentication — patients-service ↔ diet-plans-service

patients-svc

namespace: production

1

ClientHello

2

ServerHello + Cert

3

Client Cert (SPIFFE)

4

Verify Both Certs ✓

5

Encrypted Channel

diet-plans-svc

namespace: production

Jerarquía de certificados — NutriFlow PKI

Root CA (nutriflow-root-ca · 10y · offline, almacenada en GCP KMS) │ ├── Intermediate CA — cluster-prod (nutriflow-prod · 1y · cert-manager ClusterIssuer) │ │ │ ├── workload: patients-service (SPIFFE · 24h) │ ├── workload: billing-service (SPIFFE · 24h) │ ├── workload: diet-plans-service (SPIFFE · 24h) │ ├── workload: auth-service (SPIFFE · 24h) │ └── workload: [8 servicios restantes] (SPIFFE · 24h) │ └── Intermediate CA — monitoring (Prometheus/Grafana · 1y) │ └── workload: prometheus, grafana, alertmanager

📋 2 · Configuración por Namespace

Namespace	Modo mTLS	Fase	Servicios críticos	Justificación
production	STRICT	Semana 3	billing, patients, diet-plans	PII + Health data · HIPAA req.
staging	STRICT	Semana 1	todos	Ambiente de validación primero
monitoring	STRICT	Semana 2	prometheus, grafana	Métricas mTLS en puerto separado
legacy-integrations	PERMISSIVE	Mantener	webhooks, cdn-proxy	Integraciones externas legacy
istio-system	STRICT (mesh)	Semana 1	control plane	Default mesh-wide policy

⚙️ 3 · Configuraciones YAML — Istio

01-peer-authentication-mesh.yaml yaml · PeerAuthentication

# Política mesh-wide: STRICT en producción
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
  labels:
    app.kubernetes.io/managed-by: nutriflow-security
spec:
  mtls:
    mode: STRICT
---
# Override: PERMISSIVE para namespace legacy durante migración
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: legacy-integrations
spec:
  mtls:
    mode: PERMISSIVE
---
# Override específico: billing-service STRICT + métricas sin mTLS
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: billing-service
  namespace: production
spec:
  selector:
    matchLabels:
      app: billing-service
  mtls:
    mode: STRICT
  portLevelMtls:
    8080:
      mode: STRICT
    9090:                # puerto métricas Prometheus
      mode: DISABLE

02-destination-rules.yaml yaml · DestinationRule

# mTLS para todo el tráfico interno (.cluster.local)
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: default-mtls
  namespace: istio-system
spec:
  host: "*.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
---
# mTLS hacia API externa de pagos (Stripe)
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: stripe-api
  namespace: production
spec:
  host: api.stripe.com
  trafficPolicy:
    tls:
      mode: SIMPLE
      caCertificates: /etc/ssl/certs/ca-certificates.crt

03-cert-manager-issuer.yaml yaml · cert-manager ClusterIssuer

# ClusterIssuer basado en la Intermediate CA de NutriFlow
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: nutriflow-istio-ca
spec:
  ca:
    secretName: nutriflow-intermediate-ca-secret
---
# Montar la CA en Istio (cacerts secret)
# kubectl create secret generic cacerts -n istio-system \
#   --from-file=ca-cert.pem=intermediate-ca.crt \
#   --from-file=ca-key.pem=intermediate-ca.key \
#   --from-file=root-cert.pem=root-ca.crt \
#   --from-file=cert-chain.pem=cert-chain.pem

🗓️ 4 · Plan de Migración — PERMISSIVE → STRICT

1

Semana 1 · Días 1–5

Preparación y staging

Aplicar mTLS STRICT en staging completo
Configurar ClusterIssuer cert-manager con Intermediate CA
Habilitar meshConfig.accessLogFile para observabilidad
Validar handshakes con istioctl x describe pod

2

Semana 2 · Días 6–10

Production: servicios no críticos

STRICT en: auth, analytics, ml-engine, reports, search, admin-api
Aplicar monitoring namespace con puerto 9090 DISABLE
Monitorizar error rate en Kiali / Grafana (umbral < 0.1%)

3

Semana 3 · Días 11–17

Production: servicios críticos PII

STRICT en: patients, billing, diet-plans, notifications
Verificar AuthorizationPolicies + SPIFFE URIs
Ejecutar script de diagnóstico completo (ver §5)

4

Semana 4 · Días 18–21

Hardening y auditoría HIPAA

Configurar alertas cert-expiry (Prometheus AlertManager)
Documentar SPIFFE trust bundles para auditoría DACH
Eliminar modo PERMISSIVE de legacy-integrations (plan Q3)
Revisión de seguridad final con equipo compliance

🔍 5 · Scripts de Diagnóstico

check-mtls.sh bash · diagnóstico rápido

#!/bin/bash
# NutriFlow — Verificación mTLS post-migración
# Uso: ./check-mtls.sh [namespace]

NS=${1:-production}

echo "=== Verificando mTLS en namespace: $NS ==="

# 1. Estado PeerAuthentication
kubectl get peerauthentication -n "$NS"

# 2. Verificar sidecar injection
kubectl get pods -n "$NS" -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].name}{"\n"}{end}'

# 3. Describe pod para ver mTLS efectivo
for pod in $(kubectl get pods -n "$NS" -o name | head -5); do
  echo "--- $pod ---"
  istioctl x describe "$pod" -n "$NS" | grep -E "(mTLS|STRICT|PERMISSIVE|certificat)"
done

# 4. Verificar certificados workload (expiración)
for pod in $(kubectl get pods -n "$NS" -l app=billing-service -o name); do
  istioctl proxy-config secret "$pod" -n "$NS" | grep -E "(Cert|Expire)"
done

# 5. Test de conectividad entre billing ↔ patients
kubectl exec -n "$NS" deploy/billing-service -- \
  curl -sv http://patients-service.production.svc.cluster.local:8080/health \
  2>&1 | grep -E "(TLS|SSL|subject|issuer|Connected)"

✅ 6 · Checklist Post-Migración

✓

PeerAuthentication STRICT aplicada en todos los namespaces objetivo

kubectl get peerauthentication -A | grep -v PERMISSIVE
✓

DestinationRules ISTIO_MUTUAL configuradas mesh-wide

kubectl get destinationrule -n istio-system default-mtls
✓

Certificados workload emitidos por Intermediate CA NutriFlow (no Istio self-signed)

istioctl proxy-config secret <pod> | grep nutriflow
○

Alertas Prometheus para cert-expiry configuradas (threshold: 72h)

kubectl get prometheusrule -n monitoring | grep cert-expiry
○

Kiali dashboard muestra LOCK verde en todos los servicios production

kubectl port-forward svc/kiali 20001:20001 -n istio-system
○

Error rate < 0.1% durante 24h tras activación STRICT en billing/patients

rate(istio_requests_total{response_code=~"5..",destination_service=~"billing.*"}[5m])
○

SPIFFE trust bundles documentados para auditoría HIPAA/DACH

istioctl pc secret <pod> -o json | jq '.dynamicActiveSecrets[].name'
○

Plan de CA rotation documentado (Intermediate CA: renovar antes de mes 10)

openssl x509 -in intermediate-ca.crt -noout -enddate

📘 7 · Best Practices

✅ Hacer

Empezar con PERMISSIVE en todos los namespaces nuevos
Usar TTL de 24h o menos para workload certs
Configurar alertas de expiración con 72h de antelación
Documentar SPIFFE URIs para cada servicio crítico
Monitorizar handshake errors en Grafana Istio dashboard
Rotación planificada de Intermediate CA cada 10 meses

❌ No hacer

Deshabilitar mTLS por conveniencia en producción
Usar certs self-signed sin jerarquía de CA propia
Ignorar expiración de certificados (automatizar siempre)
Saltar verificación de cadena completa
Activar STRICT en billing/patients sin validar en staging
Compartir claves privadas de Intermediate CA en repos

NutriFlow — mTLS Zero-Trust