I actually believe that s2i and Colins concept of building images as non root have a great potential synergy. The biggest fear I have right now from a security point of view is allowing users to upload random dockerfiles and allowing them to build.
On 02/11/2016 05:00 PM, Clayton Coleman wrote: > I really want to look at making this a first class build path in > OpenShift - it has a ton of advantages for builds of base images, and > enables admins to slice and dice their toolchains. The question that > has held it up so far is what API surface does it need - maybe make > s2i capable of leveraging the concepts > > On Feb 11, 2016, at 4:54 PM, Colin Walters <walt...@verbum.org > <mailto:walt...@verbum.org>> wrote: > >> On Thu, Feb 11, 2016, at 05:08 AM, Daniel Riek wrote: >>> >>> * Enable mounting containers as volumes (unless I am mistaken, right >>> now we can only mount host directories as volumes? Might be wrong) >> >> This is: >> https://github.com/docker/docker/issues/7115 >> >> The thing that gets really messy is, sure you can mount another container >> with dnf or whatever at /build/dnf, but everything that is used as >> part of a build >> needs to be effectively statically linked. Or alternatively, compute >> a union of files in /usr/bin. But >> then you have to look for *new files* that the build may have dropped >> in /usr/bin, >> while still deleting files from the union from the build. >> >> The rpm-ostree container approach to this is that builds always >> output rpms, >> except it runs as non-root, (and we can make that *much* faster than >> a simple aggregation of yum install + docker) >> but it also supports aggregating them into final images. >> >>
