A walkthrough of the Blue Team Village's CTF contest infrastructure. If you came here looking for the answers sorry.
This project started as the system configuration for Blue Team Village's DefCon32 Capture the Flag event.
We needed to build a system that even after poking a few intentional holes in the services hosted within our Kubernetes Cluster, still allowed us thorough insight into how the system had been compromised and what the attacker had done after gaining access.
For more information on the CTF event itself, feel free to join the Blue Team Village Discord.
This repository represents the culmination of that work, so that others can replicate it within their own organizations in order to secure their systems as they either expand their Kubernetes footprint or start using it for the first time.
| Tool | Purpose | Links |
|---|---|---|
| Cilium | e-BPF Container Network Interface | Site, Docs |
| Tetragon | e-BPF Security observability and runtime enforcement | Docs |
| Local Tools | Purpose | Link |
|---|---|---|
| AWS CLI | AWS Authentication and connecting to the created cluster | Site, Docs |
| eksctl | Initial cluster creation | Docs |
| kubectl | Kubernetes CLI | Docs |
| k9s | (Optional) Kubernetes CLI wrapper, improves usability of kubectl | Docs |
| helm | Kubernetes package manager | Docs |
The guide leverages the Makefile in this repository to simplify how the commands are being presented. The Makefile is in order of the commands being run, to get an in-depth walkthrough of the setup go ahead and checkout the Guide.
The project was primarily put together by a small team and thus there are few limitations to be aware of if you chose to follow in its footsteps.
- Clouds - The implementation here is not explicitly AWS based, since most of the configuration resides within Kubernetes itself with non-specific resources, it has however not been tested on providers besides EKS.
- Autoscaling - Ideally Karpenter or another cluster autoscaler would be implemented on the cluster so that as more nodes are required the cluster scales up without manual intervention. This was skipped during the initial implementation due to time constraints.
- Continuous Deployment - The implementation here is done with a series of manually run commands. In a long term production environment, it is recommended that these kinds of actions are managed by automation. This was skipped since the cluster we were working on, we knew had an expiration date and speed of operations was a higher priority than a fully functioning
- Infrastructure as Code (IaC) - While this repository is arguably Infrastructure as Code, a series of Makefile scripts does not maintain state like Terraform or reconcile to correct drift like Crossplane, making infrastructure created in this way vulnerable to impatient engineers changing things in a cloud provider's UI.
- In an organization where clusters are being created frequently, or across different cloud providers, a tool like ClusterAPI could prove useful as well.