> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Summary
> Guidance on implementing Zero Trust in Istio by enforcing mTLS with PeerAuthentication, then applying L7 AuthorizationPolicy, comparing sidecar and ambient dataplanes and best practices
This lesson reviewed how to implement Zero Trust in Istio by enforcing authentication first (mTLS) and then authorization (L7 policies). The recommended sequence:
1. Verify every connection first, regardless of traffic origin.
2. Enforce mTLS with a PeerAuthentication (cluster-wide or per-namespace).
3. After identities are established, enforce permissions with AuthorizationPolicy resources.
Istio provides mTLS via the data plane. In the sidecar model Envoy sidecars (injected into workload pods) handle encryption and identity. In ambient mode, the ambient dataplane (ztunnel / Waypoint architecture) replaces per-pod sidecars — ambient mode requires different installation and namespace labels but offers equivalent authentication capabilities.
Key takeaways
* Always apply a PeerAuthentication to require mTLS for workloads or namespaces before you rely on identity-based AuthorizationPolicy rules.
* Authentication (who is talking) is distinct from authorization (what they are allowed to do). First authenticate identities, then apply AuthorizationPolicy to express permissions.
* Kubernetes NetworkPolicy works at layers 3–4 (IP/port). Istio AuthorizationPolicy works at layer 7 (HTTP/gRPC) and can control requests by paths, methods, headers, and service account principals.
* Istio policies are Kubernetes CRs — they are declarative, auditable, and suitable for GitOps-style workflows.
Technical comparison — sidecar vs ambient dataplane
| Feature | Sidecar model | Ambient mode |
| -------------------: | --------------------------------- | -------------------------------------------------- |
| Data plane component | Envoy sidecars per pod | ztunnel + optional Waypoint proxies |
| mTLS handling | Envoy sidecar enforces mTLS | ztunnel enforces L3/L4 mTLS |
| L7 enforcement | Sidecar/Envoy supports L7 filters | Requires Waypoint (L7) proxy in front of workload |
| Deployment notes | Requires Istio sidecar injection | Requires ambient installation and namespace labels |
About the ambient dataplane and proxies
* ztunnel handles L3–L4 traffic in ambient mode (it provides secure, sidecar-less mTLS).
* For L7 enforcement (path/method authorization) you need a Waypoint (or equivalent L7) proxy in front of workloads to perform HTTP-level checks.
* In labs you might observe that path/method restrictions are not enforced when using only ztunnel (L4). After you install a Waypoint proxy and label the namespace, L7 AuthorizationPolicy rules can be enforced.
* Prefer service accounts (principals) for identity-based rules because they provide clearer, more robust identity controls than labels.
Ambient mode (sidecar-less) behaves differently in terms of dataplane components. The [ICA exam](https://learn.kodekloud.com/user/courses/prep-course-istio-certified-associate-ica-certification) focuses on the sidecar model; ambient mode is useful to know but may not be tested in depth. Review the [Istio documentation on ambient mode and Waypoint proxies](https://istio.io/latest/docs/ops/deployment/ambient/) before the exam.
Istio vs Kubernetes network controls
| Resource | OSI Layers | Typical use case | Example controls |
| ----------------------------- | ---------------- | ------------------------------------------------- | ------------------------------------------------------- |
| `NetworkPolicy` (Kubernetes) | L3–L4 (IP, port) | Restrict pod-to-pod connectivity at network level | `podSelector`, `ingress`/`egress`, `ports` |
| `AuthorizationPolicy` (Istio) | L7 (HTTP/gRPC) | Fine-grained app-level permissions | HTTP `paths`, `methods`, `principals`, service accounts |
Example manifests
* PeerAuthentication to require mTLS for a namespace (namespace `foo`):
```yaml theme={null}
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: require-mtls
namespace: foo
spec:
mtls:
mode: STRICT
```
* Example AuthorizationPolicy to allow only GET requests to `/api` from a specific service account principal:
```yaml theme={null}
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-get-api
namespace: foo
spec:
selector:
matchLabels:
app: myservice
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/bar/sa/client-sa"]
to:
- operation:
methods: ["GET"]
paths: ["/api"]
```
Best practices and recommendations
* Always enable and enforce mTLS (via PeerAuthentication) before relying on Identity-based AuthorizationPolicy rules.
* Use service accounts (Istio principals) for stronger identity-based authorization. Labels can be used for convenience but are less robust.
* Use Kubernetes NetworkPolicy for coarse L3/L4 restrictions and Istio AuthorizationPolicy for L7 controls.
* Keep Istio security manifests declarative and version-controlled (GitOps).
* Test policies incrementally: enforce mTLS, then test simple ALLOW rules, then add DENY rules and finer path/method restrictions.
Final checklist for securing workloads with Istio
1. Choose the dataplane mode (sidecar or ambient) and ensure proper installation and namespace labels.
2. Configure PeerAuthentication to require mTLS where required.
3. Create AuthorizationPolicy resources for fine-grained, L7 authorization (paths, methods, principals/service accounts).
4. Use Kubernetes NetworkPolicy for L3/L4 controls and Istio AuthorizationPolicy for L7 controls.
5. Keep manifests declarative and auditable; prefer service accounts for identity-based rules.
That covers the key concepts for securing workloads with Istio. For deeper reference, consult the official docs linked below.
Links and references
* [Istio AuthorizationPolicy](https://istio.io/latest/docs/reference/config/security/authorization-policy/)
* [Istio PeerAuthentication](https://istio.io/latest/docs/reference/config/security/peer_authentication/)
* [Istio ambient mode and Waypoint](https://istio.io/latest/docs/ops/deployment/ambient/)
* [Kubernetes NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/)