GitLab CI/CD FIPS-Compliant Runner Hardening Prompt

You are a senior platform-security engineer who operates GitLab Runners in FIPS 140-2/140-3 regulated environments (FedRAMP, government, regulated finance). You know GitLab ships dedicated `-fips` runner and helper images, how RHEL/UBI FIPS mode works, and — critically — how to *prove* a job actually executed inside the crypto boundary rather than just assuming it.

I will provide:
- Target compliance regime (FedRAMP Moderate/High, DoD, PCI, internal)
- Runner platform (self-hosted RHEL/UBI, Kubernetes executor, cloud)
- Current runner + helper images and executor config
- What the pipeline does (build language, crypto operations, signing, artifact handling)
- The gap or question (bootstrap / validate / audit an existing fleet)

Your job:

1. **Select FIPS images explicitly**:
   - Use GitLab's `-fips` runner image tags and set the FIPS helper image; do not rely on defaults.
   - Job `image:` must itself be a FIPS-validated base (UBI FIPS, RHEL FIPS) — not a stock Alpine/Debian image.
2. **Enable the OS crypto boundary**:
   - Host: `fips-mode-setup --enable` (RHEL/UBI) and reboot; verify `/proc/sys/crypto/fips_enabled` is `1`.
   - Containers inherit host FIPS mode on FIPS-enabled hosts; on Kubernetes ensure the node pool is FIPS.
3. **Assert compliance IN the job** (the part teams skip):
   - Check `cat /proc/sys/crypto/fips_enabled` == 1 and fail the job otherwise.
   - For the language runtime, assert the crypto lib reports FIPS (OpenSSL `openssl md5` should FAIL under FIPS; Go `GOFIPS`/`fips140`; Node/OpenSSL `crypto.getFips()`).
4. **Handle known FIPS breakages**: MD5/RC4/legacy TLS calls fail by design — identify and fix them, don't disable FIPS.
5. **Signing/artifacts inside the boundary**: ensure cosign/gpg/artifact crypto uses FIPS-validated modules.
6. **Runner registration & config.toml**: pin `helper_image`, set image pull policy, tag FIPS runners so only compliant jobs land on them (`tags: [fips]` + protected).
7. **Produce audit evidence**: a job artifact capturing `fips_enabled`, image digests, and the runtime FIPS assertion output, retained for auditors.

Deliverables:
- `config.toml` runner block pinning FIPS runner + helper images
- A `.gitlab-ci.yml` with a reusable `fips-assert` template that HARD-FAILS non-FIPS jobs
- The list of likely FIPS-induced failures for the given stack and their correct fixes
- An evidence-artifact job for the auditor

Mark DESTRUCTIVE or RISKY: enabling host FIPS mode on shared runners, regenerating host keys, and any change that would silently fall back to non-validated crypto.

---

Compliance regime: [FedRAMP / DoD / PCI / internal]
Runner platform: [RHEL / UBI / Kubernetes / cloud]
Current images + config: [PASTE]
Pipeline crypto ops: [build / sign / TLS / artifacts]
Gap: [bootstrap / validate / audit]

Why this prompt works

FIPS compliance in CI fails silently: a non-FIPS image runs fine, passes tests, and produces a compliant-looking pipeline while using non-validated crypto. The only real control is a runtime assertion inside the job that hard-fails when the crypto boundary is absent. This prompt centers that assertion instead of trusting image names.

How to use it

1. Pin FIPS runner AND helper images in config.toml.
2. Enable and verify host FIPS mode.
3. Add a reusable fips-assert job that fails closed.
4. Emit an evidence artifact for auditors.

Useful commands

# Host-level FIPS state
cat /proc/sys/crypto/fips_enabled          # must be 1
fips-mode-setup --check

# Assert crypto library is under FIPS
openssl md5 /etc/hostname                  # under FIPS this MUST error
openssl list -providers | grep -i fips     # OpenSSL 3 FIPS provider active?

# Go / Node runtime checks
GOFIPS=1 go test ./...                     # Go FIPS build
node -e "console.log(require('crypto').getFips())"   # 1 == FIPS enabled

GitLab CI patterns

Reusable FIPS assertion (fail closed)

.fips-assert:
  before_script:
    - |
      if [ "$(cat /proc/sys/crypto/fips_enabled 2>/dev/null)" != "1" ]; then
        echo "FIPS NOT ENABLED — refusing to run in non-compliant environment"; exit 1
      fi
    - openssl md5 /etc/hostname && { echo "MD5 succeeded — NOT in FIPS mode"; exit 1; } || echo "MD5 blocked (expected under FIPS)"

build:
  extends: .fips-assert
  image: registry.access.redhat.com/ubi9/ubi:latest   # FIPS-capable base on FIPS host
  tags: [fips]
  script:
    - ./build.sh

Runner config.toml pinning FIPS images

[[runners]]
  name = "fips-runner-01"
  url = "https://gitlab.example.com/"
  executor = "kubernetes"
  # FIPS helper image — required so clone/artifact crypto stays in boundary
  [runners.kubernetes]
    helper_image = "registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper:x86_64-latest-fips"
    image = "registry.access.redhat.com/ubi9/ubi:latest"
    pull_policy = ["if-not-present"]
    node_selector = { "fips-enabled" = "true" }

Audit evidence artifact

fips-evidence:
  extends: .fips-assert
  stage: .post
  script:
    - mkdir -p evidence
    - cat /proc/sys/crypto/fips_enabled > evidence/fips_enabled.txt
    - openssl list -providers > evidence/openssl-providers.txt
    - echo "$CI_JOB_IMAGE" > evidence/image.txt
  artifacts:
    paths: [evidence/]
    expire_in: 1 year

Common findings this catches

• Green pipelines on non-FIPS images with no runtime assertion — a false compliance claim.
• FIPS runner image paired with a stock non-FIPS helper image.
• MD5/legacy-TLS calls “fixed” by disabling FIPS instead of removing the weak algorithm.
• No retained evidence artifact, so auditors have nothing to verify.

When to escalate

• A dependency that hard-requires MD5/non-validated crypto — needs a vendor or architecture decision.
• Mixed fleets where some nodes are not FIPS — requires scheduling isolation, not config tweaks.
• Formal validation boundary questions — route to your compliance/ATO authority.