Clouds-Against-Humanity is a free, open-source teaching environment that builds a locked-down DigitalOcean homelab with OpenTofu, Spacelift, Doppler and Twingate so authorized learners can practice Zero Trust and DevSecOps safely.
| Tool | ChiefGyk3D/Clouds-Against-Humanity — an open-source homelab reference environment and wiki for learning Zero Trust and DevSecOps in the cloud |
| Category | Educational cloud security lab / infrastructure-as-code reference environment |
| Primary Use | Building a small, cheap, locked-down DigitalOcean environment with OpenTofu, Spacelift, Doppler and Twingate to learn cloud security, threat modeling and Zero Trust architecture on infrastructure you own |
| Safe Use | Entirely defensive and educational: learners deploy it against their own paid cloud accounts for training; no droplet exposes a public inbound port and the project contains no offensive tooling |
| Telemetry Note | Purely defensive by design: stage 2 ships an opt-in telemetry stack with a node exporter, Wazuh agent and auditd, shipping logs to an on-prem SIEM with dashboards — a blueprint for exactly the observability defenders rely on |
Clouds-Against-Humanity is unusual among the repositories that cross this desk: it is not an offensive tool at all, but a teaching environment — a small, cheap, deliberately locked-down DigitalOcean deployment expressed entirely as code, wrapped in a wiki of lessons that the README insists is the real product. The repository, written in Python and OpenTofu and licensed under Apache-2.0, sits at roughly 469 stars, and the maintainer is refreshingly blunt that stars measure attention rather than use. What makes it worth an operator's attention is that it demonstrates, end to end, what a least-privilege cloud footprint actually looks like when someone builds it from first principles rather than retrofitting it.
The headline architectural claim is stark: no droplet has a single public inbound port open. There is no VPN concentrator, no bastion host, and no SSH listener on the internet. Human access flows through Twingate, a Zero Trust Network Access layer whose connectors dial outbound to the vendor's controller and relays. Because the connector initiates the connection, nothing in the DigitalOcean VPC listens for inbound traffic from the public internet at all — the Mermaid diagram in the README draws this explicitly, with a dashed line from the internet annotated 'no inbound rule exists' terminating nowhere.
The README's argument for ZTNA over a remote-access VPN is one of the more coherent pieces of positioning you will read in a homelab project. A traditional VPN authenticates once and then places the device on the network, and the box performing that authentication must listen on the internet — the README cites the Colonial Pipeline intrusion of 2021 via stolen single-factor credentials and the long run of pre-authentication exploits in SSL VPN appliances from Ivanti, Fortinet, Palo Alto, Citrix and Pulse Secure. Twingate instead checks every connection against a per-resource policy, granting access to one specific host and port rather than the network. Crucially, the author resists overclaiming: WireGuard is acknowledged as a different animal from an SSL VPN appliance, site-to-site tunnels remain legitimate, and ZTNA is admitted to mean trusting a vendor's control plane.
The infrastructure layer is DigitalOcean, chosen for predictable pricing and for a cloud firewall model that attaches by tag — meaning a droplet inherits its protection from first boot rather than after someone remembers to configure it. Everything is declared in OpenTofu, the MPL-licensed open fork of Terraform, organized into layered stacks under stacks/: 00-foundation for the project, VPC and baseline firewall with zero inbound rules; 10-access for the two connectors and per-host SSH resources; 20-telemetry for stage-2 observability; 30-workloads and 50-edge for later stages, both disabled by default and never applied until their stage is approved. Reusable pieces — per-region VPCs, tag-based deny-inbound firewalls, connector bootstrapping, hardened Docker hosts — live in modules/.
The control plane is where the DevSecOps discipline shows. Spacelift runs every plan and apply, holds state, and waits for a human to confirm before anything changes — nothing applies from a laptop or from CI. Pull-request plan runs never see credentials. Secrets are handled by Doppler, from which Spacelift holds exactly one read-only token; the README is emphatic that nothing in the repository is itself a credential. GitHub Actions handle tests, scanners and a cost gate, calling hardened shared workflows with every action pinned by commit SHA — a supply-chain hygiene detail many production repositories still get wrong.
That cost gate deserves its own paragraph because it is genuinely clever. Each project phase carries a spending ceiling recorded in docs/stages/approved.json — currently $30 per month for stage 3 — and CI fails any change whose planned total exceeds the approved total for a cloud, or pushes the active clouds beyond the phase ceiling. For a learner, this converts cloud billing from an anxiety into a testable invariant. The staged roadmap itself is honest about progress: stages 0 and 1 are built, stage 2's telemetry code is merged but not yet applied, stages 3 and 4 are planned, and the edge/DMZ stage is written but deliberately inert. An AWS twin of the first two stages exists under stacks/aws/ and has been tested only with mocked providers; Azure and GCP appear in the topics but have no code.
Defensive readers will find stage 2 the most interesting work in progress: logs shipped from the cloud to an on-prem SIEM, an opt-in node exporter, a Wazuh agent and auditd, plus dashboards — with a wiki page titled 'Build your own mini SOC' pointing learners toward running Grafana. This is the same observability stack a detection engineering team would want in a production cloud, taught at homelab scale. The modules/docker-host module provisions a single droplet with Docker Engine and Portainer CE via cloud-init, with no connector and no public inbound — workloads are reached the same way everything else is, through Twingate resources scoped per host and port.
The wiki is the pedagogical core, and its structure tells you who this is for. The assumed audience is a basic power user — someone who has set up a router and could work a help desk — with CompTIA A+-level knowledge as the stated floor, explicitly noted as a benchmark rather than an endorsement. There is a Git-from-zero page, a reading order with time estimates, and a contents index. The author's framing is anti-gatekeeping in an almost polemical way: no paid tiers, no '90K in 90 days' promises, optional Patreon and donation links, and an optional DigitalOcean referral link that the README itself flags as such with nothing gated behind it. Cost decisions are documented in docs/cost.md.
From a security-hygiene standpoint the repository models good behavior beyond its architecture. SECURITY.md routes vulnerability reports away from public issues; CONTRIBUTING.md governs changes; and the feedback guidance explicitly instructs users never to paste tokens, keys, account names, real IPs or hostnames into issues — small things, but they signal a maintainer thinking about operational security as a habit rather than a feature. The growth chart is generated by a daily workflow from GitHub data rather than a third-party chart service, which is a nice touch of self-reliance.
Where does this fit for a professional? Not as a tool you run against anything, but as a reference implementation. If you have ever wanted to show a junior engineer what 'no inbound exposure' means concretely, or needed a defensible written argument for ZTNA over legacy SSL VPN for management, or wanted a tagged-firewall, IaC-managed, secrets-isolated, cost-gated architecture to crib module structure from, this repository is a legitimate specimen. It is also a rare example of a learning project whose threat modeling is explicit — the topic list includes threat-modeling and zero-trust alongside the usual cloud tags, and the lessons include decisions the author got wrong the first time, which is more instructive than a sanitized success story.
The honest caveats are the ones the README itself supplies: the project is young, significant stages are planned rather than built, only DigitalOcean is live, and the whole access model rests on trusting Twingate's control plane — a tradeoff the author acknowledges rather than hides. For authorized professionals and students building skills on their own infrastructure, Clouds-Against-Humanity offers something certification tracks rarely do: a working, cost-capped, no-public-inbound cloud where every security decision is written down and every lesson is free.
ChiefGyk3D/Clouds-Against-Humanity.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.