Closed philnalwalker closed 3 years ago
The seccomp rules provided in containers-common /usr/share/contaniers/seccomp.json
Should allow buildah/podman build to run within a container.
the --isolation=chroot, basically eliminates some of the more privileged requirements required for setting up lots of namespaces. From a security point of view, we see this as you are already within a container, so want launch subcontainers. just use chroot to setup your build environment.
Hi @rhatdan I specifically tried the seccomp rules provided in containers-common /usr/share/contaniers/seccomp.json. I also pasted the file in the original issue. Is it possible there are some needed syscalls missing? Is there a good way for us to efficiently figure out what syscalls to grant?
The syscall that is missing should be listed in the audit.log or in the journal.
BTW, We prefer to just use buildah bud
when running builds within a container.
https://developers.redhat.com/blog/2019/08/14/best-practices-for-running-buildah-in-a-container/
We have multiple podman in container issues opened lets have discussion in one place. #9015
@rhatdan The seccomp profile you linked Dan actually worked. I made the mistake of removing CAP_SYS_ADMIN from the pod thinking that I did not need that anymore when using the seccomp profile. For anyone else facing this issue you need both CAP_SYS_ADMIN in the securityContext and the appropriate seccomp metadata annotation.
Thanks for the feedback on using buildah bud over podman. Why do you prefer it over podman in automated builds?
buildah bud eliminates some of the features in podman and has been used a lot more for this use case.
But if you are running privileged it does not matter. If you want to run as locked down as possible buildah bud --isolation chroot...
Can be run within a container running with /dev/fuse, CAP_SETUID, CAP_SETGID and nothing else. Since it uses the user namespace.
When running within CRI-O I would like to experiement with running the entire podman build or buildah bud container within a separate user namespace.
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind feature
Description
We have Podman working with overlay to build containers on EKS Jenkins, however this is by way of granting the SYS_ADMIN capability. We want to eliminate granting SYS_ADMIN by way of utilizing a seccomp profile.
After doing a bit of Googling and reading similar threads on Github issues we tried @rhatdan's suggestion of using the latest Fedora container-common package seccomp.json. However we encounter the following error:
We did some negative testing to make sure it was actually using the profile. If we give it a bad profile name the pod will not come up, so it is using this profile albeit unsuccessfully.
We did read the Podman needs unshare2 and do not see this syscall in the seccomp profile?
Regardless, it would be good to document the exact seccomp profile JSON needed to use Podman in a Kubernetes container (CI container build use case.) Perhaps we can make a PR with the instructions once we get this working?
Also, if we do not add
--isolation-chroot
to the Podman command line we get the following error:time="2021-02-03T21:01:12Z" level=error msg="container_linux.go:370: starting container process caused: process_linux.go:326: applying cgroup configuration for process caused: mkdir /sys/fs/cgroup/cpuset/buildah-buildah755764111: read-only file system"
Is
--isolation-chroot
required when building a container using Podman in a Kubernetes container?Steps to reproduce the issue:
Describe the results you received:
Error: mount /var/lib/containers/storage/overlay:/var/lib/containers/storage/overlay, flags: 0x1000: operation not permitted
Describe the results you expected:
Container image to build
Output of
podman version
:Output of
podman info --debug
: '''+ podman info --debug host: arch: amd64 buildahVersion: 1.18.0 cgroupManager: cgroupfs cgroupVersion: v1 conmon: package: conmon-2.0.21-3.fc33.x86_64 path: /usr/bin/conmon version: 'conmon version 2.0.21, commit: 0f53fb68333bdead5fe4dc5175703e22cf9882ab' cpus: 8 distribution: distribution: fedora version: "33" eventLogger: file hostname: test-ljvvq-zhk4d idMappings: gidmap: null uidmap: null kernel: 5.4.80-40.140.amzn2.x86_64 linkmode: dynamic memFree: 17086222336 memTotal: 33191227392 ociRuntime: name: crun package: crun-0.17-1.fc33.x86_64 path: /usr/bin/crun version: |- crun version 0.17 commit: 0e9229ae34caaebcb86f1fde18de3acaf18c6d9a spec: 1.0.0 +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL os: linux remoteSocket: path: /run/podman/podman.sock rootless: false slirp4netns: executable: "" package: "" version: "" swapFree: 0 swapTotal: 0 uptime: 120h 55m 15.85s (Approximately 5.00 days) registries: search:Package info (e.g. output of
rpm -q podman
orapt list podman
):Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?
Yes
Additional environment details (AWS, VirtualBox, physical, etc.):
Jenkins on EKS