Add blog post: Zero Trust in Practice: Migrating from Istio Sidecar to Ambient Mode

[Prianshu-git]

Summary

A hands-on, step-by-step comparison of Istio sidecar mode vs ambient mode for
zero-trust service mesh. Same application, same policy, two architectures — proven
on a local kind cluster.

What's Covered

• Baseline: plain Kubernetes with no mesh
• Phase 1: Sidecar mode — injection, mTLS, strict mode, AuthorizationPolicy
• Clean reset between architectures
• Phase 2: Ambient mode — ztunnel, L4/L7 split, waypoint proxy
• The gotcha: use-waypoint label vs annotation
• Side-by-side comparison table
• Published latency benchmarks from Istio

Files Added

• content/blog/zero-trust-istio-sidecar-vs-ambient.md
• public/img/blog/zero-trust-istio-sidecar-vs-ambient/ (25 screenshots + cover)
• public/img/authors/prianshu.jpg
• Updated content/authors.json

Checklist

• Post follows WRITING-A-BLOG.md guide
• Frontmatter includes all required fields
• Images placed in public/img/blog/<slug>/
• Author entry added to content/authors.json
• DCO sign-off included
• Previewed locally with npm run dev
• Builds successfully with npm run build
• Post renders at /blog/zero-trust-istio-sidecar-vs-ambient
• Author page renders at /blog/author/prianshu

Live Demo

Full runnable repo: https://github.com/Prianshu-git/Service-mesh-Zero-Trust-migration

[shkatara]

@Prianshu-git Great hands-on comparison. Here is some constructive feedback:

1. Skip the failed annotation step:
   In "The Nuance" section, remove "Try 2: annotate payments" and go straight to labeling the Service (istio.io/use-waypoint=payments-waypoint). Walking through a failed annotation attempt adds unnecessary troubleshooting noise.

2. Remove redundant command screenshots:
   Many commands appear twice—once as a code block and again as a terminal screenshot right below it. Stick to a copyable code block for the command followed by plain text for the terminal output.

3. Explain AuthorizationPolicy anatomy and rules:
   The blog says AuthorizationPolicy "covers access control" and applies a file, but does not explain how it works. Briefly explain its structure.

4. Explain the transparent proxy concept (HTTP vs. mTLS):
   Headings state "mTLS is Active/Working", but the command right under them uses plain http://. Add a quick note explaining that application code always sends plain http:// locally, and the proxies handle mTLS encryption transparently across the wire.

5. Explain what 127.0.0.6 is:
   The text mentions the origin IP is not 127.0.0.6 in ambient mode without context. Clarify that 127.0.0.6 is Envoy's internal loopback redirect IP used in sidecar mode, while ambient ztunnel delivers traffic at L4 preserving the real Pod IP.

6. Add context before introducing Gateway API and Waypoints:
   Gateway API is introduced abruptly for internal mesh traffic. Add a brief bridge explaining the L4 vs. L7 split: ztunnel only handles Layer 4, so L7 policies fail safe (connection drop). To inspect HTTP paths/methods, Ambient runs an on-demand Envoy pod called a Waypoint, which Istio models using standard Kubernetes Gateway API resources.

7. Show YAML manifests inline:
   Show short YAML snippets in the article for PeerAuthentication, AuthorizationPolicy, and the Waypoint Gateway rather than just referencing filenames.

8. Minor clarifications and formatting:

• Clarify that 000 is curl's exit code for a dropped TCP connection at L4, whereas 403 is an HTTP rejection from an L7 proxy.