Good points across the board. I ran into a lot of problems auditing the security of my approach and it was just too easy to circumvent.
First lesson was that the architecture had to be secure in structure, not configuration. Otherwise, a novice will run claude code on the host machine and just bork the entire setup.
So now I've replaced tightbeam runtime with a small runtime on the workspace container. Tightbeam and Airlock have been moved to separate pods. So you don't need network egress on the workspace pod at all.
Secondly, I'm isolating credentials on Tightbeam and Airlock with k8s jobs. Rather than airlock full CLI commands, you just create "airlock tools" with k8s secrets. Airlock controller never sees the secret. The tool could be like "git-create-branch" and "gh-create-pr".
Tightbeam is pretty much symmetrical. LLM credentials are tied to jobs.
I'm tying them together into a unified architecture now. Please do let me know if you have additional thoughts!
First lesson was that the architecture had to be secure in structure, not configuration. Otherwise, a novice will run claude code on the host machine and just bork the entire setup.
So now I've replaced tightbeam runtime with a small runtime on the workspace container. Tightbeam and Airlock have been moved to separate pods. So you don't need network egress on the workspace pod at all.
Secondly, I'm isolating credentials on Tightbeam and Airlock with k8s jobs. Rather than airlock full CLI commands, you just create "airlock tools" with k8s secrets. Airlock controller never sees the secret. The tool could be like "git-create-branch" and "gh-create-pr".
Tightbeam is pretty much symmetrical. LLM credentials are tied to jobs.
I'm tying them together into a unified architecture now. Please do let me know if you have additional thoughts!