Threat Model for Kubernetes-based Financial Gateway
Methodology
Threat modeling at scale requires a structured approach. We chose the STRIDE methodology (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege).
Data Flow Diagramming
We mapped out the entire payment flow, identifying:
- Trust Boundaries: Where data crosses between different security zones.
- Data Stores: Where sensitive PII and PCI data resides.
- Processes: The microservices handling the logic.
Key Discovery: Privilege Escalation
During the TAM (Tampering) analysis, we discovered that several pods had automountServiceAccountToken: true with a default role that had broad LIST permissions. This could have allowed a compromised pod to map the entire cluster and look for other secrets.
Remediation
- Disabled default service account token mounting.
- Implemented Least Privilege RBAC roles.
- Enabled Network Policies to restrict pod-to-pod communication.
"A threat model is a living document. It should evolve as the architecture changes."
The Context
A new Kubernetes-hosted payment gateway was approaching production with no formal threat model. Regulatory requirements mandated a documented risk assessment before go-live.
The Approach
Facilitated a 3-session threat modeling workshop using STRIDE taxonomy. Created data-flow diagrams across 8 microservices, identified trust zones, and modeled 40+ threats. Scored and prioritized by DREAD methodology.
The Impact
Identified 3 critical permission scope violations prior to deployment. Required implementation of mutual TLS between services and scoped RBAC roles, preventing potential privilege escalation paths.