kubeflow-pipelines-scheduledworkflow-fips

packaged by Chainguard

Chainguard Container for kubeflow-pipelines-scheduledworkflow-fips

FIPS-compliant Minimalist Kubeflow Pipelines Images

Chainguard Containers are regularly-updated, secure-by-default container images.

Download this Container Image

For those with access, this container image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/kubeflow-pipelines-scheduledworkflow-fips:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

Overview

This image group provides FIPS-compliant backend component images that make up a Kubeflow Pipelines v2 deployment, published under the kubeflow-pipelines-*-fips repositories:

The kubeflow-pipelines-driver-fips image ships the v2 driver binary, which the Pipelines workflow controller runs as an init-container to orchestrate each pipeline task at runtime.

The kubeflow-pipelines-launcher-fips image ships the v2 launcher binary, which KFP injects into every pipeline step's Pod to fetch input artifacts, run the user's command, and upload output artifacts to the object store.

FIPS Support

These Chainguard Containers ship with the OpenSSL FIPS provider, so each component's cryptographic operations — including the TLS connections between the API server, ML Metadata, the cache webhook, and the object store — use only FIPS-approved algorithms. The Go components are compiled against a FIPS-validated OpenSSL crypto backend, and kubeflow-pipelines-metadata-envoy-fips proxies through an Envoy build linked against BoringSSL FIPS. For more on FIPS support in Chainguard Containers, consult the guide on FIPS-enabled Chainguard Containers on Chainguard Academy.

Object store credentials must be at least 10 characters

FIPS mode rejects HMAC keys shorter than 112 bits, as required by NIST SP 800-131A. AWS Signature Version 4 derives its signing key from the literal AWS4 followed by your secret key, so a secret key under 10 characters leaves fewer than 112 bits and OpenSSL refuses it.

Every component that reads or writes pipeline artifacts signs its object-store requests this way — the API server, persistence agent, driver, and launcher. With too short a key they abort at startup rather than degrade:

panic: EVP_MAC_init
	openssl error(s):
	error:1C800069:Provider routines:hmac_setkey:invalid key length

The upstream Kubeflow Pipelines manifests ship an 8-character development default (minio123), which is below this floor. Set a secret key of at least 10 characters in the mlpipeline-minio-artifact Secret before deploying these images:

kubectl create secret generic mlpipeline-minio-artifact -n kubeflow \
  --from-literal=accesskey='<ACCESS_KEY>' \
  --from-literal=secretkey='<SECRET_KEY_10_CHARS_OR_MORE>' \
  --dry-run=client -o yaml | kubectl apply -f -

The non-FIPS images are unaffected, since they do not enforce the minimum key length.

Pipeline components must use a FIPS-capable base image

Kubeflow Pipelines does not run the launcher as its own container. It copies the launcher binary into each task Pod and executes it inside your component's base image. The FIPS launcher therefore needs the OpenSSL FIPS provider to be present in that base image, not just in kubeflow-pipelines-launcher-fips.

Building a component on a base without the FIPS provider fails the task at startup:

panic: opensslcrypto: FIPS mode requested (environment variable GODEBUG=fips140=on) but not available

Use a FIPS variant as the component base, for example cgr.dev/ORGANIZATION/python-fips in place of python:

@dsl.component(base_image="cgr.dev/ORGANIZATION/python-fips:3.13")
def my_step():
    ...

This applies to every component in a pipeline, including lightweight Python components, since each one executes the launcher.

Getting Started

These images are drop-in replacements for the upstream Kubeflow Pipelines component images. Deploy them by applying the upstream kustomize manifests with the image references retargeted to your Chainguard repositories.

Create a kustomization.yaml that pulls the upstream overlay and remaps each component image (replace ORGANIZATION with your Chainguard org, and pin <KFP_VERSION> to the Kubeflow Pipelines release you are deploying):

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - github.com/kubeflow/pipelines/manifests/kustomize/env/platform-agnostic?ref=<KFP_VERSION>
images:
  - name: ghcr.io/kubeflow/kfp-api-server
    newName: cgr.dev/ORGANIZATION/kubeflow-pipelines-api-server-fips
  - name: ghcr.io/kubeflow/kfp-driver
    newName: cgr.dev/ORGANIZATION/kubeflow-pipelines-driver-fips
  # ...remap the remaining kfp-* component images the same way

Install the cluster-scoped resources, then apply the overlay:

kubectl apply -k "github.com/kubeflow/pipelines/manifests/kustomize/cluster-scoped-resources?ref=<KFP_VERSION>"
kustomize build . | kubectl apply -f -

Verify the deployment once it converges:

kubectl get pods -n kubeflow

The driver and launcher images are not run as standalone workloads. The API server injects them into each pipeline task Pod through its V2_DRIVER_IMAGE and V2_LAUNCHER_IMAGE environment variables, so point those at the FIPS repositories rather than deploying them separately:

- name: V2_DRIVER_IMAGE
  value: cgr.dev/ORGANIZATION/kubeflow-pipelines-driver-fips:latest
- name: V2_LAUNCHER_IMAGE
  value: cgr.dev/ORGANIZATION/kubeflow-pipelines-launcher-fips:latest

Documentation and Resources

For configuration and usage, refer to the upstream documentation:

• Kubeflow Pipelines documentation
• Kubeflow Pipelines source

What are Chainguard Containers?

Chainguard's free tier of Starter container images are built with Wolfi, our minimal Linux undistro.

All other Chainguard Containers are built with Chainguard OS, Chainguard's minimal Linux operating system designed to produce container images that meet the requirements of a more secure software supply chain.

The main features of Chainguard Containers include:

• Minimal design, without unnecessary software bloat
• Daily builds to ensure container images are up-to-date with available security patches
• High quality build-time SBOMs attesting to the provenance of all artifacts within the image
• Verifiable signatures provided by Sigstore
• Reproducible builds with Cosign and apko (read more about reproducibility)

For cases where you need container images with shells and package managers to build or debug, most Chainguard Containers come paired with a development, or -dev, variant.

In all other cases, including Chainguard Containers tagged as :latest or with a specific version number, the container images include only an open-source application and its runtime dependencies. These minimal container images typically do not contain a shell or package manager.

Although the -dev container image variants have similar security features as their more minimal versions, they include additional software that is typically not necessary in production environments. We recommend using multi-stage builds to copy artifacts from the -dev variant into a more minimal production image.

Need additional packages?

To improve security, Chainguard Containers include only essential dependencies. Need more packages? Chainguard customers can use Custom Assembly to add packages, either through the Console, chainctl, or API.

To use Custom Assembly in the Chainguard Console: navigate to the image you'd like to customize in your Organization's list of images, and click on the Customize image button at the top of the page.

Learn More

Refer to our Chainguard Containers documentation on Chainguard Academy. Chainguard also offers VMs and Libraries — contact us for access.

Trademarks

This software listing is packaged by Chainguard. The trademarks set forth in this offering are owned by their respective companies, and use of them does not imply any affiliation, sponsorship, or endorsement by such companies.