Security chaos engineering for Kubernetes
secha lets you switch off one of your security controls, run the attack that control was blocking, and shows you what the rest of your system did about it.
| indicator | no auth | auth |
|---|---|---|
| data exposed | true | false |
| detected | false | true |
| time to detect | never | 676.6 ms |
| recovery integrity | true | true |
Start here
Security is built in layers. A firewall rule, then a password, then an alert if someone tries to break the system.
Most of the time the attacks are detected and stopped in the outer layers of security. However, sometimes the security measures fail, such as a bad deploy that removes a firewall rule. Someone grants one permission too many. A certificate expires.
That is what chaos engineering fixes for reliability: you shut a server down on purpose, so you learn how the system copes before it happens by accident.
secha does the same thing for security controls — on a cluster you pick, for a few seconds, and it measures what happened.
An example
This is what secha demo runs. It sets everything up
and removes it again afterwards.
01
The setup
Two identical databases. One asks for a password, one does not. A firewall rule keeps the attacker away from both.
02
The break
secha deletes that firewall rule — the same rule, in front of both databases.
03
The attack
An attacker pod connects to each database and tries to read a secret out of it.
The database with a password held. The attacker was refused, and the refused login was written to the log — so there was something to alert on.
The database without one lost the secret. And nothing was written anywhere, because a database that never asks for a password never records a failed attempt.
Taking the password away removed the protection and the evidence. Two things were lost, and only one of them would have been noticed.
What you get back
01
Whether the attack actually reached the data once the control was gone.
02
Whether anything saw it, and how many milliseconds it took to say so.
03
Whether the system refused the dangerous change before it could take effect.
Step by step.
01
Check
steady state
Confirm the system starts in the state we expect.
02
Break
fault
Switch off exactly one security control.
03
Attack
probe
Run the attack that control was blocking.
04
Watch
observe
See whether anything catches it, and how long that takes.
05
Put it back
restore
Get back to the state before the attack.
06
Confirm
verify
Verify the control is working again.
Install
Go 1.26+ and a k8s cluster you are allowed to break, on a CNI that enforces NetworkPolicy — Calico, Cilium, kube-router or Weave.
Install
$ go install github.com/Thran34/secha/cmd/secha@latest
Watch the whole thing run against a target it builds and deletes itself
$ secha demo
See what a run would break, without touching the systen
$ secha run experiment.yaml --dry-run