Skip to main content

GitLab Self-Hosted Pipeline

Beta feature

CI/CD support for GitLab Self-Hosted is currently in beta for select Lacework customers. Contact your Lacework Representative for more information.

Lacework IaC Security now integrates with self-hosted CI/CD providers. For more information, go to the updated IaC Support Matrix.

Prerequisite - Select the Correct GitLab Runner​

To select the correct GitLab Runner, Lacework recommends using Docker as an executor. Go to the GitLab documentation for more information on supported executors.

The following set up configuration is an example using Docker:

concurrent = 1
check_interval = 0
[session_server]
  session_timeout = 1800
[[runners]]
  name = "gitlab-runner"
  url = "<gitlab_URL>"
  id = 1
  token = <token>
  token_obtained_at = 2022-10-17T13:35:56Z
  token_expires_at = 0001-01-01T00:00:00Z
  executor = "shell"
  [runners.custom_build_dir]
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]
    [runners.cache.azure]
[[runners]]
  name = "gitlab-runner"
  url = "<gitlab_URL>"
  id = 2
  token = <token>
  token_obtained_at = 2022-10-17T14:23:09Z
  token_expires_at = 0001-01-01T00:00:00Z
  executor = "docker"
  [runners.custom_build_dir]
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]
    [runners.cache.azure]
  [runners.docker]
    tls_verify = false
    image = "ubuntu"
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0
[[runners]]
  name = "gitlab-runner"
  url = "<gitlab_URL>"
  id = 3
  token = <token>
  token_obtained_at = 2022-10-17T14:24:21Z
  token_expires_at = 0001-01-01T00:00:00Z
  executor = "docker"
  [runners.custom_build_dir]
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]
    [runners.cache.azure]
  [runners.docker]
    tls_verify = false
    image = "ubuntu"
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0
note

The default runner does not support container-based pipelines. This must be set up post-install. If the container-based runner is not locked in, and you turn off the default runner, this results in pipeline failure.

Integrate a GitLab CI/CD Pipeline​

Before you can integrate a GitLab CI/CD pipeline, you must collect your Lacework account name, LW_API_KEY and LW_API_SECRET. To view this information:

  1. Log in to the Lacework Console.
  2. Click Settings > API keys.
  3. Select or create an API key that is enabled for IaC Security.
  4. Click the download icon.
  5. Open the downloaded .json file to view your API Key, API Secret, and account name.

Then you must configure the API Key, API Secret, and account name in your GitLab project or group:

  1. Go to your group or project then Settings > CI/CD and expand the Variables section.
  2. Click Add variable for each variable (LW_ACCOUNT, LW_API_KEY, and LW_API_SECRET) and fill in the following fields:
    • Key: LW_ACCOUNT, LW_API_KEY or LW_API_SECRET.
    • Value: Enter the value you retrieved from the .json file for each variable.

For example, Key: LW_ACCOUNT Value: <account>.lacework.net.

Then, configure a GitLab Pipeline similar to the following examples:

Example GitLab Pipeline​

stages: # List of stages for jobs, and their order of execution
  - build
  - test

build-job:
  stage: build # This job runs in the build stage.
  script:
    - echo "Nothing to build here..."
    # - sleep 5 # We're demo'ing IaC scanning, nothing to build

iac-test-job: # This job runs in the test stage.
  stage: test # It only starts when the job in the build stage completes successfully.
  image: lacework/codesec-iac:latest
  variables:
    LW_ACCOUNT: $LW_ACCOUNT
    LW_API_KEY: $LW_API_KEY
    LW_API_SECRET: $LW_API_SECRET
    SCAN_COMMAND: "tf-scan"
    SCAN_DIR: "."
    WORKSPACE: "src"
    EXIT_FLAG: "High=2"
  script:
    - sh -c /app/bin/init

Example GitLab Pipeline Using Docker​

stages:          # List of stages for jobs, and their order of execution
  - build
  - test

variables:
  LW_ACCOUNT: $LW_ACCOUNT
  LW_API_KEY: $LW_API_KEY
  LW_API_SECRET: $LW_API_SECRET

build-job:
  stage: build # This job runs in the build stage.
  script:
    - echo "Building..."
    - sleep 5 # We're demo'ing IaC scanning, nothing to build

iac-test-job:   # This job runs in the test stage.
  stage: test    # It only starts when the job in the build stage completes successfully.
  image: docker:latest
  services:
    - docker:dind
  script:
    - echo "Running Lacework IaC checks."
    - env | grep "GITLAB_\|LW_\|CI_" > env.list
    - echo "SCAN_COMMAND=tf-scan" >> env.list
    - echo "SCAN_DIR=terraform" >> env.list
    - echo "WORKSPACE=src" >> env.list
    - echo "EXIT_FLAG=High=2" >> env.list
    - docker run --env-file env.list -v "$(pwd):/app/src" lacework/codesec-iac:latest

Available Commands​

For available commands, refer to CI/CD Usage.