Future of rootless container builds in GitLab CI (Discussion only)

1. Refer to the proposed plan below #38957 (comment 2697905782)

2. This discussion issue will be closed for comments on 2025-09-18

Problem to Solve

Given future maintenance of the Kaniko project is unclear, there is no known existing alternative that can replicate Kaniko's unique security model to enable image builds in Gitlab CI without requiring changes to GitLab Runner configurations or underlying Runner infrastructure.

Additional Details

Based on discussion and analysis in an adjacent Issue for improving GitLab's documentation for rootless Docker builds, Kaniko operates entirely in userspace by:

• Extracting base image contents as regular files (no filesystem mounting)
• Running Dockerfile commands directly on extracted files
• Never requiring kernel namespace manipulation or mount operations

Thus far, customers have been unable to replicate a drop-in replacement for Kaniko with BuildKit / Buildah/ Podman for rootless builds in unprivileged containers without significant security compromises. Every "working" solution (even GitLab's documented solution) requires compromising either Runner or container level security controls such as:

• Using the Docker executor in privileged mode with privileged = true
• Disabling seccomp filtering for containers with security_opt = ["seccomp:unconfined"] (allows system calls from containers that can perform kernel module manipulation and raw I/O operations on the host)
• Disabling AppArmor confinement security_opt = ["apparmor=unconfined"] (enables broader access from container to host filesystem)

These requirements for container privilege escalation (even for rootless builds) derive from:

1. Namespace Requirements: Most existing alternatives attempt to create user namespaces via unshare(CLONE_NEWUSER), which fails in unprivileged containers: Error during unshare(CLONE_NEWUSER): Operation not permitted
2. Mount Operations: Tools like BuildKit's rootlesskit try to remount / for isolation: [rootlesskit:child] error: failed to share mount point: /: permission denied

These compromises defeat the purpose of using unprivileged runners for secure, isolated image builds in GitLab CI.

Proposal:

Rather than relying on external tools that require container privilege escalation on the Runner, enhance GitLab Runner itself to support image builds in CI/CD in jobs running in unprivileged containers. This might be able to be accomplished through:

Userspace Build Engine Integration

• Integrate a Kaniko-like userspace build engine directly into GitLab Runner
• Implement file-based layer extraction and manipulation (no mounting)
• Support Dockerfile parsing and execution within Runner's existing security model

Dedicated Build Executor

• New executor type: container-build alongside docker, kubernetes, etc.
• Purpose-built for image construction without requiring external tools
• Operates within Runner's existing privilege model

Enhanced Docker Executor

• Extend the Docker executor with native build capabilities
• Implement userspace-only image construction
• Maintain compatibility with existing security configurations

Key Requirements

Security

• No privilege escalation: Works with existing unprivileged runner configurations
• No security_opt modifications: Maintains default container security policies
• No host changes: No kernel parameter adjustments or AppArmor modifications

Compatibility

• Drop-in replacement: Existing Kaniko CI configurations work with minimal changes to existing CI/CD configurations
• Registry integration: Seamless authentication with GitLab Container Registry