How to run test container in git lab shared runner without security concerns?

[prateekkarmakar]

How to run test container in git lab shared runner without security concerns?

primarily because it often requires running containers in --privileged mode, which grants them root-level access to the host. This undermines container isolation and can expose the host system to attacks. DinD can interfere with Linux Security Modules

What changes need to be done here https://java.testcontainers.org/supported_docker_environment/continuous_integration/gitlab_ci/
when running via a shared runner with security concerns. Is this a feature which will be coming later.

[EbrahimSolomon]

On GitLab shared runners you can’t rely on privileged DinD for Testcontainers. That’s a runner policy / Docker constraint, not a Testcontainers feature gap. Use one of these safe patterns:

Options that work without --privileged:

1. Remote Docker daemon (TLS): Run a hardened Docker Engine in a locked-down VM/VPC and point Testcontainers to it.

variables:
  DOCKER_HOST: tcp://$REMOTE_DOCKER_HOST:2376
  DOCKER_TLS_VERIFY: "1"
  DOCKER_CERT_PATH: "$CI_PROJECT_DIR/.docker"
test:
  image: eclipse-temurin:21
  script:
    - mkdir -p .docker
    - echo "$DOCKER_CA_PEM"     > .docker/ca.pem
    - echo "$DOCKER_CLIENT_CERT" > .docker/cert.pem
    - echo "$DOCKER_CLIENT_KEY"  > .docker/key.pem
    - ./mvnw -B test

Store the certs as masked CI variables. Job stays unprivileged; all containers run on the remote host.
2. Self-hosted runner (shell or Docker-out-of-Docker): Use a private runner with the shell executor or a Docker executor that binds to the host’s Docker socket (with appropriate AppArmor/SELinux/seccomp). No DinD, no shared-runner risk.
3. Testcontainers Cloud: Offload containers to a secure remote environment. In CI: start the agent, set TC_CLOUD_TOKEN, run tests. No privileged mode, works on shared runners.
4. Rootless Docker service (advanced): Possible with docker:dind-rootless, but fragile and often blocked on shared runners (cgroups/LSM). Prefer 1–3.

About the docs link: The current GitLab CI guide shows DinD for simplicity. For shared runners with security constraints, add an alternative section showing:

• Remote Docker over TLS (example above),
• Self-hosted shell runner,
• Testcontainers Cloud instructions.

Not recommended: Disabling Ryuk or trying to mirror the Docker socket inside an unprivileged DinD job. You’ll lose cleanup guarantees and still face LSM restrictions.

Bottom line: This isn’t a feature “coming later”—it’s about choosing a Docker provider that fits shared-runner security. Remote Docker, a private runner, or Testcontainers Cloud are the practical, secure paths today.