Reenforce Kubernetes Image Isolation in Multi-Tenant Service
summary
Claim: Kubernetes plus container runtimes currently allow image content to be reused across namespaces so one tenant can pull another tenant’s layers. Investigation shows the root cause is the single containerd content store and CRI calls that lack tenant context. Built a patched flow that threads a namespace argument into image operations and adds a per-content access policy so namespace-tagged image pulls are blocked when not authorized. Demo with a fake registry and digest-only blobs reproduces the leak and shows the patch prevents it; garbage-collection and signing remain future work and patches are upstreamed.
AI-written summary · about
chapters (10)
- 0:00Start
- 1:26API View Isolation
- 3:29Image isolation in k8s
- 4:22Image management in k8s
- 4:58Containerd Multi-Tenancy
- 6:03Reenforce it!
- 8:18Problem solved?
- 8:55Image in containerd (Demo)
- 13:12How images were pulled
- 15:43Back to problem
related talks
30mSecuring Kubernetes Multi-Tenancy
28mKubernetes Multitenancy in Image Pulling
25mSecuring Kubernetes Multi-Tenancy: Navigating Challenges Through DevSecOps Control and Visibility
30mEstablishing Image Provenance and Security in Kubernetes - Adrian Mouat, Container Solutions
31mImage Provenance and Security in Kubernetes
14mYour Containers Aren’t Alone: Demystifying Container Isolation
29mLayers of Isolation in Kubernetes
05mNamespace Multi-Tenancy, But All The Problems Related To It