-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make-dind is a new image for rootless dind-enabled Prow jobs #655
Conversation
Signed-off-by: Maël Valais <[email protected]>
Skipping CI for Draft Pull Request. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: maelvls The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This is how I was able to run the image on my machine (based on https://docs.docker.com/engine/security/userns-remap/):
|
In this PR, I added a CNI configuration so that containerd stops complaining about not being able to load the CNI plugin. The message was: failed to load cni during init, please check CRI plugin status before setting up network for pods error="cni config load failed: no network config found in /etc/cni/net.d: cni plugin not initialized: failed to load cni config" The cni.json file is picked up by nerdctl as a network: root@8deca99e60b5:/# nerdctl network ls NETWORK ID NAME FILE bridge /etc/cni/net.d/nerdctl-bridge.conflist host none It is important to use the name "bridge" in the CNI configuration, ie., you should see: { "cniVersion": "1.0.0", "name": "bridge", ... } Otherwise, nerdctl will try to create another bridge network, and you will get the following error message: FATA[0002] failed to create default network: subnet 10.4.0.0/24 overlaps with other one on this address space The following warning can be ignored: WARN[0002] default network named "bridge" does not have an internal nerdctl ID or nerdctl-managed config file, it was most likely NOT created by nerdctl Signed-off-by: Maël Valais <[email protected]>
Everything in this PR is pointless: we don't have control over the CRI!! Since we are using GKE and that the GKE CRI is root, there is no point in trying to make our container image "rootless-ready" when the CRI will run as root anyways... |
See #656
To test it yourself locally, you will have to configure your CRI so that it runs as non-root:
Then, build the dind image (choose the correct command):
Finally, run the image:
You should get a prompt. Try to run a container:
Why
--privileged
when we want a rootless container? The container requires a number of capabilities to configure cgroups for the child containers and such.