Project Fortress β Production Hardening of an AWS EKS Platform
Production-grade AWS platform hardened with Terraform and DevSecOps practices, featuring GitHub OIDC authentication, least-privilege IAM, secure secrets management, EKS access controls, automated CI/CD, infrastructure drift recovery, and production incident documentation.
I built Project Fortress as the production-operations evolution of Project Bedrock, focusing on what happens after a cloud platform has already been deployed and needs to be secured, maintained, and operated reliably.
The problem I addressed was the operational risk associated with managing a production AWS environment using long-lived credentials, broad IAM permissions, manual Kubernetes access, unmanaged secrets, and infrastructure changes that could cause configuration drift. The goal was to transform the existing AWS platform into a more secure and maintainable production environment using modern Cloud and DevSecOps practices.
I hardened the infrastructure using Terraform, organizing the environment into reusable modules covering networking, EKS, IAM, KMS, Secrets Manager, SSM, Lambda, monitoring, S3, RDS, DynamoDB, OIDC, and ECR. The platform retained its AWS foundation of VPC networking, private/public subnets, EKS, RDS, S3, Lambda, CloudWatch, IAM, and Application Load Balancing
For identity and access management, I implemented GitHub OpenID Connect (OIDC) so GitHub Actions can authenticate to AWS using temporary credentials rather than long-lived AWS access keys. I also introduced dedicated deployment roles, IAM trust relationships, explicit EKS access entries, and role separation to eliminate dependence on the original cluster creator for Kubernetes access
I implemented secure configuration and secret management using AWS Secrets Manager and Systems Manager Parameter Store, separating sensitive database credentials from non-sensitive application configuration. Customer-managed KMS keys were also introduced to strengthen encryption and key-management controls.
The CI/CD platform was hardened with GitHub Actions workflows that perform Terraform validation, planning, infrastructure deployment, kubeconfig configuration, AWS Load Balancer Controller deployment, and Kubernetes validation. This created an automated path from a code change to a validated infrastructure environment
I also incorporated production incident management into the project by documenting infrastructure drift scenarios, root-cause analysis, recovery procedures, lessons learned, and preventive actions. A complete postmortem was created around recovering an EKS environment following manual infrastructure drift.
The platform was designed for high availability and resilience. It runs across two availability zones, automatically replaces failed instances, scales based on CPU utilization, and includes health checks, monitoring alerts, and database redundancy.
This project improved security, automated infrastructure management, reduced deployment effort, and provided complete visibility into application and infrastructure health.
Key Benefits
- π Eliminated long-lived AWS credentials through GitHub OIDC
- π Implemented least-privilege IAM and explicit EKS access management
- π Centralized secrets using AWS Secrets Manager
- βοΈ Managed application configuration through AWS Systems Manager Parameter Store
- π Added customer-managed KMS encryption
- π Automated Terraform-based infrastructure deployment
- βΈοΈ Hardened Amazon EKS access and operations
- π Improved protection against infrastructure drift
- π¨ Introduced production-style incident response and postmortems
- ποΈ Applied reusable Terraform module architecture
- βοΈ Built a more secure and maintainable production AWS platform