This repository contains the complete Infrastructure as Code (IaC) and deployment manifests for a highly available, secure financial microservice. The infrastructure is provisioned on AWS using Terraform, leveraging an Elastic Kubernetes Service (EKS) cluster deployed within a custom Virtual Private Cloud (VPC).
The core philosophy of this project is Security by Default and Zero Trust Architecture. It eliminates hardcoded credentials, enforces least-privilege IAM access, and ensures strict container runtime security.
The Problem: Storing long-lived AWS IAM Access Keys in GitHub Secrets creates a massive blast radius if the repository or CI/CD platform is compromised.
The Solution: Implemented AWS IAM Identity Center and OIDC integration with GitHub Actions. The deployment pipeline requests temporary, short-lived STS tokens for authentication, ensuring zero static credentials exist anywhere in the pipeline.
The Problem: Exposing worker nodes to the public internet invites automated scanning and exploitation.
The Solution: Designed a custom VPC utilizing public and private subnets. The EKS worker nodes (t3.small) reside strictly in private subnets, utilizing a NAT Gateway for outbound artifact retrieval. Only the Kubernetes LoadBalancer Service is exposed to the public internet, acting as the sole ingress point.
The Problem: Default container configurations often run as the root user, making container escape vulnerabilities catastrophic to the host node.
The Solution: Enforced strict Kubernetes SecurityContext rules at the Deployment level. The Flask banking application is forced to run as an unprivileged user (runAsUser: 1000, runAsGroup: 3000), mitigating the impact of potential application-layer compromises.
The Problem: Deploying untracked or vulnerable container images into a production cluster.
The Solution: Deployed a private Amazon Elastic Container Registry (ECR) via Terraform with image_scanning_configuration { scan_on_push = true } enabled. Kubernetes workloads pull strictly tagged, immutable image digests rather than relying on the volatile :latest tag.
zero-trust-banking-platform/
├── .github/workflows/
│ └── deploy.yml # CI/CD pipeline with AWS OIDC authentication
├── k8s-manifests/
│ ├── bank-deployment.yaml # K8s Deployment (Replicas, SecurityContext, Liveness Probes)
│ └── bank-service.yaml # K8s LoadBalancer Service for public ingress
├── terraform/
│ ├── main.tf # VPC networking & EKS Cluster module definitions (v1.29)
│ ├── ecr.tf # Private container registry definition
│ └── providers.tf # AWS provider and remote S3/DynamoDB backend configuration
└── app/
├── app.py # Python Flask microservice (Bank Dashboard)
└── Dockerfile # Multi-stage, minimal attack surface container build
- AWS CLI configured (for initial backend setup)
- Terraform
>= 1.5.0 kubectlconfigured
The infrastructure state is managed remotely via S3 with state locking handled by DynamoDB to prevent concurrent pipeline corruption.
terraform init
terraform plan
terraform apply --auto-approveOnce the EKS cluster is successfully provisioned, update your local kubeconfig using the AWS CLI. Note: Access entries are strictly managed via the access_entries block in main.tf to ensure explicit authorization mapping between IAM identities and RBAC.
aws eks update-kubeconfig --region af-south-1 --name devsecops-clusterDeploy the banking application to the worker nodes. The deployment utilizes a standard rolling update strategy ensuring zero downtime during updates.
kubectl apply -f k8s-manifests/To prevent ongoing AWS billing for the NAT Gateway and EKS Control Plane, tear down the environment:
kubectl delete svc bank-loadbalancer
terraform destroy --auto-approveThis project is part of a research and engineering progression. The security architecture demonstrated here (particulary the Zero Trust deployment model and container runtime hardening) forms the production environment context for ongoing research into kernel-level runtime threat detection using eBPF. See: https://github.com/Murashidzi/sentinel-ebpf (in development)