Set's an apparmor profile on the OCI spec if one is configred on the
worker.
Adds selinux labels to containers (only added if selinux is enabled on
the system).
This assumes that the specified apparmor profile is already loaded on
the system and does not try to load it or even check if it is loaded.
SELinux support requires the `selinux` build tag to be added.
Likewise, `runc` would require both the `apparmor` and `selinux` build
tags.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Vendored go-selinux to v1.8.0
Fixed tests
Signed-off-by: Tibor Vass <tibor@docker.com>
(cherry picked from commit 68bb095353)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
`cmd/buildkitd/config` pkg is imported and used by other packages including
moby/moby.
Though stargz snapshotter configuration is currently effective only with
buildkitd + OCI worker, `cmd/buildkitd/config` consumer needs to introduce an
indirect dependency to stargz snapshotter's config pkg
(`github.com/containerd/stargz-snapshotter/stargz/config`), which is too much.
This commit solves this by delaying decoding the stargz config until OCI
worker's initialization phase.
Signed-off-by: ktock <ktokunaga.mail@gmail.com>
Current stargz snapshotter pkg doesn't contain registry configuration and the
client of that pkg needs to pass it to that pkg. So this commit includes changes
of propagating buildkitd's registry configuration to stargz snapshotter.
But this is a partial integration of registry logic between buildkitd and stargz
snapshotter because buildkitd's session-based authentication logic is still not
applied to stargz snapshotter. This means private images that require
`~/.docker/config.json` creds can't be lazily pulled yet.
Signed-off-by: ktock <ktokunaga.mail@gmail.com>
The implementation in libcontainer/system is quite complicated,
and we only use it to detect if user-namespaces are enabled.
In addition, the implementation in containerd uses a sync.Once,
so that detection (and reading/parsing `/proc/self/uid_map`) is
only performed once.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
While real overlayfs is available only in Ubuntu and Debian kernels,
fuse-overlayfs is universally available for kernel >= 4.18.
For dockerized deployment, `--device /dev/fuse` needs to be added to
`docker run` flags.
Kubernetes deployment needs a custom device plugin that enables
`/dev/fuse`, e.g. https://github.com/honkiko/k8s-hostdev-plugin
Instead of a device plugin, the device can be also enabled by setting
`securityContext.privileged` to `true`.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
To support switching the OCI worker binary via buildkitd and without modifying the Dockerfile, an optional command-line flag was added to main_oci_worker.go that allowed for input the name of an OCI worker binary (ex. crun). This OCI worker binary would then replace the current buildkit-runc with a symbolic link to that binary. The above was done using the os/exec package's Command func.
Signed-off-by: Jeffrey Huang <jeffreyhuang23@gmail.com>
This patch allows downstream code to pass a DNSConfig that is
then used by executor/oci.GetResolvConf.
This would allow the BuildKit-based builder in Docker to honor
the docker daemon's DNS configuration, thus fixing a feature gap
with the legacy builder.
Signed-off-by: Tibor Vass <tibor@docker.com>
Note that this mode allows build executor containers to kill (and potentially ptrace) an arbitrary process in the BuildKit host namespace.
This mode should be enabled only when the BuildKit is running in a container as an unprivileged user.
Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
if buildkitd is being executed as the mapepd-root ($USER==root)
in a rootless container, we need to enable the rootless mode but
we don't want to honor $HOME.
Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>