Security
Zero Trust Security Architecture for Cloud-Native Applications: A Practical Guide
May 202610 min read
Photo by Unsplash
Photo by Unsplash
Indonesia's BSSN (Badan Siber dan Sandi Negara) reported over 3 billion cyber attack attempts against Indonesian digital infrastructure in 2025 — a 400% increase from 2022, driven by the rapid digitalization of government services and fintech. Traditional perimeter security (firewall-in, trusted-inside) is catastrophically insufficient for cloud-native architectures where workloads span multiple clouds, services communicate over shared networks, and the 'perimeter' no longer exists. Zero Trust — never trust, always verify, assume breach — is the architectural response.
Zero Trust is a security model, not a product, defined by three core principles: never trust any request implicitly based on network location (including 'inside' the corporate network), enforce least privilege access so each identity gets only the permissions it needs for the current task, and assume breach by designing systems to contain the blast radius of a compromised component. These principles apply to human users, service accounts, machine identities, and every API call between microservices.
NIST SP 800-207 defines five Zero Trust pillars: Identity (every user and service has a verified cryptographic identity), Devices (only managed, compliant devices can access resources), Network (traffic is encrypted and authorized at the workload level, not the perimeter), Applications (each application enforces its own authorization, not just network access control), and Data (data is classified and access is controlled at the data layer). Most organizations start with Identity and Network as they provide the highest immediate security return.
In a microservices architecture deployed across multiple availability zones or clouds, the concept of a trusted internal network is a fiction. A compromised container in the 'trusted' namespace can make lateral API calls to payment services, databases, and secret stores with no friction if only perimeter firewalls are in place. The 2021 SolarWinds attack demonstrated how trusted internal software can be weaponized; the 2023 MOVEit breach showed how trusted file transfer software becomes an attack vector. Zero Trust assumes these breaches happen and designs to limit their impact.
Map your service-to-service communication topology before implementing Zero Trust policies. Use Istio's Kiali dashboard or Cilium Hubble to automatically discover and visualize which services talk to which — you will invariably find unexpected connections that represent either overly permissive legacy code or potential security issues. This map becomes your baseline for writing AuthorizationPolicy rules.
Mutual TLS (mTLS) ensures that both the client and server in a service-to-service connection authenticate each other with X.509 certificates before exchanging any data. In a Kubernetes service mesh like Istio, mTLS is implemented transparently by sidecar proxies (Envoy) — application code does not change, the proxies handle certificate rotation, validation, and encryption. Istio's STRICT mTLS mode rejects all plaintext traffic, ensuring no service can accidentally communicate without authentication.
Kubernetes NetworkPolicy provides L3/L4 (IP and port) micro-segmentation, restricting which pods can initiate TCP connections to which other pods. Istio AuthorizationPolicy provides L7 (application layer) authorization, restricting which service accounts (cryptographic identities) can call which HTTP paths on which services. The two work together: NetworkPolicy stops unauthorized TCP connections before they reach the Envoy sidecar, and AuthorizationPolicy handles fine-grained HTTP-level access control for connections that do reach the service.
# NetworkPolicy — micro-segmentation: only allow payment-service to reach db
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-payment-to-db
namespace: production
spec:
podSelector:
matchLabels:
app: postgres-payments
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: payment-service
ports:
- protocol: TCP
port: 5432
---
# Default deny-all for the namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
---
# Istio PeerAuthentication — enforce mTLS for all services in namespace
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default-mtls
namespace: production
spec:
mtls:
mode: STRICT # reject all plaintext traffic
---
# Istio AuthorizationPolicy — only payment-service may call billing-service
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: billing-authz
namespace: production
spec:
selector:
matchLabels:
app: billing-service
rules:
- from:
- source:
principals:
- cluster.local/ns/production/sa/payment-serviceSPIFFE (Secure Production Identity Framework For Everyone) defines a standard for cryptographic workload identities called SVIDs (SPIFFE Verifiable Identity Documents), formatted as spiffe://trust-domain/path URIs. SPIRE (the SPIFFE Runtime Environment) is the reference implementation: a server that acts as a certificate authority, and an agent running on each node that attests workload identity (by verifying Kubernetes service account tokens, pod labels, or node attestation plugins) and issues short-lived X.509 SVIDs. SVIDs rotate automatically every hour, limiting the window of exposure if a certificate is compromised.
BSSN's Kerangka Keamanan Siber (Cyber Security Framework) aligns with NIST CSF and explicitly recommends Zero Trust principles for critical infrastructure operators (PSE — Penyelenggara Sistem Elektronik strategis). The Personal Data Protection Law (UU PDP, effective 2024) requires data controllers to implement 'appropriate technical and organizational security measures' — Zero Trust's micro-segmentation and encryption-in-transit directly satisfy these requirements and provide an audit trail for regulators. Indonesian fintech companies under OJK supervision face additional requirements for data residency and access logging that Zero Trust architectures address natively.
Replace long-lived service account passwords and API keys with short-lived OIDC tokens and Kubernetes-native workload identity. AWS IRSA (IAM Roles for Service Accounts) and GCP Workload Identity Federation allow Kubernetes pods to assume cloud IAM roles without any stored credentials — the Kubernetes API server issues a signed OIDC token that cloud IAM validates. This eliminates the most common secrets management failure mode: long-lived credentials stored in Kubernetes Secrets, environment variables, or worse, committed to Git.
Purchasing a vendor's 'Zero Trust' product (ZTNA gateway, cloud access broker) without re-architecting your identity and network policies provides a false sense of security — this is security theater. True Zero Trust requires systematically eliminating implicit trust: removing long-lived service account passwords, replacing VPN-based access with identity-aware proxies, enforcing mTLS between all services, and implementing fine-grained AuthorizationPolicies. Each step takes weeks to months. A realistic Zero Trust roadmap spans 12–24 months for a mature engineering organization.
The security value of mTLS certificates depends entirely on how quickly compromised certificates are rotated. Istio, using its built-in Citadel CA, rotates service certificates every 24 hours by default — configurable down to 1 hour for high-security environments. SPIRE rotates SVIDs every 60 minutes. Pair this with certificate transparency logging (record every issued certificate) and automated revocation via OCSP stapling to create an auditable, automatically-rotating identity fabric.
A default-deny NetworkPolicy (applied to all namespaces) ensures no pod can initiate a network connection unless explicitly permitted by a policy rule. This requires writing explicit allow rules for every legitimate communication path — initially labor-intensive but self-documenting. Cilium, a Kubernetes CNI plugin using eBPF, extends NetworkPolicy with L7 HTTP path filtering (allow only GET /api/v1/products, deny all other paths), DNS-based egress filtering, and deep observability into network flows without adding latency overhead.
Istio's telemetry generates access logs for every service-to-service call including the source identity (SPIFFE URI), destination service, HTTP method, path, response code, and latency. Shipping these logs to a SIEM (Elastic SIEM, Splunk, or open-source Wazuh) enables real-time anomaly detection: unusual call patterns between services, a service calling an endpoint it has never accessed before, or a spike in 403 Forbidden responses that indicates a misconfigured or malicious client. This visibility is impossible with traditional network monitoring.
Implement Zero Trust incrementally using Istio's PERMISSIVE mTLS mode first — it allows both plaintext and mTLS traffic while logging which services are still communicating without mTLS. Use Kiali to identify all plaintext communication paths, fix them one by one, and only switch to STRICT mode once all services show mTLS-only traffic. Trying to switch to STRICT mode in a large cluster all at once will cause immediate service disruptions.
A realistic Zero Trust implementation for an Indonesian startup or enterprise follows a phased approach: Phase 1 (months 1–3) establishes identity foundations — SSO with MFA, service account inventory, and eliminating shared credentials. Phase 2 (months 3–6) implements network controls — default-deny NetworkPolicies and mTLS between critical services. Phase 3 (months 6–12) enforces application-layer authorization — Istio AuthorizationPolicies and data classification. Each phase delivers measurable security improvements and satisfies incremental BSSN and OJK compliance requirements.
Zero Trust policies must not become a productivity tax on developers. Provide developers with clear documentation of which service-to-service calls are allowed and a self-service interface (Backstage plugin or CLI tool) to request new AuthorizationPolicy rules with automated security review. Use dry-run mode for new policies (Istio's 'audit' action logs what would be denied without actually denying it) to validate policies against production traffic before enforcement. A policy that blocks legitimate traffic will be bypassed immediately — friction drives insecure workarounds.
Key terms in this article include mTLS (Mutual TLS), SPIFFE/SPIRE, BSSN, and micro-segmentation.