OPA ScaleFT Docker Images for Labs and Automation

Introduction

#

When I work on Okta Privileged Access (OPA) labs, I often need the same building blocks again and again: the sft client for automation, and sometimes the OPA gateway package for test environments.

Installing those packages in every GitHub Actions run works, but it adds time and noise. So I created a small companion project: OPA ScaleFT Docker.

It publishes two reusable Docker images on GitHub Container Registry:

Why I Built It

#

The first use case came from an OPA Workloads lab with GitHub Actions. The workflow needs the sft client to authenticate a workload, reveal a secret, or run an SSH smoke test against an OPA-managed Linux target.

Instead of installing scaleft-client-tools on every runner, the workflow can run inside a container that already includes the client:

jobs:
  automation:
    runs-on: ubuntu-24.04
    container:
      image: ghcr.io/fabiograsso/opa-scaleft-client:latest

    permissions:
      contents: read
      packages: read

    steps:
      - name: Check sft
        run: sft --version

This keeps workflow files cleaner and makes the runtime more predictable.

What Is Inside

#

Both images are based on debian:12-slim and use the Okta PAM apt repository for Debian bookworm.

The client image includes:

• scaleft-client-tools
• bash
• curl
• jq
• OpenSSH client
• script from util-linux, useful when a non-interactive runner needs a pseudo-terminal

The gateway image includes:

• scaleft-gateway
• bash
• curl
• jq
• script from util-linux

No OPA credentials, API keys, setup tokens, enrollment tokens, tenant configuration, or workload tokens are baked into the images.

Versioned Tags

#

The images are published with latest and with the actual package version:

ghcr.io/fabiograsso/opa-scaleft-client:latest
ghcr.io/fabiograsso/opa-scaleft-client:1.108.0

ghcr.io/fabiograsso/opa-scaleft-gateway:latest
ghcr.io/fabiograsso/opa-scaleft-gateway:1.108.0

A scheduled GitHub Actions workflow checks the Okta PAM Debian package metadata weekly. If a new package version appears, it builds and publishes a new image tag. If the version already exists on GHCR, the workflow skips the build.

Runtime Configuration

#

For the client image, mount /etc/sft/ if your automation needs local sft configuration:

docker run --rm \
  -v "$PWD/sft-config:/etc/sft" \
  ghcr.io/fabiograsso/opa-scaleft-client:latest \
  sft --version

For the gateway image, mount /etc/sft/ so the container can read:

/etc/sft/sft-gatewayd.yaml

For the gateway setup token, use one of these options:

• mount /var/lib/sft-gatewayd/setup.token read-only
• or set SetupToken directly in /etc/sft/sft-gatewayd.yaml

Example:

docker run --rm \
  -v "$PWD/sft-config:/etc/sft" \
  -v "$PWD/setup.token:/var/lib/sft-gatewayd/setup.token:ro" \
  ghcr.io/fabiograsso/opa-scaleft-gateway:latest \
  bash

Okta documents SetupTokenFile as the recommended method, with /var/lib/sft-gatewayd/setup.token as the Linux default.¹

Where This Fits

#

This is not meant to replace official installation guidance. For production, follow your organization’s packaging, hardening, update, and support process.

For labs, demos, and automation experiments, it gives you a faster starting point:

• CI/CD workflows that need sft
• OPA Workloads demos with GitHub Actions
• SSH smoke tests through OPA
• secret reveal tests
• gateway package experiments where configuration is mounted at runtime

The project is available now at github.com/fabiograsso/opa-scaleft-docker.

If you try it, feedback and pull requests are welcome.