[CNCF LFX Proposal] Kubescape Agent Sandbox: CRD Posture Controls + gVisor Runtime Visibility
- Dominant language
- JavaScript
- Stars
- 3.1k
- Forks
- 816
- Avg merge
- 12h 32m
- Merged PRs (30d)
- 8
Description
### CNCF Project
Kubescape
### Term
2026 Term 3 (Sep-Nov)
### Program Name
Agent Sandbox: CRD Posture Controls + gVisor Runtime Visibility
### Program Description
Google shipped GKE Agent Sandbox to GA and introduced Agent Substrate in
May 2026, pushing agent security-relevant configuration into new object
types (`WorkerPool`, `ActorTemplate`, sandbox resources) that live outside
the workloads Kubescape scans today. An `ActorTemplate` decides whether
model-generated code runs under gVisor/Kata or a shared kernel; a
`WorkerPool` decides whether one runaway actor can starve every other
session multiplexed onto it. Nothing currently treats these as posture
decisions, even though the workload is untrusted by definition — the code
an agent runs is generated by a model at request time, so the isolation and
egress posture of the resource defining it *is* the trust boundary.
This term combines two complementary halves of the same problem: static
posture (cheap, ships day one) and runtime visibility (harder, the actual
gap once isolation is misconfigured or bypassed).
**Part A — static posture and admission (near-term, PR #10 scope):**
- A new "Agent Runtime Hardening" Rego control framework against the
`WorkerPool` / `ActorTemplate` / sandbox CRD schemas, covering: runtime
isolation class pinned to gVisor/Kata (not shared-kernel default),
default-deny egress with explicit allowlist, CPU/memory ceilings per
actor, image provenance/registry allowlisting, per-session credential
scoping, and encrypted/access-scoped snapshot storage.
- Findings surfaced through the existing CLI, operator, and MCP-server
paths, with framework mapping to OWASP LLM / MITRE ATLAS where controls
map cleanly.
- An admission-control variant (VAP or Kubescape admission) that rejects or
warns on non-hardened `ActorTemplate`/sandbox definitions before they run.
**Part B — runtime visibility into gVisor sandboxes (stretch, this term's
research contribution):**
- gVisor intercepts syscalls in userspace (the Sentry), so Kubescape's
node-agent, which relies on kernel-level eBPF hooks, cannot see inside a
gVisor-isolated actor the way it sees a normal container. This is the
concrete visibility gap PR #10 explicitly defers.
- Investigate and prototype a feasible signal source for gVisor-sandboxed
actors without requiring in-Sentry code changes — candidates include
`runsc`'s built-in trace/strace export, Sentry-level seccomp/audit event
forwarding, and host-visible boundary signals (network egress, process
lifecycle of the Sentry process itself) — and feed whichever proves
viable into the node-agent's existing event pipeline.
- Deliver at minimum a design doc with a working proof-of-concept for one
signal source (e.g. sandbox start/stop and network egress visibility),
clearly scoped against what remains genuinely out of reach this term.
Explicit non-goals: no per-session/per-actor runtime attribution, and no
claim of full in-sandbox behavioral enforcement — this term establishes
posture + admission plus a first, honest answer to the visibility question,
not a complete gVisor introspection layer.
### Technologies
Go, OPA/Rego, Kubernetes admission control (ValidatingAdmissionPolicy), eBPF, gVisor (runsc)
### Skills same as Technologies?
- [x] Yes, the required skills are the same as the technologies listed above.
### Required/Desirable Skills
_No response_
### Mentors
Matthias Bertschy | @matthyx | matthias.bertschy@gmail.com | matthyx
Ben Hirschberg | @slashben | ben@armosec.io | slashben
### Upstream Issue URL
https://github.com/kubescape/kubescape/issues/2557
### Application Prerequisites
- [ ] Resume
- [ ] Cover Letter
- [ ] School Enrollment Verification
- [ ] Participation Permission from school or employer
- [ ] Coding Challenge
- [ ] Custom Prerequisite (fill in details below)
### Coding Challenge URL
_No response_
### Custom Prerequisite Name
_No response_
### Custom Prerequisite Description
_No response_
### Custom Prerequisite — File Upload
- [ ] Yes — completion of this task requires the mentee to submit a file.
---
**LFX program:** [CNCF - Kubescape: Agent Sandbox: CRD Posture Controls + gVisor Runtime Visibility (2026 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/4758765a-88a2-4c7e-ac47-8d25f4a23d40)
Contributor guide
Research direction
Start with the upstream Kubescape issue #2557 and the PR #10 scope described here, then inspect the existing node-agent event pipeline and Kubescape CLI, operator, and MCP-server paths. Done means a design document and working proof of concept for one gVisor signal source, alongside the specified CRD posture and admission controls, with remaining visibility limits clearly documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- devops, infrastructure, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100