Cybersecurity SaaS: Zero Trust Network Architecture on EKS
A threat intelligence platform needed to meet enterprise customer requirements for network segmentation, mTLS between all services, and zero standing access to production systems. Their flat EKS network allowed any pod to talk to any other pod. We implemented a full Zero Trust architecture using Istio and AWS IAM roles for service accounts in 5 weeks.
The Challenge
The company had won two Fortune 500 POC evaluations but both security reviews had flagged the same issue: no network segmentation, no mutual TLS between services, and engineers using long-lived IAM access keys to access production. For a company selling threat intelligence to enterprises, running a flat internal network was a credibility problem as much as a security problem.
The Approach
Zero Trust in Kubernetes has three components: network policy (who can talk to whom), service mesh mTLS (cryptographic identity between services), and workload identity (no long-lived credentials). We implemented all three using Istio service mesh, Kubernetes NetworkPolicies, and EKS IRSA (IAM Roles for Service Accounts).
The Implementation
Istio service mesh with automatic mTLS
We installed Istio in sidecar injection mode. Every pod in the production namespace got an Envoy sidecar that handled mTLS automatically - service-to-service communication was encrypted and mutually authenticated without any application code changes. We set PeerAuthentication to STRICT mode: connections without valid certificates were rejected.
Kubernetes NetworkPolicy for service segmentation
We implemented a default-deny NetworkPolicy at the namespace level and then allowlisted only the specific ingress paths each service needed. The threat intelligence ingestion service could receive from the API but not from the billing service. The database proxy only accepted connections from the API, worker, and admin service - not from any other pod.
IRSA for workload identity
We replaced all long-lived IAM access keys used by services with EKS IRSA - each service account got an IAM role with only the permissions it needed, and credentials were injected as short-lived tokens by the EKS Pod Identity Webhook. The S3 uploader service had an IAM role that could only write to one specific prefix. No service could read what another service owned.
Just-in-time production access
Engineers had been using personal AWS access keys with AdministratorAccess for production debugging. We replaced this with AWS SSO and permission sets: engineers request elevated access, which is auto-approved for 4 hours, then revoked. All production access is logged in CloudTrail with identity context. There are no standing production access keys.
Key Takeaways
- Istio mTLS is the most impactful single change for any company selling to enterprises - mutual authentication between services costs nothing after implementation
- Default-deny NetworkPolicy followed by explicit allowlists is always more secure than trying to block known-bad traffic
- IRSA replaces long-lived access keys with zero application code changes - the security improvement is immediate and the migration path is straightforward
- Just-in-time production access is a policy change, not a technical one - but it is one of the most valued controls by enterprise security teams
Facing Similar Challenges?
Book a free 30-minute audit and I will tell you what I see.