File: 01-2026-04-15-truststack.md
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200

TrustStack: why I am building a cloud security lab as one connected system

Published: 2026-04-15 // Root Access: Granted

TrustStack: why I am building a cloud security lab as one connected system

I have spent a lot of time looking at security project ideas that are technically fine and still feel unfinished.

Deploy a scanner. Install Kubernetes. Run Terraform. Put a green badge in the README. Each item proves that a tool ran, but it doesn't always prove that the person using it understands what happens when a control is wrong, when an attacker works around it, or when an automation causes more damage than the incident it was meant to stop.

I don't want to build another pile of disconnected demos.

TrustStack is my attempt to build one security story across cloud accounts, Kubernetes, detection and response, and the software supply chain. It contains four projects:

  1. AwLZ creates and governs a multi-account AWS environment.

  2. KateClusters builds and hardens a Kubernetes cluster from the control plane up.

  3. PontoAntiCrack detects risky activity in AWS and responds without skipping evidence or safety checks.

  4. ProvenancePipeline proves where a container image came from and prevents an untrusted image from entering the cluster.

The order matters. PontoAntiCrack needs AWS events and accounts worth monitoring. ProvenancePipeline needs a cluster where admission control can make a real decision. Building them under one name forces me to deal with the boundaries between systems, not just the easy center of each repository.

Why the name TrustStack

"Security stack" was too broad. It could mean a list of products.

TrustStack describes the question I keep asking at each layer: what am I trusting, and why?

In AWS, I trust that member accounts cannot silently remove the controls set by the organization. I need SCPs, centralized logging, delegated security services, and a way to show that those controls are active.

In Kubernetes, I trust that a pod cannot become privileged, read a token it never needed, or talk to anything on the network by default. A YAML file is not enough. I need to attempt the action.

In the build pipeline, I trust that an image came from a specific repository, workflow, branch, and commit. A tag such as latest answers none of those questions.

In detection and response, I trust that an automated remediation will preserve evidence, touch only the unsafe part of a configuration, and stop if the event volume becomes dangerous.

That is the stack: not products layered on top of each other, but trust decisions layered on top of each other.

The rule for this project

The rule is simple:

I will not call a control complete just because its configuration exists.

Every important claim needs evidence. Depending on the control, that might be an API response, a denied action, an immutable log object, a Falco event, a failed admission request, a test fixture, or a before-and-after snapshot.

This also means keeping failed attempts.

If an SCP blocks my own deployment, that belongs in the history. If a NetworkPolicy breaks DNS, I want to document why. If an EventBridge pattern matches more events than I expected, a clean final screenshot would hide the useful part of the work.

I am building this as a learning project, so the mistakes are not noise around the result. They are part of the result.

Minimal AI, on purpose

I am limiting my use of AI while I build TrustStack.

That decision isn't based on pretending AI tools have no value. They are useful, and avoiding them forever would be artificial. The problem is that they can remove the exact struggle I need right now.

If I ask for a finished Terraform module before I understand the AWS API behind it, I might get working code and learn very little. If I paste a Kubernetes error into a chat before reading the event and the relevant local documentation, I lose the chance to form a debugging habit. If an assistant writes the detection logic, I can explain the result after the fact, but that is not the same as making the decision myself.

My working rules are:

  1. Start with official documentation, local manuals, source code, logs, and experiments.

  2. Write the first implementation myself.

  3. Use linters, tests, scanners, and validators freely. Automated checking is not the same as outsourcing the reasoning.

  4. If I use AI for a narrow task, record what it helped with and verify the result independently.

  5. Never use generated output as evidence that a control works.

I expect this to make the project slower. That is fine. Speed is not the scarce thing here. Understanding is.

How I plan to build it

AwLZ comes first because the AWS organization is the foundation for the rest of the cloud work. I will bootstrap protected Terraform state, create the organization and accounts, apply guardrails, centralize logs, and delegate the security services. The dangerous part will be getting the policies strict enough to matter without making the environment impossible to operate.

KateClusters comes next. I chose kubeadm because I want access to the control plane configuration rather than having it hidden by a managed service. I will take a baseline before hardening, then work through audit logging, encryption at rest, Pod Security Admission, RBAC, NetworkPolicy, runtime detection, and four controlled attack scenarios.

PontoAntiCrack will use the AWS environment created by AwLZ. Its first mode will be dry-run. The system should see events, plan a response, preserve a snapshot, update an audit record, and alert without changing the resource. Only after the event shapes and patterns are confirmed against real AWS events will I enable remediation.

ProvenancePipeline closes the loop between source code and runtime. It will build a small Go application, generate an SBOM, scan it, sign the image with a short-lived identity, attach provenance, verify everything from a clean job, and then let Kyverno decide whether the image belongs in KateClusters.

I already know the tempting version of this plan: install everything quickly, make a large architecture diagram, and spend the rest of the time polishing READMEs.

I'm going to resist that.

What "finished" should look like

I don't want TrustStack to finish with a list of tool names. I want it to finish with a sequence a reviewer can follow.

An action is attempted in AWS and an organization policy blocks it. The event still lands in a separate log archive account. A dangerous configuration produces a detection. The response system records the original state before changing anything.

A workload enters the build pipeline. Its components are recorded. Its image is tied to an identity and an exact digest. The cluster admits that image. The same cluster rejects an unsigned one.

Inside the cluster, a simulated attack tests the runtime controls. The preventive control either blocks it or the detection layer records it. If the detection layer itself disappears, monitoring notices that silence.

There will be gaps. A single-node lab is not a production platform. A personal AWS organization does not reproduce the politics, scale, change process, or failure modes of a large company. I won't claim otherwise.

What I can prove is how I approached the controls, what I tested, where they failed, and what changed after the failure.

That is enough reason to build this.