GitLab Ultimate self-managed customer interested in this capability with their Docker Executor on RHEL hosts.

Customer Ticket: Internal Only (Zendesk)

Use case: Many internal teams rely on Testcontainers for integration/unit tests. Historically they used /var/run/docker.sock from the host inside the build container, which:

• Leaves behind orphaned containers when jobs crash or terminate abruptly.
• Grants effective root on the host, which is not acceptable for their shared RHEL infrastructure.

Desired architecture: A rootless sidecar service (Podman or Docker‑in‑Docker) running as a job service container. They have validated that a rootless runtime works from the main build container using cap_add (for example SYS_ADMIN and NET_ADMIN to mount /proc and configure bridges), but there is currently no equivalent for services (no services_cap_add or similar).

Because of that gap they’re currently stuck between:

• services_privileged = true (security risk they cannot accept); and
• Non‑privileged services which cannot acquire the capabilities they need to operate a rootless sidecar runtime.

They’ve previously engaged with Support around #2150 (closed), which requested applying cap_add/cap_drop to service containers as well as the main build container. That issue was auto‑closed without implementation, but the underlying need remains and is now affecting a current Ultimate customer deployment.

Why this matters

• The customer is actively working to move away from host‑docker‑sock patterns toward a more secure sidecar model.
• They want to keep jobs non‑privileged while still granting tightly scoped capabilities (primarily for mount and networking) to the service container that runs their container runtime.
• Having cap_add (and ideally devices) available for services would let them avoid services_privileged and still meet both their security and lifecycle requirements for Testcontainers.

Please consider this as an additional strong signal for prioritizing this feature.

If there’s a newer issue that should be considered the canonical tracker for “capabilities/devices on Docker services”, I’m happy to help move the customer reference there.