Well, almost. Even outside that above usecase I'd still be interested in the capabilities TinyKVM needs and its overall security model & properties! There are far too many Github projects out there these days that claim to do sandboxing and for an outsider it's very difficult to compare them security-wise.
> what about using more caving in your CI/CD Pipeline.
The caching itself is not the issue. We already heavily cache image layers when building container images. The issue (one of them) is that on our platform AppArmor prevents containers from mounting anything, including overlayfs file systems. The latter, however, are needed for Docker/Podman to do proper image layering. The only non-mount alternative I'm aware of, Kaniko, avoids overlayfs but at the cost of severe I/O and performance impact
AFAIU this is because it manually detects changes in a given image layer by walking the directory tree. See also https://github.com/GoogleContainerTools/kaniko/issues/875
No worries, I know how it is! :)
> But good to see you got your answer in the end.
Well, almost. Even outside that above usecase I'd still be interested in the capabilities TinyKVM needs and its overall security model & properties! There are far too many Github projects out there these days that claim to do sandboxing and for an outsider it's very difficult to compare them security-wise.
> what about using more caving in your CI/CD Pipeline.
The caching itself is not the issue. We already heavily cache image layers when building container images. The issue (one of them) is that on our platform AppArmor prevents containers from mounting anything, including overlayfs file systems. The latter, however, are needed for Docker/Podman to do proper image layering. The only non-mount alternative I'm aware of, Kaniko, avoids overlayfs but at the cost of severe I/O and performance impact AFAIU this is because it manually detects changes in a given image layer by walking the directory tree. See also https://github.com/GoogleContainerTools/kaniko/issues/875