github.com/secure-build/gitlab-runner@v12.5.0+incompatible/docs/security/index.md (about)

     1  # Security of running jobs
     2  
     3  When using GitLab Runner you should be aware of potential security implications
     4  when running your jobs.
     5  
     6  ## Usage of Shell executor
     7  
     8  **Generally it's unsafe to run tests with `shell` executors.** The jobs are run
     9  with user's permissions (GitLab Runner's) and can steal code from other
    10  projects that are run on this server. Use only it for running the trusted builds.
    11  
    12  ## Usage of Docker executor
    13  
    14  **Docker can be considered safe when run in non-privileged mode.** To make such
    15  setup more secure it's advised to run jobs as user (non-root) in Docker containers
    16  with disabled sudo or dropped `SETUID` and `SETGID` capabilities.
    17  
    18  On the other hand there's privileged mode which enables full access to host system,
    19  permission to mount and unmount volumes and run nested containers. It's not advised
    20  to run containers in privileged mode.
    21  
    22  More granular permissions can be configured in non-privileged mode via the
    23  `cap_add`/`cap_drop` settings.
    24  
    25  ## Usage of private Docker images with `if-not-present` pull policy
    26  
    27  When using the private Docker images support described in
    28  [advanced configuration: using a private container registry](../configuration/advanced-configuration.md#using-a-private-container-registry)
    29  you should use `always` as the `pull_policy` value. Especially you should
    30  use `always` pull policy if you are hosting a public, shared Runner with the
    31  Docker executor.
    32  
    33  Let's consider such example, when pull policy is set to `if-not-present`:
    34  
    35  1. User A has a private image at `registry.example.com/image/name`.
    36  1. User A starts a build on a shared runner: The build receives registry
    37     credentials and pulls the image after authorization in registry.
    38  1. Image is stored on shared runner's host.
    39  1. User B doesn't have access to the private image at registry.example.com/image/name.
    40  1. User B starts a build which is using this image on the same shared runner
    41     as User A: Runner find a local version of the image and uses it **even if
    42     the image could not be pulled because of missing credentials**.
    43  
    44  Therefore, if you host a Runner that can be used by different users and
    45  different projects (with mixed private, and public access levels) you should
    46  never use `if-not-present` as the pull policy value, but use:
    47  
    48  - `never` - if you want to limit users to use only image pre-downloaded by you,
    49  - `always` - if you want to give users possibility to download any image from
    50    any registry.
    51  
    52  The `if-not-present` pull policy should be used **only** for specific Runners
    53  used by trusted builds and users.
    54  
    55  Read the [pull policies documentation](../executors/docker.md#how-pull-policies-work)
    56  for more information.
    57  
    58  ## Systems with Docker installed
    59  
    60  >**Note:**
    61  This applies to installations below 0.5.0 or ones that were upgraded to newer version.
    62  
    63  When installing package on Linux systems with Docker installed, `gitlab-runner`
    64  will create user that will have permission to access `Docker` daemon. This makes
    65  the jobs run with `shell` executor able to access `docker` with full permissions
    66  and potentially allows root access to the server.
    67  
    68  ## Usage of SSH executor
    69  
    70  **SSH executors are susceptible to MITM attack (man-in-the-middle)**, because of
    71  missing `StrictHostKeyChecking` option. This will be fixed in one of the future
    72  releases.
    73  
    74  ## Usage of Parallels executor
    75  
    76  **Parallels executor is the safest possible option**, because it uses full system
    77  virtualization and with VM machines that are configured to run in isolated mode
    78  it blocks access to all peripherals and shared folders.
    79  
    80  ## Cloning a runner
    81  
    82  Runners use a token to identify to the GitLab Server. If you clone a runner then
    83  the cloned runner could be picking up the same jobs for that token. This is a possible
    84  attack vector to "steal" runner jobs.