AWS EKS Security: Moving Beyond “Running Pods” to a Zero-Trust Kubernetes Platform
Running workloads on Amazon EKS is only the beginning. In this article, I explore a practical security approach for EKS using least-privilege IAM, workload identity, network controls, secrets management, admission policies, and observability. I also explain why Kubernetes security should be designed in layers instead of relying on a single security mechanism.
AWS EKS Security: Moving Beyond “Running Pods” to a Zero-Trust Kubernetes Platform
When I started learning Kubernetes, my first goal was simple:
Get the application running.
Create a Deployment.
Expose it through a Service.
Configure the gateway.
Check the Pods.
Done.
But when I started thinking about production environments, I realized something important:
A running Kubernetes application is not necessarily a secure Kubernetes application.
A production EKS environment has multiple layers that need to be protected:
1
2
3
4
5
6
7
8
9
10
11
User
↓
Gateway
↓
Kubernetes Service
↓
Pod
↓
AWS Services
↓
Data
Every connection and every permission creates a potential security boundary.
This is why I started looking at EKS security from a different perspective:
Instead of asking “Is my cluster secure?”, ask “Who can do what, from where, and with which permissions?”
1. Start With Least Privilege
One of the first principles I consider in AWS security is least privilege.
A workload should not receive permissions simply because they are convenient.
For example, imagine an application that only needs to read objects from an S3 bucket.
Giving its workload broad AWS permissions would create unnecessary risk.
A better model is:
1
2
3
4
5
Application
↓
Specific IAM permissions
↓
Only required AWS resources
The question should always be:
What is the minimum permission this workload needs?
Not:
What permissions make the application work fastest?
2. Kubernetes Identity and AWS Identity Are Different
This is an important concept when working with EKS.
Kubernetes has its own identity and authorization mechanisms.
AWS has IAM.
An application running inside a Pod may need to access AWS services such as:
1
2
3
4
5
S3
DynamoDB
Secrets Manager
CloudWatch
ECR
The challenge is connecting the workload identity to the appropriate AWS permissions without giving excessive access.
This is where EKS workload identity mechanisms become important.
The basic idea is:
1
2
3
4
5
6
7
Kubernetes Workload
↓
Workload Identity
↓
IAM Role
↓
AWS Resource
The Pod should receive only the permissions required for its function.
3. Avoid Static AWS Credentials Inside Containers
One pattern I would strongly avoid is placing long-lived AWS credentials inside:
1
2
3
4
Docker image
Kubernetes manifest
Git repository
Application source code
For example:
1
2
AWS_ACCESS_KEY_ID=...
AWS_SECRET_ACCESS_KEY=...
inside an application configuration is dangerous.
Even if the credentials are not committed to Git, storing long-lived credentials unnecessarily increases the blast radius if they are exposed.
A better approach is to use AWS-native identity mechanisms that provide temporary credentials to workloads.
This leads to another important principle:
Credentials should be short-lived whenever possible.
4. Secrets Are Not Just Configuration
Another common misconception is:
"If I put it in a Kubernetes Secret, it is automatically secure."
Kubernetes Secrets are useful, but they should not be treated as the complete security solution.
Applications may need:
1
2
3
4
5
Database passwords
API tokens
TLS certificates
Third-party credentials
Encryption keys
A production architecture should consider where these secrets are stored, who can access them, how they are rotated, and how they reach the application.
A possible pattern is:
1
2
3
4
5
6
7
Secret Store
↓
Controlled Access
↓
Kubernetes Workload
↓
Application
The important part is not simply hiding the password.
The important part is controlling the entire lifecycle:
1
2
3
4
5
6
7
8
9
Create
↓
Store
↓
Access
↓
Rotate
↓
Revoke
5. Network Security Matters Too
Even if IAM permissions are correct, the network layer still matters.
Consider:
1
2
3
4
5
6
7
8
9
Internet
↓
Gateway
↓
Frontend
↓
Backend
↓
Database
Should every component be able to communicate with every other component?
Probably not.
A compromised frontend Pod should not automatically have unrestricted access to internal services.
This is where network segmentation and Kubernetes network policies become useful.
A simplified approach could be:
1
2
3
4
5
6
7
8
9
10
11
Frontend
↓
Allowed
↓
Backend
Frontend
↓
Denied
↓
Database
The objective is to reduce unnecessary communication paths.
6. Think About East-West Traffic
A lot of security discussions focus on traffic entering the cluster.
But there is another important category:
East-west traffic.
This means communication between workloads inside the environment.
For example:
1
2
3
4
5
Service A
↕
Service B
↕
Service C
If Service A becomes compromised, unrestricted internal connectivity can increase the blast radius.
This is why internal workload communication should also be controlled.
A useful question is:
If this Pod is compromised, what can it reach?
That question can reveal security gaps that are invisible when looking only at the external load balancer.
7. Admission Control: Stop Bad Workloads Before They Run
Another security layer is admission control.
Instead of waiting for a workload to cause a problem, we can prevent unsafe configurations from being deployed.
For example, an organization may want to prevent:
1
2
3
4
5
6
Privileged containers
Host network access
Host filesystem mounts
Unapproved images
Missing resource limits
Missing security configuration
The idea becomes:
1
2
3
4
5
6
7
8
9
Developer
↓
Kubernetes manifest
↓
Admission policy
↓
Allowed / Rejected
↓
Cluster
This moves security earlier in the deployment process.
Instead of saying:
"Someone deployed an insecure Pod."
we can make the platform say:
"This workload does not satisfy our security policy."
8. Container Images Are Another Attack Surface
The security of an EKS workload also depends on the image being deployed.
For example:
1
2
3
4
5
6
7
8
9
Application
↓
Dockerfile
↓
Base Image
↓
Dependencies
↓
Container Image
A vulnerable dependency or outdated base image can introduce security issues before the application even reaches Kubernetes.
This is why container image scanning and dependency management should be part of the CI/CD pipeline.
A simplified workflow could be:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Git Push
↓
Build
↓
Unit Tests
↓
Dependency Scan
↓
Container Build
↓
Image Scan
↓
Push to Registry
↓
Deploy
The earlier we detect the problem, the cheaper it is to fix.
9. Don't Forget the Supply Chain
Container security is not limited to the final image.
We also need to think about:
1
2
3
4
5
6
7
8
9
10
11
Source Code
↓
Dependencies
↓
Build Process
↓
Container Image
↓
Registry
↓
Deployment
Every stage represents a possible supply-chain risk.
For example, dependency confusion, compromised packages, malicious images, or unauthorized build changes can affect the final artifact.
This is why modern DevSecOps increasingly focuses on the complete software supply chain.
10. Image Provenance Matters
Suppose an image is running in production:
1
my-app:v1.8
Can we answer:
Where did this image come from?
A mature supply chain should make it possible to connect:
1
2
3
4
5
6
7
8
9
Git Commit
↓
Build
↓
Artifact
↓
Container Image
↓
Deployment
This gives teams more confidence that the artifact running in production is the artifact that was actually built and tested.
It also makes incident investigation easier.
11. Runtime Security Is Different From Build Security
Passing a security scan during CI does not mean the workload will always behave safely at runtime.
These are different questions.
Build-time security
1
2
3
Is the image vulnerable?
Is the dependency safe?
Was the artifact built correctly?
Runtime security
1
2
3
4
What is the workload doing?
What network connections is it making?
What permissions is it using?
Is its behavior unexpected?
Both matter.
A secure pipeline should not stop at:
1
Image scan → PASS
12. Observability Is Also a Security Tool
I previously thought of observability mainly as a reliability feature.
But security events can also appear in logs, metrics, and traces.
For example:
1
2
3
4
5
6
Unexpected API requests
Authentication failures
Unusual traffic patterns
Repeated permission errors
Unexpected container restarts
Suspicious network connections
This makes observability an important part of security monitoring.
A simplified model is:
1
2
3
4
5
6
7
Application
↓
Logs ─────┐
Metrics ──┼──→ Observability
Traces ───┘
↓
Investigation
The goal is not to collect every possible metric.
The goal is to collect useful signals that help answer:
What happened?
and:
What changed?
13. Security Should Be Layered
One of the biggest lessons I have taken from studying cloud and Kubernetes security is:
There is no single security control that solves everything.
Instead, think in layers.
1
2
3
4
5
6
7
8
9
10
11
12
13
┌─────────────────────┐
│ Application │
├─────────────────────┤
│ Container Image │
├─────────────────────┤
│ Kubernetes │
├─────────────────────┤
│ Network │
├─────────────────────┤
│ IAM / Identity │
├─────────────────────┤
│ AWS Infrastructure│
└─────────────────────┘
If one layer fails, other layers should reduce the blast radius.
This is the basic idea behind defense in depth.
14. A Practical EKS Security Checklist
If I were reviewing an EKS environment, I would ask questions like:
Identity
- Does every workload have only the permissions it needs?
- Are long-lived credentials avoided?
- Are AWS permissions scoped properly?
Kubernetes
- Are workloads running with unnecessary privileges?
- Are security policies enforced?
- Are resource limits defined?
Network
- Can every Pod communicate with every other Pod?
- Is internal traffic restricted?
- Is external access controlled?
Images
- Are container images scanned?
- Are base images maintained?
- Can we identify where an image came from?
Secrets
- Where are secrets stored?
- Who can access them?
- How are they rotated?
Runtime
- Are suspicious behaviors visible?
- Are logs and metrics available?
- Can incidents be investigated?
Supply Chain
- Can we trace an artifact back to source code?
- Are CI/CD permissions restricted?
- Are deployments protected?
15. The Zero-Trust Mindset
The term "zero trust" can sound complicated.
For me, the simplest way to understand it is:
Do not automatically trust something just because it is inside the cluster.
A Pod inside EKS should not automatically be trusted.
A service should not automatically trust another service.
A developer should not automatically have production access.
An application should not automatically have broad AWS permissions.
Every access request should have a reason.
1
2
3
4
5
6
7
8
9
Who?
↓
What resource?
↓
What action?
↓
Why?
↓
Is it al
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article