Saltar a contenido

Capstone Projects-Three Tracks, One Choice

Pick one. The work performed here is what you describe in interviews.

Track 1-Mini-Docker (the curriculum's default)

Outcome: a from-scratch container runner in Go or Rust, demonstrating manual orchestration of namespaces, cgroups v2, OverlayFS, capabilities, seccomp, and a working subset of OCI runtime spec.

Functional spec

  • Read an OCI runtime bundle (config.json + rootfs/).
  • Lifecycle: create, start, state, kill, delete, plus run (create+start).
  • Apply: PID/NET/MNT/UTS/IPC/USER/CGROUP namespaces, capability dropping, seccomp filter, cgroups-v2 (memory/cpu/pids), pivot_root, masked/readonly paths.
  • Spec compliance: passes a meaningful subset of the OCI runtime spec validator.

Non-functional spec

  • Implemented in <2,500 lines of code (excluding tests).
  • Memory footprint <20 MB resident.
  • Container-start latency <100 ms on a baseline workload (matches runc within 2×).

Architecture sketch

  • Top-level CLI parses the lifecycle subcommand.
  • Runtime orchestrator: state machine over the bundle's lifecycle.
  • Init re-exec pattern (like runc's "init"): the binary self-re-execs as the container's PID 1 supervisor; performs final mount + capability + seccomp setup; execs the user command.
  • State persistence in /run/<runtime-name>/<id>/state.json.

Test rigor

  • Unit tests for: bundle parsing, namespace setup, cgroup writes, seccomp compilation.
  • Integration tests: run real bundles (Alpine, BusyBox, a small Go binary) and assert behavior.
  • Spec compliance test against (a subset of) runtime-tools/validation.
  • Chaos: malformed configs, missing rootfs, OOM, exhausted PIDs.

Hardening pass

  • Default seccomp profile equivalent to containers/common/pkg/seccomp.
  • Default capability set: CAP_NET_BIND_SERVICE only.
  • Read-only rootfs unless explicitly opted in.
  • Rootless support (user namespace path tested).

Acceptance criteria

  • Public repo, documented architecture.
  • A README walkthrough: from runc spec to running nginx under your runtime.
  • Integration tests in CI, passing.
  • A short paper (3–5 pages) comparing your runtime to runc/crun/youki: what's similar, what's different, what you skipped and why.

Skills exercised

  • All months-but heaviest on Months 1 (OCI specs), 2 (filesystems), 3 (runtimes), 4 (security primitives).

Track 2-Image Scanning & Signing Service

Outcome: an HTTP service that ingests OCI image references, runs Syft + Grype + Trivy, attaches signed SBOMs and VEX statements, and exposes a policy-gated promotion API.

Functional spec

  • `POST /scan {image} - scan, return findings.
  • `POST /promote {image, target} - verify the image meets policy (signature, SBOM, vuln thresholds, SLSA provenance) before copying to a higher-trust registry.
  • `GET /audit/{image} - full triage report, including VEX state per finding.
  • Policy as YAML; reload without restart.
  • Plugin model: scanner backends and signature verifiers loaded at startup.

Non-functional spec

  • 50 concurrent scans without degradation.
  • Sub-second policy evaluation given pre-fetched attestations.
  • Admission API compatible with Kubernetes ImagePolicyWebhook.

Architecture sketch

  • Workers consuming a scan queue.
  • skopeo for image fetching; syft and trivy shelled out (or embedded as Go libs).
  • cosign Go SDK for signature verification.
  • Postgres for findings storage; Prometheus for metrics; OTel for traces.

Test rigor

  • Unit tests for policy evaluation.
  • Integration tests against a local registry with known-good and known-bad images.
  • Property tests: policy decisions are deterministic given inputs.

Hardening pass

  • Service runs rootless in its own container.
  • mTLS between worker and registries.
  • Findings DB encrypted at rest.

Acceptance criteria

  • Public repo, README with end-to-end demo.
  • Demonstrate full flow: image with critical CVE → scan → signed VEX → policy decision → promotion gated correctly.

Skills exercised

  • Months 5 (supply chain) heavily; Months 1, 4 supporting.

Track 3-Custom Runtime Fork

Outcome: a fork of runc (or youki) adding one substantial feature: gVisor-style sandbox, a custom seccomp generator, or eBPF-based per-container observability.

Suggested scopes

  1. runc-trace: a runc fork that, before execve, attaches an eBPF program tracing syscalls and emitting per-container telemetry to a userspace consumer. Useful for forensic environments.
  2. runc-autoseccomp: generates a tight seccomp profile during a "learning" run, then enforces it. Removes the manual seccomp-authoring burden.
  3. runc-cap: stricter capabilities defaults; introspects the rootfs and disables capability sets the binary doesn't appear to need.

Acceptance

  • Forked from upstream at a tagged commit; documented merge plan to maintain rebase against upstream.
  • The new feature is opt-in via config.json annotations or a CLI flag.
  • Test coverage equivalent to upstream's for the touched code.
  • A short blog post explaining the feature, the design, and the upstream-contribution plan.

Skills exercised

  • All months. Track 3 is for the candidate who wants to contribute upstream eventually.

Cross-Track Requirements

  • container-baseline/ template (Appendix A) integrated.
  • ADRs (≥3).
  • THREAT_MODEL.md.
  • Defense readiness: 45-minute walkthrough.

Comments