3

I run multiple GitLab CI jobs that use Kaniko to build Docker images and push them to my private GitLab registry. My GitLab Runners use the Docker executor with privileged = false, and this setup has worked perfectly.

Here is my config.toml with the relevant information for my question

[[runners]] executor = "docker" [runners.docker] image = "alpine:latest" privileged = false 

My original, working GitLab C/I configuration is:

.kaniko_auth: &kaniko_auth - mkdir -p /kaniko/.docker - > echo '{ "auths": { "'"$CI_REGISTRY"'": { "auth": "'"$(echo -n "$CI_REGISTRY_USER:$CI_REGISTRY_PASSWORD" | base64)"'" }, "registre.private.com/private/private": { "auth": "'"$(echo -n "$CI_REGISTRY_USER:$CI_REGISTRY_PASSWORD" | base64)"'" } } }' > /kaniko/.docker/config.json .kaniko: image: name: gcr.io/kaniko-project/executor:debug entrypoint: [""] before_script: *kaniko_auth 

I then, include this file into my .gitlab-ci.yml file and use it like this:

# Extract from my .gitlab-ci.yml build_Golden_Complete: stage: build_docker extends: .kaniko parallel: matrix: - IMAGE_NAME: complete DOCKERFILE_PATH: ./ci_cd/DockerfileComplete - IMAGE_NAME: golden DOCKERFILE_PATH: ./ci_cd/DockerfileGolden script: - > /kaniko/executor --use-new-run --context "$CODE_DIRECTORY/" --dockerfile "$DOCKERFILE_PATH" --destination "$CONTAINER_IMAGE_BUILD:$SOME_TAG-$IMAGE_NAME" --build-arg "SRC_IMAGE=$SRC_IMAGE" --cache=true 

Recently, I upgraded one of my Dockerfiles and now need to use the #syntax=docker/dockerfile:labs directive for some features

But I've discovered that the gcr.io/kaniko-project/executor:debug image does not support this newer syntax, because this is no longer maintained. While Google archived the original Kaniko project, Chainguard maintains a fork. However, their actively updated images are behind their paywall or requires an account.

Then, I explored alternatives like Buildah and BuildKit, but they fail because they require system calls that are blocked by Docker's default seccomp profile.

Adding security_opt = ["seccomp:unconfined"] in my config.toml for my workers would probably do the trick but I don't want that, I want a solution that works like kaniko with a modern support for Dockerfile syntax.

For BuildKit I tried the official GitLab documentation on the matter which is

build-rootless: image: name: moby/buildkit:rootless entrypoint: [""] stage: build variables: BUILDKITD_FLAGS: --oci-worker-no-process-sandbox before_script: - mkdir -p ~/.docker - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > ~/.docker/config.json script: - | buildctl-daemonless.sh build \ --frontend dockerfile.v0 \ --local context=. \ --local dockerfile=. \ --output type=image,name=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA,push=true 

When I run this, I end up with

could not connect to unix:///run/user/1000/buildkit/buildkitd.sock after 10 trials ========== log ========== [rootlesskit:parent] error: failed to start the child: fork/exec /proc/self/exe: operation not permitted 

Then, I tried Buildah, also ending up with a denied unshare syscall.

Error during unshare(CLONE_NEWUSER): Operation not permitted 

So, is there a free, actively maintained tool or a specific version of Kaniko that can build Docker images using modern Dockerfile syntax while running in a standard, non-privileged GitLab CI Docker executor, without requiring me to disable the default seccomp profile?

Note: Adding security_opt = ["seccomp:unconfined"] in the runner config didn’t work for moby/buildkit:rootless. I ended up creating a special runner with privileged = true, which works, but this is not a long-term solution and only serves to unblock me for now.

2
  • There is another fork that provides images github.com/mzihlmann/kaniko Commented Sep 4 at 18:49
  • I didn't see it during my search, but unfortunately, this does not support the latest syntax. Trying to build my Dockerfile with it gave me this error: error building image: parsing dockerfile: dockerfile parse error on line 60: unknown flag: --parents. However, from what I can tell, the repo is actively updated, so maybe this will be supported in a future update. Commented Sep 5 at 7:29

1 Answer 1

1

I ran into the exact same issue today. However, adding security_opt = ["seccomp:unconfined"] to the GitLabRunner config.toml did work out for me.

Here is a short version of my config.toml:

[[runners]] executor = "docker" [runners.docker] tls_verify = false privileged = false disable_entrypoint_overwrite = false oom_kill_disable = false disable_cache = false volumes = ["/cache"] shm_size = 0 network_mtu = 0 security_opt = ["seccomp:unconfined"] 

I wonder if using podman for the GitlabRunner would work without setting ["seccomp:unconfined"].

1
  • Even if you get security_opt = ["seccomp:unconfined"] to work, it's still not what I asked for in my original question. Configuring the runner with podman as the executor seems great, but I looked into it, and it appears it would be a pain to get it working fully. I'll check on it later. Commented Sep 9 at 14:11

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.